Skip to main content
The OCSS Trust List is the signed document that enumerates every accredited party on the network. Getting on it is the precondition for originating signed operations — a write receipt, a routing attestation, an enforcement confirmation. This page describes what that means today. The production Trust List has zero third-party entries as of this writing — every accreditation there goes through the application-then-review process above. The full eligibility criteria and SLA are documented at Production Accreditation.
Building a platform kids use — not issuing rules on a family’s behalf? This page (and the roster below) is written from the Issuer/Provider side. Start with the Platform Quickstart instead — the Gatekeeper guide for apps, OS vendors, and networks that enforce signed rules. (Existing createConnectReceiver receivers: the legacy lane.)

Get a sandbox DID — self-serve, no email required

The fastest path to a signed round-trip is a sandbox provisional DID. It is bring-your-own-key: you mint the Ed25519 pair, and register its public half. The census never mints a key for you.

1. Mint your Ed25519 key pair

2. Register the public key

public_key_b64url is required — omit it and the census returns 400 public_key_b64url is required.
200 response — this is the exact shape (live-verified against the sandbox census):
The census now returns your bound key_id (and bare kid) directly in this 200 — it is did:ocss:<slug>#<YYYY-MM>, the current UTC month at registration. Use key_id verbatim as your SenderKey.keyID. (You can still confirm it against your published entry — step 3 — but you no longer have to.) A self-registered DID is a generic provisional participant (publisher org Self-registered sandbox participant). It is not scoped to a role.
Your signing key id is did:ocss:<slug>#<YYYY-MM> — not a name you choose. The census binds your key under a bare kid equal to the current UTC month at registration time (e.g. a DID registered in July 2026 gets kid 2026-07). Bespoke kids like did:ocss:my-org#my-org-2026-06 appear in signing examples on this site only for seeded roster DIDs (e.g. loopline) that publish that kid; a self-registered DID does not. Signing with a kid that is not the one bound in your entry fails 401 (kid-not-in-entry). Always read your kid back from your published entry (below) and use it verbatim as your SenderKey.keyID.

3. Read back your bound kid

