We wrote the reference implementation of OCSS. Now we run it for you.
Like Yubico for FIDO2.Conform in a few API calls: signed age checks, tier gates, tamper-evident receipts.
An individual IETF Internet-Draft (draft-phosra-ocstf-00), not yet working-group-adopted. Phosra implements it; it does not own it. Spec, rule registry, and conformance suite live at openchildsafety.com.
Live today: the signed succession record (§12.3) and the §9.4 attestation CSV. The public router and receipt rail ship in a later phase.
A hosted accredited router, and the Trust Framework API above it.
The routing-and-trust layer of OCSS — one sealed two-layer envelope, four lane verbs, a public signed Trust List, one binary contract. We wrote and golden-vector-tested the reference implementation, and run one accredited router on it.
One sealed two-layer envelope, every signal
Every signal — age attestations, parental directives, abuse alerts, audit records — travels in one format.
The headers a router reads to move a signal — nothing more.
JWE, ECDH-ES+A256KW / A256GCM. The router forwards it untouched — it holds no key to open it.
The cannot-decrypt property is structural, not a pledge.
Four lane verbs, one wire format
- BROADCASTone attestation, many consumers
- DIRECTIVEone control, many enforcement points
- CONSUMEingest a signal and act
- ATTESTwrite the proving record
Plus the gated EMIT qualifier for the abuse-signal lane.
Keys and trust, in one signed document
Every entry's DID resolves to a JWKS — envelope-signing keys and payload public keys — so sealing and signature-checking both run against one cached, signed document. No out-of-band key exchange. It's hash-chained across independent mirrors; a router that breaks the contract comes off it. We run the compiler; the document is public.
Six MUSTs, four MUST-NEVERs — binary, no partial credit
- Validate sender signatures
- Address every payload to the receiver's key
- One immutable audit row per envelope
- Publish a real-time status page
- Rotate keys on a ≤180-day cadence
- Pass an annual independent audit
- Decrypt payloads
- Retain contents past delivery
- Correlate routing metadata across families without consent
- Accept payloads that re-identify minors across intermediaries
We hold ourselves to the same contract every other accredited router holds. By design a Phosra-only federation reads RED: the Trust List computes Red below two accredited intermediaries (§11.2/§11.9) — which is why one router is never enough.
Integrate once. We eat the platform-API churn.
Apple and Google OS age signals, app-store state, certified euCONSENT-class assurance networks — each drifts on its own quarterly schedule. Phosra's accredited Issuer-adapter speaks all of them and emits one conformant OCSS envelope you integrate against once.
Every envelope carries signed provenance, so the original assurance level is preserved, never laundered up. The bridge is one-way and double-blind.
Their API change is our ticket, never your migration.
A record a regulator can replay — and a service level a miss has to answer for.
Every action on the rail leaves a signed, append-only Receipt: an envelope identifier, a decision, a signature — never payload, never PII, age only as a derived band. The reliability of the hosted operation is itself a published, measured number, not an adjective.
Hash-chained, not merely signed
Each audit row commits to the SHA-256 digest of the row before it, forming a single append-only hash chain, and the writer publishes periodic signed checkpoints of the chain head. Truncating or rewriting the record is detectable by any verifier holding a later checkpoint — tamper-evident, never merely forbidden. A correction is a new Receipt referencing the original by id, so history is preserved and the correction is itself evidence.
Verifiable without trusting the writer
A regulator can request every Receipt for a jurisdiction and provision over a date range and verify each Ed25519 signature against the signer's published JWKS — no cooperation from us required. An attestation that can only be confirmed by asking its author is not an attestation. A multi-week subpoena exercise becomes a single-pass query.
An SLO per cell, witnessed independently
Restricted-path traffic publishes a service-level objective — availability target, p99 added latency, maximum time-to-notify — per cell of the per-OS capability manifest, with the declared target and the measured attainment shown side by side on the Trust List entry. Restricted cells never rest on self-measurement alone: counterparty Receipt timestamps at both ends of every hop are the independent witness the rail produces for free.
A missed SLO emits a breach Receipt
When a Restricted signal is delayed or dropped, the miss is allocated in evidence, not litigated: an SLO miss emits a breach Receipt on the same rail — no new endpoint — attached to the SLO cell that missed it. The guarantee this document makes end to end is attributability: who owes what is a recomputable fact off the signed record.
What's live today, and what ships in the next phase.
Implying a running public network you can't hit yet would be the one thing that loses a regulator's trust, so we draw the line plainly. The whole Trust Framework is built and golden-vector-tested — the signed envelope, the hash-chained Receipt rail, the Trust List compiler, the closed-vocabulary parsers. But only two public endpoints are live today; the public router-ops and receipt-rail API is the next phase, not a thing you call this afternoon.
Two signed public reads, live now
Two endpoints are public and serving today, and both are signed artifacts you verify rather than claims you take on faith:
- GET /.well-known/ocss/succession
The Ed25519-signed succession record (OCSS §12.3) — steward of record, transfer status, and succession plan, so you can verify the chain of custody instead of reading a press release.
- GET /api/v1/decisions/export.attestation.csv
The §9.4 attestation export — aggregate-per-category-and-period rows, signed by the issuing key, zero student identifiers. A district's annual E-rate certification as a recomputable claim, not a federal checkbox.
The public router-ops & receipt-rail API
The full public Trust Framework API exists in code and passes its golden vectors today; it becomes a public endpoint in a later phase. Until then, these are not things you can call against a running public network:
- POST /api/v1/policies/{policyId}/rules
the signed Rule write — the most-exercised write on the rail
- POST /api/v1/webhooks/inbound/{source}
the single inbound surface every external attestation rides (the N+M adapter door)
- POST /api/v1/alerts
the EMIT side of the abuse-signal Alert lane
- GET /api/v1/rules/{ruleId}/provenance
who changed the rules, on what authority — as a recomputable read
We say which is which, never the reverse. The developer docs carry the same what's-live-vs-next-phase table at /developers.
Speak OCSS in an afternoon. We run the rest.
One integration against the reference implementation, signed receipts on every decision, and an adapter that takes the platform-API churn so you don't. See what the operation costs, start building against what's live today, or build with us while the next phase ships.
Building something early? Build with us as a design partner →
Verify the standard itself at openchildsafety.com — spec, rule registry, and conformance suite.