The two paths
There are two ways to claim conformance. Both are tested against the same specification. They differ only in who verifies the claim and which mark the implementer may display.
For endpoint vendors: a parental-controls app, a device or OS maker, a platform. You enforce OCSS Rules; you do not route envelopes, so the Trust List and its MUST / MUST-NEVER contract (§2) do not apply to you. No fee, no audit, no Trust List approval.
- Listed in the public registry as a self-attested Implementer
- No third-party verification. The claim is your own, on the record
- The mark reads "Implementer."
- Effort: map shipped capabilities, run the suite, file the attestation; measured in engineer-days, not quarters
- Timeline: listed on acceptance; you may display the Implementer mark the day your attestation is accepted. (Registry intake opens with the v1.0 suite, target Q3 2026.)
The implementation is audited by an approved third-party assessor against the OCSS conformance suite.
- Listed in the separate verified registry
- The approved-assessor list is set by the Trust Committee, which seats at ratification; until then it is published as it is finalized
- The mark reads "Certified."
- Cost: roughly $2.5k–$5k / year for the Tier 1 Certified track (audit + listing); higher participation tiers are a separate ladder, on Get Involved
- When you re-verify: annually, plus on each key rotation (≤180 days) and on re-test against new Rules as the spec advances
Two paths. Same spec. Different mark. The distinction the registry surfaces is the one that matters: who checked. If you ship a parental-control product and never route signed traffic, you are an Implementer (the free path) and you can stop reading at §5. Sections §2 and §6 govern routing intermediaries only.
Why an adopter implements once
The integration math is the whole pitch. Without a shared signal, every parental-control vendor wires up to every platform, OS, and carrier by hand: N×M bilateral integrations, each one a separate contract, schema, and on-call rotation. OCSS makes you implement the spec once: you read one signal and emit one signal, and the cost collapses to N + M. One conformance pass replaces a backlog of one-off vendor deals.
The mark is the second half of the return. A controlled, registry-resolvable certification mark is a market trust asset a procurement officer or a regulator can verify in one lookup, not a logo you self-print. You implement the Rules for the capabilities you ship; you get a public record that says you did, and a mark that resolves to it.
And it tells you your legal exposure before an auditor does. Each capability you claim maps to specific statute provisions: claim Tier and you implement the duty-of-care gate KOSA §4(b)(2) describes; claim Age and you implement CA AB 1043's OS age-signal ingest; claim Consent and Privacy and you implement COPPA 2.0's verifiable-consent and minimization duties. So a regulator auditing you for KOSA is auditing the exact capability the registry already shows you passed. The full crosswalk (which claim answers which provision) is the table in §7; the point is that your capability set is your compliance profile, not a separate document you assemble after the fact.
The MUST / MUST-NEVER contract
The Trust Framework holds intermediaries to a normative conformance contract that is binary. A party satisfies every item in both sets, or it does not hold Accredited status and never appears on the signed Trust List. The MUST set makes routing trustworthy. The MUST-NEVER set makes it safe. This contract binds Infrastructure intermediaries only (the routing layer), and not the endpoint Implementers covered in §1.
Earned, not claimed
The certification mark is granted only on passing the conformance suite and holding a valid Trust List entry.
v1.0 conformance contractAn accredited Infrastructure intermediary…
On the fourth MUST-NEVER. Non-re-identification is enforced cryptographically, not by promise. The two-layer envelope splits visibility: an Ed25519-signed outer carries routing metadata the intermediary needs, and the inner is JWE-sealed to the receiver's public key, so the intermediary never holds plaintext to correlate. The family_hash is domain-separated per receiver via HKDF-SHA-256(salt = receiver_pubkey, ikm = household_id, info = "ocss-family-v1"), a 32-byte output, so the same household resolves to a different value at each hop, and no stable join key links a child across intermediaries. Audience binding via RFC 8707 resource indicators keeps a token minted for one receiver from replaying at another. The full envelope schema is normative in the Standard, §2.2.
Trust tiers
Provisional → Verified → Accredited, with a future Tier 4. Higher tiers may route more sensitive envelope bands.
accredited routes RestrictedA party that offers fewer obligations than this contract may describe itself as "OCSS-compatible." It does not appear on the Trust List, and it MUST NOT route Gated or Restricted envelope types: for example, real-time CSAM or ICAC referral signals.
The MUST / MUST-NEVER set governs Infrastructure intermediaries: parties that route signed envelopes between issuers, verifiers, and gatekeepers. It does not apply to Implementers on the free self-attestation path: an Implementer (a parental-controls app, a device maker, a platform) self-attests to the OCSS Rules and never touches the routing layer. An intermediary carrying CSAM or ICAC traffic is held to the binary Trust Framework contract; an endpoint that enforces a tier gate is not.
Threat model: the adversary each rule assumes
The MUST-NEVER set is written against a specific adversary: an intermediary that is honest-but-curious at best and compromised at worst, and that can see every outer envelope it routes. Each defense names the attack it stops.
Token replay (same receiver)
A captured envelope re-submitted within one receiver's domain. The outer signature covers a nonce and issued_at per RFC 9421; receivers reject duplicate nonces inside the freshness window, so a replayed token does not re-fire a decision.
Cross-intermediary correlation
Two colluding hops trying to link the same child. family_hash is HKDF-SHA-256 keyed to the receiver's public key (salt = receiver_pubkey, ikm = household_id), so the same household yields a different 32-byte value at each receiver. There is no shared key to join on, even under collusion. And because the intermediary only ever sees the outer envelope, it has no plaintext to correlate by content; timing-and-volume analysis is all that remains, which the v1.1 formal pass (§7) is scoped to bound.
Replay at a different audience
A token minted for receiver A submitted to receiver B. RFC 8707 resource indicators bind each token to one audience; B's verifier rejects an audience mismatch.
Key compromise
A leaked signing key. The MUST rule caps key lifetime at ≤180 days on a published cadence; the Trust List carries current JWKS, so a rotated-out or revoked key stops verifying network-wide within the ≤24h cache window.
Stricter-rule downgrade
An intermediary silently relaxing a BLOCK to a WARN. The decision is signed by the issuer end-to-end inside the sealed inner; an intermediary cannot rewrite a decision it cannot decrypt, and any tampered outer fails signature validation.
Out of v1.0 scope
A malicious intermediary running unaudited code is bounded by audit + rotation, not yet attested. Replacing operator trust with TEE/enclave attestation is the Tier 4 roadmap item (§6), tracked for v1.1. Stated, not overclaimed.
What the contract anchors to in law
The MUST set is no abstract hygiene exercise. Each obligation maps to a regulatory expectation.
The audit row per envelope is the evidentiary trail a CSAM-reporting regime expects (US 18 U.S.C. § 2258A).
The annual independent audit and real-time status page answer the auditability and transparency duties of the EU DSA.
The rule taxonomy lets an Implementer say it implements KOSA, COPPA 2.0, the UK Online Safety Act, the EU AADC, and pending CA AB 1043 / NY S9051. See the statute map and §7 below.
The conformance test suite
The OCSS v1.0 conformance suite is in drafting. Every implementation is tested against the rule list of each capability area it claims. A claim of "Tier conformance" means the implementation passed the tests covering tier-signal ingestion, tiering-policy correctness, decision tracing, and cited-rule emission.
One layer is not like the others. Of the nine areas in the spec, Charter (§1) is a governance layer: it is the canonical document the standard is written against, not a runtime capability you build and test. You implement the eight runtime capabilities: Age, Tier, Consent, Block, Alert, Privacy, Audit, Receipt. Each carries its own rule list; the ~100 categories are partitioned across these eight (e.g. Age holds age_gate and os_age_signal_ingest; Tier holds ai_chatbot_tier_gate; Block holds nfk_hard_block). The rule list for a capability is its test list: to find the runnable assertions for, say, Age, you read the Age section of the Standard, take the categories listed there, and the suite carries one deterministic assertion per category-and-boundary. Claim a capability, inherit its rule list, run those assertions.
The shape is settled even where the count is not. Each test is a deterministic assertion: a fixed input, the rule it exercises, and one binary outcome. No grader judgment, no scoring band. A failed assertion is no deduction. It names the exact rule id and boundary that did not hold, which is the remediation: fix that rule's handling, re-run that assertion. A draft assertion from the Tier capability reads like this:
draft-test TIER-001 tier_gate · age-band evaluation given age_band = "13–17", content_tier = "T3" when the Tier capability evaluates access then decision == BLOCK and a cited rule is emitted (e.g. cite[] ⊇ ["NY-S9051"]) and the decision is traceable to one rule id draft-test TIER-002 tier_gate · boundary at the band edge given age_band = "13–17", content_tier = "T2" then decision == WARN (not BLOCK, not ALLOW)
Two things matter to a reviewer reading those stubs. The expected output is a single enumerated decision (ALLOW / WARN / BLOCK), so a pass is unambiguous. And every passing decision must carry a cited rule id, which is what makes the same machinery double as an audit artifact: the test that proves the gate fires is the structure that proves why it fired.
What a conformant OCSS Rule signal looks like
You do not need to open the full spec to start. A Rule signal is typed JSON: a category from the ~100-category taxonomy, the inputs it consumed, the enumerated decision, and the cited statute that justifies it. An assertion passes when this shape is well-formed and the decision matches. (The normative field-by-field definition lives in the Standard, §1.1: What a Rule is.)
{
"capability": "tier", // 1 of 9 capability areas
"rule": "ai_chatbot_tier_gate", // a category in the taxonomy
"age": "13-17", // derived band, never identity
"jurisdiction": "US-NY",
"decision": "BLOCK", // ALLOW | WARN | BLOCK
"cite": ["NY-S9051"], // statute that justifies it
"spec": "OCSS-v1.0"
}
Verify before you enforce
An Implementer that consumes a signal runs the same five steps every time, in order. This sequence is itself testable. The suite feeds tampered and well-formed envelopes and asserts the decision.
- Fetch the issuer's public key from the Trust List's cached JWKS (refresh ≤24h).
- Verify the
outerEd25519 signature over the RFC 9421 signature base; reject on mismatch, expired key, or revoked entry. - Check the audience: the RFC 8707 resource indicator must name your receiver. Reject a token minted for anyone else.
- Decrypt the JWE
innerwith your private key; read the typed Rule signal above. - Enforce the
decisionon your surface, and emit a signed Receipt carrying the samecite[]: the audit artifact.
Where the decision lands: enforcement surfaces
One verified signal, many enforcement points. The Implementer mark covers whichever of these you ship; you do not have to ship all of them.
Routing parties: how validation is checked
If you route signals (the Infrastructure intermediary role, §6), two of the validation steps are mechanical. A DNS TXT record at the manifest host proves domain control, and a signed metadata manifest is published at a well-known path. The exact formats below are draft and finalize with the v1.0 suite:
# DNS TXT — proves control of the routing domain (draft) _ocss-trust.intermediary.example. TXT "ocss=v1; jwks=https://intermediary.example/.well-known/jwks.json" # Signed metadata manifest (draft) GET https://intermediary.example/.well-known/ocss-manifest { "tier": "verified", "jwks_uri": "…/jwks.json", "routes": ["open","gated"], "sig": "…" }
The signed Trust List is the registry these manifests resolve into. Its entry format, the ≤24h cache contract, and the eIDAS-style signing model are specified in the Standard, §2.3, and the live registry is at the Trust List.
What you'll actually run: the artifact format
For a tech lead deciding whether to commit engineering cycles, here is the integration contract as it stands. Assertions ship as declarative YAML fixtures (the given / when / then stubs above are that YAML, rendered) plus a CLI runner (ocss-conform) that you point at your implementation's HTTP endpoint or link as a library. It exits non-zero on any failed assertion and writes a JUnit-format report, so it drops into a CI/CD step like any other test gate. The envelope schema those fixtures assert against is the one in the IETF Internet-Draft draft-phosra-ocstf-00. That draft is the authoritative wire format for the Trust Framework layer; the Rule-signal JSON above is normative in the Standard §1.1. Rule versions are pinned: a fixture names the spec version it tests against ("spec":"OCSS-v1.0"), so a new Rule landing mid-deployment does not silently change your pass/fail. You re-test against the new version on your own schedule, within the deprecation window (18 months, RFC-first). Suite, runner, and per-capability counts publish together, targeting Q3 2026.
Want a seat at the table while the conformance bar is being set? Join a working group through Get Involved, or write [email protected].
The certification mark: earned, not claimed
The OCSS certification mark MAY only be displayed by an entity that passes the conformance suite for every capability it marks as conformant, and holds a valid Trust List entry (for the Certified path and for any routing party).
A controlled mark
It is not a logo a vendor can paste onto a website by intent. The right to display it is tied to a verifiable registry entry, and a reader who sees the mark can resolve it to a live record.
Tied to a live registry entry
If the entry lapses (a missed key rotation, an expired audit, a failed re-test), the right to display the mark lapses with it. If the mark does not resolve to a live registry record, the claim is invalid.
- Display right resolves to a registry record
- Lapses with the entry it points to
- Cannot be self-asserted by intent
How to claim conformance
Conformance is a living state, not a one-time stamp. Seven steps from reading the spec to staying listed.
- Read the spec. Identify which of the nine capability layers your implementation covers and which Rules each one ships.
- Map your implementation. For each claimed capability, document how it satisfies the Rules in that capability's rule list.
- Choose a path. Self-attest as an Implementer (free, public registry), or pursue independent Certified assessment.
- Run the suite. Execute the conformance suite for each claimed capability: deterministic assertions like the
TIER-001stub in §3, one binary decision per test. (Suite and per-capability counts in drafting; target Q3 2026.) - Submit. File your self-attestation, or engage an approved assessor and submit the audit result.
- Get listed. On acceptance, your entry appears in the public (Implementer) or verified (Certified) registry, and, for routing parties, on the signed Trust List.
- Maintain it. Rotate keys ≤180 days, hold a current annual audit (Certified / Accredited), and re-test against new Rules as the spec advances.
Trust Framework intermediary tiers
Parties that route signals (the Infrastructure intermediary role) are organized into trust tiers that differ by how identity and conformance are validated, and by which envelope bands the tier may route. These are distinct from the adopter participation ladder: an intermediary tier is about routing trust, not membership.
| Tier | Self-service | Validation | May route |
|---|---|---|---|
| Provisional | Yesgenerate a JWKS; publish signed metadata at /.well-known/ocss-manifest; register the domain with a Trust List operator | None automatic | Open only |
| Verified | Yes | DNS TXT + manifestpasses automatically | Open + Gated |
| Accredited | No | Conformance suite + SOC 2 Type II + governance approvalapproving body is the Trust Committee, seated at ratification; on approval, placed on the signed eIDAS-style Trust List by the list operator | Open + Gated + Restricted |
Provisional & Verified: open-door
Any party that publishes a signed metadata manifest and passes automated validation can self-declare up to Verified standing, and begin routing low-sensitivity (Open) and DNS-validated (Gated) envelope types.
Accredited: different in kind, not degree
Requires completing the conformance suite, passing an independent SOC 2 Type II security audit, clearing governance approval (the Trust Committee, post-ratification), and being placed on the signed Trust List. Only Accredited intermediaries may route Restricted envelopes (real-time CSAM signals, ICAC referrals, emergency-flag payloads), where the entire MUST-NEVER set is most load-bearing.
Who operates the Trust List, and how you integrate
The Trust List is a machine-readable, cryptographically signed registry of accredited intermediaries, modeled on the EU Trusted List (EUTL, in operation since 2014). The list operator role transfers to the Trust Committee at ratification; Phosra holds editorial stewardship of v1.0 only, until then. Integration is pull-based, not a vendor hub: fetch the signed list, verify its signature, cache it for ≤24h, and resolve each intermediary's JWKS from its entry. The entry format and signing model are in the Standard, §2.3; the live registry and its tiers are at the Trust List. Federation requires plurality, since a single "+" is N×M renamed, so the network is only "green" at ≥3 accredited operators.
Future Tier 4: v1.1 roadmap
A tier above Accredited, reserved for intermediaries that can cryptographically prove, via TEE / enclave attestation, that they are running the exact audited binary, replacing operator trust with attestable trust. Tier 4 is a roadmap item, not a v1.0 conformance gate.
What a conformance claim means in law
OCSS Rules exist so an implementer can build to one machine-readable contract instead of 91 statutes across 30+ jurisdictions. A regulator should be able to see the mapping, not take it on faith. A representative slice is below; the full crosswalk lives in the Standard. Pending and not-yet-enforced measures are framed as "implements", not "compliant with enforced law."
| Statute | Jurisdiction | OCSS capability | Example rule / cite |
|---|---|---|---|
| KOSA pending | US-Federal | Tier · Audit | duty-of-care tier gate · cite ⊇ ["KOSA-§4(b)(2)"] |
| COPPA 2.0 / FTC COPPA | US-Federal | Consent · Privacy | verifiable parental consent · parental_consent_gate |
| 18 U.S.C. § 2258A | US-Federal | Receipt · Audit | CSAM-report audit trail · one immutable row per envelope |
| CA AB 1043 pending | US-CA | Age | OS-level age-signal ingest · os_age_signal_ingest |
| NY S9051 pending | US-NY | Tier · Block | AI-companion limit · ai_no_simulated_companionship |
| EU DSA | EU | Audit | independent-audit + transparency duty · annual SOC 2 + status page |
| EU AADC / GDPR Art. 8 | EU | Privacy · Consent | data minimization for minors · commercial_data_ban |
| UK Online Safety Act | UK | Block · Audit | illegal-content blocking · nfk_hard_block |
| UK AADC | UK | Privacy · Audit | age-appropriate design · algorithmic_audit |
| Australia OSA | APAC | Block · Alert | harmful-content controls + parent notice |
Who controls OCSS, and when. During v1.0 drafting (now), Phosra holds editorial stewardship: it maintains the spec text and the draft suite, but every breaking change ships RFC-first (published ≥30 days before adoption, 90-day public review for majors) so the process is open and contestable before anyone signs. Disputes during drafting are resolved through the working groups and the public RFC record, not behind a vendor's door. At ratification, authority over the spec, the conformance suite, and the Trust List transfers to the Trust Committee. Civil society is structurally embedded in a 9-seat Trust Committee. 3 of the 9 seats are reserved for named civil-society bodies (for example Common Sense Media, Roost, the EFF, FOSI, and the ACLU), non-removable except for cause. Accreditation decisions run on one organization, one vote, so a large implementer cannot accumulate weight proportional to market share. Every trust-list change carries a 72-hour public notice and comment period. De-accreditation requires a 2/3 Trust Committee vote plus a 30-day cure period. After ratification the Trust Committee is the standing dispute and ratification authority; no single participant (Phosra included) can ratify a version or grant a Trust-List placement alone. ESRB / MPAA / PEGI ratings are mapped to, not endorsed by, those bodies. See versioning and the Trust Committee charter.
Conformance is a claim that can be checked.
Read the spec, run the suite when it lands, and apply for certification through the coalition.