Your full signing key id is therefore did:ocss:my-org#2026-07. Build your SenderKey as { seed, keyID: "did:ocss:my-org#2026-07" } (the seed is your private key’s 32-byte Ed25519 seed).
roles is informational; entry_role is the only field that sets a Trust-List role. The census stores a roles: [...] array verbatim on provisional entries but does not act on it — it does not make you an “issuer” or “gatekeeper”. The only field that sets a real Trust-List role is entry_role, and self-register accepts exactly one value: verifying-agency (the §5.4 open-assessor lane). Any other entry_role returns 400 invalid_entry_role. For a normal platform or provider integration you need neither — a plain provisional DID signs rule writes and mints endpoints just fine.
Now you can call POST /api/v1/policies/{policyId}/rules with an RFC-9421 DID-signed request (signed with did:ocss:my-org#<YYYY-MM>) and receive a real router-signed write receipt, verifiable against the sandbox Trust List root.
The phosra register / phosra doctor CLI is a convenience wrapper over the same endpoint. Because a self-registered DID is role-agnostic, a --role flag (if you pass one) is cosmetic — it maps to the informational roles field, not entry_role. phosra doctor confirms the full sandbox round-trip is green (consent 201, rule 201, receipt verified to trust-list root).
Sandbox-only. Provisional DIDs registered via this path are on the sandbox census only (phosra-api-sandbox-production.up.railway.app — the stable testing endpoint). They do not appear on the production Trust List for live accredited traffic. Production accreditation is a separate governance step — see below.

Accreditation lanes (§5.4)

The OCSS specification defines three accreditation lanes based on the capability band you intend to operate on (§5.4):
Tier disambiguation. The Trust List entry for each party carries a tier field: accredited or provisional (§3.6). The three accreditation lanes (§5.4) determine which tier you enter — a party on the Implementer lane enters as provisional; passing an independent audit reaches accredited. These tiers are separate from the four capability bands (§3.6): a band governs which envelope types you can carry; a tier governs what the network trusts you to sign.

Per-role onboarding artifact

The one real difference between roles at onboarding time is the artifact you register on the Trust List. The accreditation lane and the initial contact path are the same for all roles today.

Issuer

Onboarding artifact: Ed25519 signing key registered on the OCSS Trust List Register an Ed25519 signing key under your did:ocss: identifier. Signed rule writes you originate are then verifiable by any party holding the Trust List (§11.9). The write operation is POST /api/v1/policies/{policyID}/rules (§8.3.1). Live status: Conformance Status lists the live vs. preview state for the operations backing each role.

Verifier

Onboarding artifact: Trust List read access — subscriber record linking family policy to the Verifier’s accredited DID Register your accredited DID and request a subscriber record linking it to the family policy stores you service. CONSUME-side subscription management is GET/PUT /api/v1/alerts/subscriptions (§8.3.3); inbound signal ingest is POST /api/v1/webhooks/inbound/{source} (§8.3.2). Live status: Conformance Status lists the live vs. preview state for the operations backing each role.

Gatekeeper

Onboarding artifact: enforcement-endpoint URL declared on the Trust List accreditation record Declare an enforcement-endpoint URL on your Trust List accreditation record. The census POSTs signed enforcement confirmations to that URL (§8.3.8). The URL must be reachable and respond per the enforcer floor at §4.6. Live status: Conformance Status lists the live vs. preview state for the operations backing each role.

Infrastructure Intermediary

Onboarding artifact: routing attestation: an accredited Trust List entry as an independently operated router node (§11.9 federation floor) Register as an independently operated router node (§11.9 federation floor). Your routing attestation — a signed Trust List entry declaring the envelope bands you route and the SLO cells you operate — is the onboarding artifact (§8.3.6, §5.4). The federation floor requires at least three independently accredited routers; one is operated today. Live status: Conformance Status lists the live vs. preview state for the operations backing each role.

Economics and the covenant

Royalty-free vocabulary. The OCSS rule vocabulary — all rule categories, the verb model, the envelope format — is royalty-free per §5.5. No licensing fee is owed for implementing the specification vocabulary. The cost schedule for accreditation paths is published in the specification at openchildsafety.com (§5.5). It is not reproduced here, because the numbers belong to the specification, not to Phosra’s documentation.
§12.2 covenant — not yet a signed instrument. Joining as a founding signatory converts to a covenant, not yet a signed legal instrument. The distinction is honest and material: a covenant is a public commitment; it does not create a legal instrument until the governance body designates one (§12.2). OCSS is a pre-release standard — an individual IETF Internet-Draft, not yet ratified by any standards body. Conformance evidence is something a regulator can weigh; it is not a compliance determination or a safe harbor (§5.1).

Next steps

Sandbox (self-serve, start here)

  1. Generate a did:ocss: identifier with an Ed25519 signing key. @openchildsafety/ocss includes key generation utilities; or use openssl genpkey -algorithm ed25519 for the raw PEM.
  2. Identify your role(s) from the four §3.2 roles — you may hold more than one.
  3. Register on the sandbox Trust List via POST /api/v1/advisors/self-register (see above) — no email required.
  4. Run phosra doctor to confirm a green sandbox round-trip.

Production accreditation

Production accreditation is governance-gated — it requires a review of your integration and accreditation lane (§5.4). Apply for accreditation in the console; a Phosra reviewer approves it. This is an application-then-review process, not instant self-serve. The full process, eligibility criteria, and SLA are documented at Production Accreditation. To start:
  1. Complete the sandbox round-trip first (phosra doctor exits 0).
  2. Submit an application via POST /api/accreditation-apply with your DID, intended role(s), and intended use case. See Production Accreditation for the full field list.
  3. A Phosra reviewer approves or rejects the application; there is no automatic admission.
Submitting is self-serve today; the decision is not. POST /api/v1/accreditation/applications is live on the production census — verified 2026-07-26: it answers 400 invalid_proposed_did: must be did:ocss:<slug> (registered and validating) against a bogus-path control returning plain-text 404 page not found. The production census names this same endpoint in its own 403 self_register_sandbox_only response, so it is the intended path.What is not self-serve is admission: a reviewer approves, and approval mints a verified entry — accredited still requires a verifying-agency attestation. So apply now rather than waiting; just don’t expect instant production admission.Note also that this endpoint is absent from the partner sandbox census (plain 404) — submit against the production census.
The Conformance Status page tracks the live vs. preview split for every surface.

Next


If the standard and this mirror ever conflict, the standard (at openchildsafety.com) wins. Authoritative text at openchildsafety.com.