Repository navigation
Building on the M5 deliverable, provide a JSON-level standalone validator endpoint for any implementer to test against #21
Description
Activity
- moved this from Backlog to In progress in SovereignTech Funded Activities
on May 21, 2026 Here is the full set of PRs behind M9, grouped by what each part actually does and then by platform. GitHub expands the links to their titles, so I kept the notes short. The earlier work sits at the bottom since it is related but not part of the M9 contract.
Milestone 9
The validator itself: the web UI and the Go backend that serves the JSON validation endpoint.
ocm-web-site (validator UI)
- feat(validator): M9 web federation validator + GHCR publish MahdiBaghbani/ocm-web-site#8
- ci(web): fix checkout sha in ghcr publish MahdiBaghbani/ocm-web-site#9
- ci(web): rename ghcr image to ocm-web-site MahdiBaghbani/ocm-web-site#10
- fix(validator): bind host fns and send URL target MahdiBaghbani/ocm-web-site#11
- feat(validator): redesign results UI with live scores and privacy MahdiBaghbani/ocm-web-site#12
- feat(validator): validator UI v2 redesign MahdiBaghbani/ocm-web-site#13
opencloudmesh-go (backend and JSON endpoint)
- feat(validator): add federation validator MahdiBaghbani/opencloudmesh-go#89
- chore(release): v1.3.0 MahdiBaghbani/opencloudmesh-go#90
- fix(validator): concurrent active sessions MahdiBaghbani/opencloudmesh-go#93
- chore(release): v1.3.1 MahdiBaghbani/opencloudmesh-go#94
Build and test plumbing
Packaging and end to end tests that back the validator, plus the ocmgo cells in the shared test suite.
opencloudmesh-go
- ci(e2e): push/PR, playwright results, badge MahdiBaghbani/opencloudmesh-go#24
- ci: add build foundation and pure-Go sqlite MahdiBaghbani/opencloudmesh-go#38
ocm-test-suite
- add: opencloudmesh-go e2e tests ocm-test-suite#215
- OpenCloudMesh Go share mount fix ocm-test-suite#219
- add: OCM Go matrix truthfulness ocm-test-suite#220
Upstream OCM fixes the active test needed
These live in other people's servers. The active flow only runs end to end once they merged, so I'm listing them as supporting work rather than M9 itself.
Reva
- Bugfix: Set correct user type when accepting OCM invites reva#5415
- Bugfix: Fix inverted expiry check in JSON invite repository reva#5418
- Enhancement: add OCM code-flow token exchange reva#5552
- Bugfix: normalize remote user ids in OCM reva#5695
- Bugfix: Resolve single-file OCM shares over WebDAV reva#5696
- Bugfix: Normalize user ids on incoming OCM shares reva#5698
OpenCloud
Nextcloud
OCM-API spec alignment
The spec I validate against, kept in sync while building the validator.
- fix: sync discovery schema/spec with IETF-RFC.md OCM-API#317
- Clarify code flow sender and receiver semantics OCM-API#354
- OCM-IP: resolve JWKS via Discovery jwksUri, not a fixed path OCM-API#395
Done as part of this milestone but not directly related to the contract
Earlier work on the site and the Go reference server. Related, but it predates the M9 validator contract.
ocm-web-site
- fix(site): rename observatory and fix hero map MahdiBaghbani/ocm-web-site#1
- Sta/m9/fix website branding 2 MahdiBaghbani/ocm-web-site#2
- update(observatory): align with backend contract MahdiBaghbani/ocm-web-site#3
- update(observatory): align with backend contract MahdiBaghbani/ocm-web-site#4
- update(obs): align labels with matrix metadata MahdiBaghbani/ocm-web-site#5
- add: fund details in readme MahdiBaghbani/ocm-web-site#6
- add: STA Milestone 8 WebApp share flow MahdiBaghbani/ocm-web-site#7
opencloudmesh-go
- fix(test): scoped harness transport defaults MahdiBaghbani/opencloudmesh-go#2
- fix(proxy): support env-aware outbound routing MahdiBaghbani/opencloudmesh-go#3
- fix(signature): tighten strict signature boundary MahdiBaghbani/opencloudmesh-go#4
- add: nested SSRF route policies for strict transport MahdiBaghbani/opencloudmesh-go#7
- update(config): fail on unsupported keys MahdiBaghbani/opencloudmesh-go#8
- Code quality reorganization MahdiBaghbani/opencloudmesh-go#9
Still open upstream
A few more fixes on the same push that are not merged yet, so I'm not counting them as evidence, just noting they are in flight.
Reva
ownCloud (oCIS and Reva fork)
- feat(ocm): add WAYF configuration for reva OCM service owncloud/ocis#11758
- feat(ocm): add wayf specific /discover and /federations endpoints to sciencemesh package owncloud/reva#432
CERNBox
- feat(ocm): implement WAYF page and enhance invitation workflow cernbox/web#228
- Feature: open webapp cernbox/web#260
If any of these sit in the wrong group, let me know and I'll move them.
A walk through of the validator, screen by screen. Passive first, which needs no account on the target, then the full active flow. The validator watches and grades each area rather than blocking, so an overall "failed" still comes with a full per-area breakdown.
Landing and entry
The OpenCloudMesh site
The public site. The validator lives under the Validator link in the top nav.
The "Check a server" form
You give it a host and pick the mode. Active is left unchecked here, so this run is passive only. It also says up front that results are informational, not a certification.
Passive test
Step P1 - Passive report
Four of the eight areas run without an account. Secure connection passes, request signing fails, and discovery and signing keys come back needing attention. The share and token areas stay untested, since passive mode never runs the live flow.
Signing keys warn because the target does not publish a JWKS URL in discovery, so there are no keys to check. Request signing is the hard fail: the target does not advertise HTTP-signature support, so the validator cannot confirm it verifies inbound signatures.
Step P2 - Server discovery
Opening the discovery area. The validator did an uncached GET on
/.well-known/ocmand wants a proper 200 JSON document back, withenabled,apiVersion,endPoint, andresourceTypes.The warning is mostly the version: the target advertises OCM 1.2.0 while the validator pins 1.4.0. That is a soft warn, not a rejection, since it consumes by capability at call time rather than doing a version handshake.
Active test
Step A1 - Validator creates an invitation
The active run starts. The validator mints its own OCM invitation and shows the token for me to accept on the target.
Step A2 - The target side
Signed in to the target OpenCloud. The Personal space is empty, and ScienceMesh in the app list confirms OCM is enabled here.
Step A3 - Accept the invitation on the target
Pasting the validator's token into the target's Invitations app. It resolves the institution back to the validator, with no connections yet.
Step A4 - Connection registered
Accept worked. The target now lists Session Inviter as a federated connection.
Step A5 - Waiting for the return invitation
The validator flips to the reverse direction and waits for an invitation coming back from the target.
Step A6 - Target generates its invitation
On the target I generate a new invitation, described "Test Validator", to hand back.
Step A7 - Return invitation pasted back
That return token goes into the validator, ready to submit and close the trust both ways.
Step A8 - Both directions connected
Both connections now show on the target, so the two-way invite handshake is done.
Step A9 - Forward share, waiting to open
The sharing phase. The validator has shared a file out and waits for me to open it on the target.
Step A10 - Forward share arrives
hello-ocm.txtshows up under "Shared with me" on the target, so the forward share landed.
Step A11 - Forward file opens
Opening it on the target renders the content, so the peer served the bytes and the forward share reads end to end.
Step A12 - Waiting for the reverse share
Roles switch. The validator now waits for the target to share a file back, and times out if nothing comes.
Step A13 - Target creates a file
On the target I create
Share to validator.txtas the file to send back.
Step A14 - Give it some content
A quick edit so the file has real content before it goes out.
Step A15 - Share it back
Sharing it back to Session Inviter with Can view. This is the reverse OCM share.
Step A16 - Reverse share confirmed
The target lists it as Shared with Session Inviter, no public link involved.
Step A17 - Final report
Share exchange and capabilities pass, discovery and signing keys warn, and request signing fails because the target does not advertise HTTP-signature support, so the validator cannot confirm it verifies inbound RFC 9421 signatures. Notifications and access tokens weren't exercised. The suggestion is to turn on inbound RFC 9421 verification and finish the discovery and JWKS advertising.
- moved this from In progress to Done in SovereignTech Funded Activities
on Sep 14, 2026
