OCSS — Open Child Safety Specification

§0The two layers

OCSS is a single umbrella standard composed of two layers. The split mirrors how FIDO2 separates WebAuthn (what a credential is) from CTAP (how it travels between authenticator and client): one layer names the meaning, the other moves it and decides who is trusted to assert it.

OCSS Rules define what a child-safety signal means. A Rule is a typed, named category: age_gate, ai_chatbot_tier_gate, nfk_hard_block, csam_reporting, and roughly a hundred others, each traceable to one or more statutes. Rules are the vocabulary. They say nothing about transport.

The OCSS Trust Framework defines how a signal moves and who is trusted to move it. It specifies a two-layer signed envelope, an eIDAS-style Trust List of accredited intermediaries, the role layers a federated network needs, and a binary MUST / MUST-NEVER conformance contract. The Trust Framework carries OCSS Rules as typed payloads, the way CTAP carries WebAuthn assertions without needing to understand them.

OCSS Rules define what a signal means; the OCSS Trust Framework defines how it moves and who's trusted, like WebAuthn + CTAP under FIDO2.

A conformant implementation MAY implement OCSS Rules alone (an endpoint that evaluates and enforces typed rules locally) or both layers (a party that also routes signals across the network). The two layers version independently and are documented separately below.

§1OCSS Rules

§1.1What a Rule is

A Rule is the atomic unit of the standard: a typed, named obligation derived from law. Each Rule answers one question, what must happen to a request, and why, in a form a machine can evaluate the same way on every surface. A platform that implements os_age_signal_ingest consumes an OS-level age band identically whether it sits behind DNS, an MDM profile, a router, an operating system, or an app-store install gate. The Rule is the contract; the surface is an implementation detail.

Every Rule carries a stable identifier, the capability layer that implements it, the statutes it traces to, and the decision it produces (typically Allow / Warn / Block). Rules are additive across minor versions and never silently redefined: a change to a Rule's meaning is a breaking change and follows the deprecation process in §4.

Build to the spec, not to the statute. A platform implements one typed Rule once; as the underlying law moves, the Rule's statute mapping updates without the platform rewriting enforcement code.

What a Rule looks like to the family. A Rule is machine-readable, but it terminates in something a parent and child actually see. When nfk_hard_block fires on a title rated "Not For Kids," the child gets a block screen (the request never completes) and the parent's app receives a timestamped Alert (the §7 capability) naming the title and the Rule that stopped it. When parental_consent_gate fires, the child sees a "waiting for a parent" state and the parent gets an approve/deny prompt; nothing is collected until they answer. A parental-controls vendor maps each capability to existing UI (a block screen, an alert feed, a consent inbox, a screen-time report) without inventing new concepts. The Rule decides what happens; the vendor owns how it looks.

§1.2The taxonomy (~100 categories)

OCSS Rules currently define ~100 typed categories. They span the full surface of modern child-safety obligation, including:

• age_gate · os_age_signal_ingest: verify and consume age signals across OS, app, and household.
• ai_chatbot_tier_gate · ai_no_simulated_companionship: gate AI products by risk tier; prohibit minor access to simulated companionship.
• csm_privacy_tier_gate · nfk_hard_block: evaluate a civil-society privacy program's Pass/Warning/Fail tier; hard-block "Not For Kids" titles.
• parental_consent_gate · screen_time_report: mediate verifiable parental consent; generate parent-facing usage reports.
• commercial_data_ban · algorithmic_audit: prohibit commercial sale or sharing of minor data; require algorithmic transparency and audit.
• csam_reporting: route detection events to the mandated reporting channel with chain-of-custody.

The taxonomy is the standard's content layer and grows by RFC, never by fiat. Public statements use the "~100" framing deliberately. The registry reconciliation between code, type declarations, and statute mappings is itself tracked as an open work item, and OCSS does not assert a false-precision count.

§1.3The nine capability layers

Every Rule is implemented by exactly one named capability. There are nine layers (one Charter plus eight runtime capabilities), and conformance is tested per layer (see Conformance). A note on the section numbers in the table below: the § column gives each capability's home section in the full specification (Charter at §1, the runtime capabilities at §3 through §10), where its complete rule list and normative text live. The table here is the index, not a substitute for those sections; this page summarizes the contract that §3–§10 state in full.

Each runtime layer is a separate conformance claim, tested against that layer's own rule list. An implementation may certify a single layer (an OS vendor that only ingests age signals claims Age alone) or the full stack. The mark names exactly which layers were verified, so a buyer can read a claim of "Age + Tier + Block, Certified" and know what was and wasn't audited. Per-layer test counts are published with the suite (see Conformance); OCSS does not publish counts it has not finalized.

§1.4How a Rule maps to statute

OCSS is built on the law, not instead of it. Each Rule cites the statutes and recognized standards it implements; the registry currently traces to 91 laws across 30+ jurisdictions (54 enacted, 22 proposed, 7 pending, 5 under injunction, 3 passed). A single Rule frequently satisfies several statutes at once: parental_consent_gate traces to COPPA (16 CFR § 312.5), the COPPA 2.0 amendments, KOSA's access-notification duty, and the App Store Accountability Act (UT SB 142, TX SB 2420) simultaneously. Citations carry jurisdiction and section so a policymaker can check the mapping: ai_no_simulated_companionship cites NY S9051 § 2(b) (the chatbot prohibition reaching minors aged 13+); the Tier and Privacy layers cite CA AADC § 22675 (the duty owed where a service is likely accessed by children, including digital advertising to minors).

Pending law is implemented now, not after enactment. Several mapped statutes are not yet enforceable. KOSA is pending in Congress and is not law; California AB 1043 (the OS-level age-signal mandate) is enacted but phases in, and similar bills are pending in other states. OCSS implements these Rules today so that when a provision is enacted or its effective date arrives, enforcement is already live: no spec revision, no re-integration, no scramble. The standard traces legislative intent; ratification of the statute simply activates the enforcement path the implementer already wired. Accordingly OCSS describes a Rule as one that implements a statute, never as making an implementer "compliant with enforced law." OCSS implements; it does not endorse, and it does not overstate the legal status of any provision it maps to.

§1.5What an adopter implements, and why it pays

The integration math is the whole pitch. A parental-controls product that wants signals from N platforms and serves M downstream surfaces faces, under the status quo, an N×M lattice of bilateral deals: a separate contract, key exchange, data agreement, and audit obligation with every platform, re-negotiated every time either side ships. Implement OCSS once and that collapses to N+M: you build to one typed contract, and any conformant platform on the Trust List is reachable through it. You add a platform by it appearing on the list, not by signing with it.

What you actually build. Concretely, an adopter implements the capability layers it needs (most parental-controls vendors start with Age, Block, Alert, and Consent) by (a) consuming typed Rule JSON (the shape in §3), (b) running the verify-before-enforce sequence so a Rule is only acted on after its signature checks against the Trust List, and (c) rendering each decision in the UI you already have. You do not build a new policy engine; you map four capabilities onto a block screen, an alert feed, a consent inbox, and a usage report.

Migration from your COPPA logic is incremental, not a rewrite. The hand-coded COPPA/state-law conditionals already in your product map directly onto Rules: your existing under-13 consent gate is parental_consent_gate, and your data-sale block is commercial_data_ban. The budget case is that you stop maintaining that logic per-jurisdiction: today a new state law means a sprint of conditionals and a fresh legal review; under OCSS the Rule's statute mapping updates upstream and your enforcement code does not move. The cost is one integration plus per-layer certification; the return is retiring the bilateral-deal backlog and never re-coding enforcement when a law shifts.

A worked example. Take a parental-controls vendor that today hand-maintains under-13 consent logic for COPPA, California's AADC, and a handful of state codes, and pulls age signals from four platforms through four separate integrations. Mapping its three existing conditionals onto parental_consent_gate, commercial_data_ban, and os_age_signal_ingest is a matter of relabeling decisions it already computes. The verify-before-enforce client and the Trust List fetch are the genuinely new code, and both are small, well-specified, and shared across every Rule. The recurring win is structural: the four bilateral platform integrations collapse to one OCSS client plus whatever platforms appear on the Trust List, and the next state law that lands updates the Rule's cite[] upstream instead of opening a ticket in your codebase. We are not publishing day-count or dollar benchmarks we cannot yet stand behind from shipped pilots. The honest claim is the shape of the curve (N+M, not N×M; statute churn absorbed upstream), and the pilot program below exists precisely to produce the numbers.

You can pilot before Q3 2026; you do not have to wait for ratification. The certification suite finalizes at ratification, but the Rule taxonomy and the envelope format are stable enough to build against now. An early adopter joins as a Tier 0 Implementer (free, self-attested, listed on the public registry), wires the four capabilities against the field vocabulary in §3.3, and gets an interim conformance review from the steward against the draft suite, so when the suite is final at Q3, the path to the audited Certified mark is a re-run, not a fresh integration. Tier 0 is the on-ramp, not the destination: it is self-attested and risk-aligned by design. A self-attested mark is appropriate for an implementer that has not yet routed Restricted-band signals, and the audited Tier 1 / Accredited path is what a vendor moves to before it asserts certified enforcement to a procurement team or a regulator. The interim-review pathway and the early-adopter terms are on Conformance.

The certification mark is a market asset, not a checkbox. A verified Certified claim (Tier 1) names exactly which capability layers an independent assessor audited ("Age + Block + Alert + Consent, Certified"), so a buyer, a platform partner, or a regulator can read the claim and trust it without re-auditing you. In a market where every vendor asserts "COPPA-compliant," a third-party-verified, machine-checkable mark is something you can put in front of an enterprise procurement team. The mark, the two tiers (self-attested Implementer vs audited Certified), and the assessor process are specified in Conformance.

Where liability sits. OCSS is explicit about the chain so an adopter can scope its exposure. A Receipt records, for every signal, who issued it, which intermediary routed it, and who enforced it — each over its own signature. If a routed signal is lost in transit, the gap is attributable to the named intermediary, not the receiver; if a signal arrives but the receiver enforces the wrong Rule, the receiver's enforcement Receipt shows it. The standard fixes responsibility for delivery and verification at the signing party for each hop; it does not reassign a vendor's existing statutory duty to the families it serves. OCSS gives you the evidence to apportion fault, not a shield from it.

§2OCSS Trust Framework

Status: Draft v0.1. Filed at the IETF as draft-phosra-ocstf-00. Proposed for stewardship under the Linux Foundation Agentic AI Foundation (AAIF), the body that adopted the Model Context Protocol in December 2025.

OCSS Rules say what a signal means. The Trust Framework says how it crosses the network, and refuses to let any single party become the chokepoint.

§2.1The problem it solves

A child-safety vendor that must integrate with N platforms and serve M downstream providers faces N×M bilateral integrations: separate contracts, key exchanges, and audit obligations for every edge. Routing everything through one private hub does not fix this; it hides it. "N+M with one + is N×M renamed." The Trust Framework collapses the graph to N+M honestly, by defining an open protocol that multiple accredited intermediaries can implement simultaneously: none of them required, all of them substitutable.

§2.2The signed envelope

Every signal crosses the network inside a two-layer signed envelope. The outer layer is visible to the routing intermediary; the inner layer is sealed to the receiver and opaque to everyone else.

• outer: routing metadata plus the sender's Ed25519 signature. The intermediary reads this, signs over it to produce its audit row, and routes. It contains the chosen intermediary's audience, an issued-at timestamp, and a per-request nonce that defeats replay. No personally identifiable signal content lives here.
• Nonce consumption (replay defense). Every intermediary MUST maintain an immutable, append-only record of consumed nonces and MUST reject any envelope presenting a nonce already delivered to that intermediary. The nonce is consumed on first valid delivery; a second presentation (captured wire traffic, a retried request, a malicious replay) is dropped at the routing layer before the payload is ever forwarded. Replay is foreclosed at the intermediary, not papered over downstream.
• The freshness window, quantified (store-exhaustion defense). The nonce store is bounded by the issued_at freshness window, and v1.0 fixes that window at ±300 seconds of the verifier's clock: an envelope whose issued_at is more than five minutes old, or more than five minutes in the future, is rejected on signature-verification grounds before its nonce is ever recorded. This is the answer to a nonce-store pre-population attack: an adversary cannot force the store to grow by minting envelopes with valid-looking future timestamps, because a future-dated envelope outside the window is dropped and never inserts a nonce. The store therefore holds at most one window's worth of legitimately-delivered nonces and self-prunes; entries are expired once their issued_at falls behind the trailing edge, since a replay of an expired nonce already fails the freshness check on its own. Bounding the window also caps the store's contribution to a DoS surface (see §2.7); the ±300s figure assumes loosely-synchronized NTP clocks and is itself an RFC-tunable parameter, not a magic constant.
• inner: JWE-sealed to the receiver's public key. The intermediary cannot decrypt it. It carries the receiver identity, the envelope type, the sealed payload (which carries the OCSS Rule), and a family_hash that pins a family to a stable opaque identifier per receiver, never a global one.
• family_hash domain separation (correlation defense). The hash is computed as HKDF-SHA256(ikm = family_id, salt = receiver_did, info = "OCSS-family-v1"), truncated to 128 bits. The receiver_did salt is the domain separator, so the same family resolved at two different receivers (or routed through two intermediaries to the same receiver) yields uncorrelated values, and no intermediary can join a child's activity across receivers. HKDF (RFC 5869), not a bare hash, is mandated so the construction is a proper keyed extract-and-expand rather than a guessable digest of a low-entropy family_id.

§2.3The eIDAS-style Trust List

Accredited intermediaries are published on a machine-readable, cryptographically signed Trust List, modeled directly on the EU Trusted List (EUTL) pattern that has operated in production since 2014. Any party can verify the list's contents offline against the signing key, with no central API call required. Every conformant node MUST fetch and cache the Trust List on a cadence no greater than 24 hours. A provider whose intermediary goes offline consults the signed list, finds a conformant alternative, and switches without asking anyone's permission. That is what substitutability means in practice.

§2.4Accredited intermediaries and the pluralism guarantee

Federation is only real if more than one party can occupy the middle. The Trust Framework therefore bakes plurality into the Trust List as a published status, not an advisory note:

• Green / Federation-grade: ≥3 accredited intermediaries active.
• Yellow: fewer than 3 accredited intermediaries active.
• Red: fewer than 2 active.

Three is the floor at which one intermediary's failure, acquisition, or policy change does not leave the network without a fallback. The pluralism status is the mechanism by which regulators, platforms, and downstream providers can see, at any moment, whether the market has retained meaningful substitutability or collapsed toward monoculture.

§2.5Role layers

The Trust Framework adopts the four role layers from IETF draft-knodel-age-arch-00 verbatim, to keep cross-spec referencing cost-free:

• Issuer: produces age credentials.
• Verifier: checks credentials against a defined assurance level.
• Gatekeeper: enforces platform access decisions downstream of verification.
• Infrastructure intermediary: routes signals, audit rows, and policy claims among the other three. This is the role the Trust Framework specifies in depth, and the role the pluralism guarantee governs.

§2.6Cryptographic requirements

The following are non-optional. An implementation that omits any MUST primitive is not OCSS-conformant and MUST NOT appear on the signed Trust List.

• MUST: RFC 9421 HTTP Message Signatures over Ed25519, covering a body digest, a per-request nonce, and the audience binding. Replay across intermediaries is foreclosed because the nonce is consumed on first delivery (see §2.2).
• MUST: the inner layer is JWE, sealed to the receiver's public key using ECDH-ES+A256KW key agreement with A256GCM content encryption (or an equivalent authenticated-encryption suite). Authenticated encryption is mandatory: unauthenticated CBC modes are out of conformance, removing the padding-oracle attack surface entirely.
• MUST: constant-time comparison for every HMAC and signature-verification path, and for nonce-equality checks. A verifier MUST NOT short-circuit on the first differing byte; timing must not leak a function of the secret or the signature, closing the timing side channel against key and tag recovery.
• MUST: RFC 8707 resource indicators for OAuth 2.0. A token issued for intermediary X MUST NOT be accepted by intermediary Y; every hop carries a distinct, audience-bound token.
• MUST: an eIDAS-style signed Trust List, fetched and cached ≤24h.
• MUST: per-party JWKS endpoints publishing current and rolling Ed25519 (OKP) keys, with key rotation on a published cadence ≤180 days. Rotation overlaps the old and new key so in-flight signatures verify across the cutover.
• MUST: an immutable, append-only audit trail with response signatures, enabling independent re-verification of any routing decision.
• SHOULD: the W3C Digital Credentials API with OpenID4VP / DCQL for selective-disclosure age proofs; effectively a MUST for any receiver requiring browser-native zero-knowledge age proofs.
• MAY (v1.1 roadmap): Longfellow-ZK proofs over existing credentials, TEE attestation (a future "Tier 4" intermediary status), and W3C Verifiable Credentials for long-lived parental-consent certificates. These are explicitly outside the v1.0 conformance boundary.

The credential proof in v1.0, and where SHOULD becomes MUST. The W3C Digital Credentials API is a network-wide SHOULD, not a MUST, because v1.0 must run on surfaces that have no browser: carrier DNS, embedded device firmware, an MDM agent. For those, the v1.0 credential proof is an Ed25519 signature over the credential, verified against a JWKS key, which is sufficient assurance for the Open and Gated bands. The point a security reviewer needs is that the SHOULD is band-scoped, and it is not band-scoped by exhortation. The conformance contract draws the line as a hard rule, not advice:

• MUST: for any receiver claiming Accredited status (the only tier permitted to handle the Restricted band), the high-assurance age-proof path is mandatory: the receiver MUST require either the W3C Digital Credentials API selective-disclosure flow (OpenID4VP / DCQL) or an equivalently-bound credential, and a bare Ed25519-over-credential signature MUST NOT satisfy a Restricted-band age proof. The conformance suite tests this as a per-tier MUST, so a receiver cannot certify Accredited while accepting low-assurance proofs for Restricted traffic.
• SHOULD → MUST by band: the network-wide statement is "SHOULD use the browser selective-disclosure path," but for the Restricted band that SHOULD is promoted to the MUST above. The browser path remains a SHOULD only on the Open and Gated bands, where the signed credential is the floor.

So the assurance ladder is testable, not aspirational: Open/Gated accept the signed credential; Restricted requires selective disclosure today, and adds Longfellow-ZK or TEE attestation as conformance options once v1.1 promotes them (§2.6, roadmap row). The reason a security reviewer can validate an Accredited claim for high-stakes age proofs is precisely that the high-assurance codepath is a MUST at the tier where it matters. The v1.0 SHOULD is explicitly not a license to ship low-assurance proofs into a regulated, Restricted-band context, because at that tier it is no longer a SHOULD.

§2.7Threat model & recovery

The Trust Framework is designed against a specific, written adversary set, not a vague promise of "security." The authoritative model lives in draft-phosra-ocstf-00 (Security Considerations); what follows is the scope a reviewer needs to read this page.

In scope. The wire is assumed hostile, so a man-in-the-middle who captures and replays an envelope gets nothing: the per-request nonce (§2.2) is consumed on first delivery and rejected on any reappearance, and the ±300s freshness window means a captured envelope is stale long before most replays are attempted. The intermediary itself is assumed curious (possibly compromised), and the design denies it the two things it would want. It never holds a decryption key, because the inner layer is JWE-sealed to the receiver, so routing metadata is all it can read; and even that metadata withholds a join key, because the per-receiver HKDF family_hash resolves the same family to uncorrelated values at different receivers, so an intermediary cannot stitch one child's activity together across receivers. A timing adversary probing the verifier fares no better: every signature, HMAC, and nonce-equality check is constant-time (§2.6), so no comparison leaks a function of the secret. And a routing party that tries to downgrade a strict Rule to a more permissive one cannot, because the inner payload is signed and sealed: swap a weaker Rule in and the signature the receiver checks before enforcing simply fails.

Nonce-store exhaustion, analyzed. The obvious follow-on attack on the replay defense is to attack the store that backs it: flood an intermediary with valid-looking nonces, or pre-populate it with far-future timestamps, until it falls over. The freshness window forecloses both. Because issued_at must land within ±300s of the verifier's clock and the envelope must carry a valid sender signature to be admitted, an attacker cannot insert a nonce by minting a future-dated envelope: it is rejected before the nonce is recorded. The store's resident set is therefore bounded by one window's worth of legitimately-signed, freshly-timestamped deliveries (a quantity tied to real traffic from listed senders, not to an attacker's send rate), and it self-prunes as entries age past the window. The store has a ceiling by construction; it is not an unbounded sink an adversary can grow at will.

Out of scope for v1.0 (stated, not hidden). A receiver whose own decryption key is exfiltrated can read its own traffic. OCSS protects signals across the network, not against a fully compromised endpoint. Volumetric denial-of-service against a single intermediary is handled by substitutability (§2.3, §2.4), not by the protocol itself: when an intermediary is down or hostile, providers fail over to another on the signed Trust List, and the bounded nonce store (above) keeps the replay defense from becoming its own DoS target.

Key compromise and revocation. Keys rotate on a published cadence of ≤180 days with old/new overlap (§2.6), but rotation is the routine case; compromise is the urgent one. A party that suspects key loss publishes the revocation in its JWKS immediately and the Trust List operator pulls the affected intermediary's row on the next signed publication, and every conformant node re-fetches the Trust List at least every 24 hours, so the revocation propagates network-wide within that window without a flag day. Receipts signed before the revocation timestamp remain verifiable against the rotated-out key (which stays published as historical, not active); Receipts that claim a time after revocation against a revoked key fail verification. The 24-hour cache ceiling is therefore also the worst-case revocation SLA: an attacker holding a stolen key has at most one Trust-List cycle, not indefinite access.

Testing the security claims. Constant-time behavior and payload blindness are not honor-system assertions. The conformance suite (Conformance) treats them as MUST-NEVER cases: a verifier whose comparison time correlates with input under a statistical timing harness fails, and an intermediary that can produce plaintext for a sealed payload fails. These are pass/fail, not graded.

§3Sample signed envelope

A realistic, non-normative illustration. The authoritative field semantics, size constraints, and error-handling rules live in draft-phosra-ocstf-00 (Appendix C). Identifiers, signatures, and ciphertext are abbreviated for readability.

§3.1Two-layer envelope

Once the receiver decrypts inner.payload, it recovers the typed OCSS Rule the envelope was carrying:

The intermediary routes on outer and never sees the Rule. The receiver verifies the sender signature against the Trust List, decrypts inner, and enforces the typed Rule. Payload blindness at the intermediary is a MUST-NEVER violation if broken (see Conformance).

§3.2Sample OCSS Receipt

Every enforcement decision is wrapped in a signed Receipt. A Receipt carries the rule, the derived age band, the jurisdiction, the capability, the decision, the statute citations, and an Ed25519 signature over typed data domain-separated by spec version. It contains no PII: age is the band 13-17, never a birthdate or identity. Because the signature is over typed fields, a regulator recomputes each signature against the signer's published JWKS to confirm a Receipt is authentic and unaltered without contacting the implementer at all, and the implementer cannot backdate, forge, or quietly edit a decision without invalidating the signature.

What a subpoena-free audit looks like operationally. A regulator pulls Receipts over a published query surface, filtering by jurisdiction, rule, and issued_at range (e.g. every nfk_hard_block in US-NY for Q2). Each Receipt verifies against the signer's published JWKS, so a request that used to mean a subpoena and weeks of waiting becomes a verification that runs locally in seconds.

The query interface is a contract, not a courtesy. A vendor cannot prototype against vibes, so v1.0 pins the audit-query surface down to the parts an integrator needs to plan around:

The exact byte-level request/response schema, error codes, and the rate ceiling are normative in draft-phosra-ocstf-00 and ship in the JSON Schema with the registry (§5); the contract above is what an integrator builds and budgets against today. One evidentiary detail bears repeating: deletion of records shows up as a gap in the append-only trail (§2.6), so an audit can prove tampering, not merely allege it.

Admissibility, plainly. A Receipt is self-authenticating digital evidence in the sense courts already understand: its integrity is established by a digital signature against a published key, not by an implementer's testimony that the log is genuine. That is the same posture as a qualified eIDAS electronic seal or a notarized timestamp. OCSS does not claim a Receipt is automatically admissible in any given forum (admissibility is the court's call), but it removes the chain-of-custody dispute that usually dominates these proceedings: whether the record was altered after the fact is answerable in seconds, by anyone, offline.

§3.3Verify-before-enforce, and the fields you build against

An implementer never enforces on an unverified Rule. The sequence a receiver runs on every inbound envelope is fixed and ordered:

• 1. Resolve the sender against the cached signed Trust List (§2.3). If the sender's key is not on the list, stop; an unlisted sender is not trusted, full stop.
• 2. Verify the outer signature (RFC 9421 over Ed25519), then check the nonce against the consumed-nonce store. A failed signature or a replayed nonce is dropped before decryption is ever attempted.
• 3. Decrypt the inner layer (JWE to the receiver's key) and verify the sealed payload's signature. Only now does the typed Rule exist in cleartext.
• 4. Enforce the typed Rule and emit a signed Receipt (§3.2). Enforce is the last step, never the first; verify-before-enforce is the invariant the conformance suite tests against.

The fields are enumerated, not free-form. Authoritative semantics, byte-size limits, and error codes are normative in draft-phosra-ocstf-00 (Appendix C) and the published JSON Schema ships with the registry (§5), but the vocabulary an engineer builds against is fixed:

How a layer is certified. Each of the eight runtime capabilities is its own conformance claim with its own test set, and the threshold is all-must-pass: there is no partial credit within a claimed layer, and the security MUST-NEVER cases (payload blindness, constant-time comparison; §2.6, §2.7) are pass/fail across every layer. An implementer requests the certification mark by passing the suite for the specific layers it claims; the mark then names those layers and nothing more.

The acceptance criteria are knowable before the suite ships. "In active drafting" is not a reason a reviewer should have to wait, so the suite's structure is fixed even while the individual cases are being written. Acceptance for any claimed layer is the conjunction of three test classes, and an implementer can build against them today: (a) per-Rule decision vectors, a frozen set of input envelopes per Rule with the single correct decision for each, so a layer passes only if it reproduces the canonical Allow/Warn/Block/Pending-Parent for every Rule in the layer; (b) the protocol invariants, the verify-before-enforce order (§3.3), Trust-List resolution, and signed-Receipt emission, exercised against malformed, replayed, and out-of-window envelopes that MUST be rejected; and (c) the MUST-NEVER security cases, a statistical timing harness against every comparison path and a sealed-payload challenge against every intermediary, both pass/fail (§2.7). What is not yet published is the count of cases in each class, because the per-Rule vector set is still being frozen, and OCSS will not quote a number it has to revise. An early implementer wires against these three classes now and gets an interim review against the draft vectors; the Q3 2026 milestone is when the vector set freezes and the counts publish with the suite, not when the acceptance model first becomes legible. The roadmap and interim-review pathway live on Conformance.

The enforcement surface is the implementer's choice. The same typed Rule is enforced identically whether the surface is recursive DNS, an MDM profile, a household router, an operating-system age API, or an app-store install gate. OCSS specifies the decision, not the mechanism, so a DNS provider and an OS vendor implementing the same Rule reach the same Allow/Warn/Block, and a buyer comparing two products is comparing the same contract.

§3.4The conformance contract, on one screen

The MUST and MUST-NEVER obligations are stated in their home sections (crypto in §2.6, verify-before-enforce in §3.3, the threat-model pass/fail cases in §2.7). A platform engineer building a conformant router, MDM, DNS service, or OS integration should not have to reassemble them from prose, so here is the single testable list, where every row is something the conformance suite checks:

The MUST-NEVER rows are pass/fail across every claimed layer; the numbered MUST rows are tested per the capabilities an implementer claims. This is the contract an integrator certifies against. The full normative wording lives in draft-phosra-ocstf-00, and the per-layer test mapping is on Conformance.

§3.5The accreditation ladder

Two ladders run in parallel, and they are not the same axis. One grades how an adopter's claim is verified; the other grades what bands a routing intermediary is trusted to carry. A buyer or regulator reading a mark needs to know which is which.

The pricing for each tier and the full assessor process live on Conformance rather than here, because they move on a different clock than the spec; what this page fixes is the shape of the ladder, so an engineer reading the spec knows which rung a given claim sits on. A Tier 4 intermediary status backed by TEE attestation is on the v1.1 roadmap (§2.6) and is deliberately outside the v1.0 boundary.

§4Versions & status

Both layers carry independent SemVer. A minor bump only adds (new Rules, tighter wording, additional statute citations) and never changes what an existing Rule decides, so an implementer can adopt it without re-certifying. A major bump can break behavior, and the bar for one is deliberately high: a public review window of 90 days, an RFC on file at least 30 days before the Trust Committee votes, and an 18-month deprecation window during which the old major keeps verifying. Nothing in this document is ratified; the statuses below are honest, not aspirational.

The real Trust List entry count and accredited-intermediary count today is 0: the coalition is forming. OCSS does not publish placeholder counters.

§4.1For regulators: authority, enforcement, and the root of trust

Who accredits, and where the root of trust lives. At ratification, authority over the standard transfers from Phosra (steward of v1.0 only) 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. The Committee holds the Linux Foundation AAIF root key, ratifies every major version, and approves the conformance suite and the roster of approved assessors. Assessors audit implementers; the Committee audits the assessors and signs the Trust List. So the chain a regulator can anchor to is concrete: a legal requirement points at "OCSS-conformant," conformance is verified by a Committee-approved assessor, and the assessor's authority traces to a Committee whose composition is fixed in the Charter (see governance).

Where the AAIF root key sits today, stated plainly. A regulator deciding whether to anchor statute language to OCSS needs to know who controls the root of trust now, not just after ratification. Today, as steward of v1.0, Phosra holds the AAIF root key. That is the honest status, and it is exactly why ratification matters: the handoff to the Trust Committee is the moment the key leaves a single vendor's hands for a multi-stakeholder body. The handoff is a published, pending milestone (§4, "governance handoff · pending ratification"), not a verbal promise, with the Committee's composition fixed in the Charter before the key moves. A regulator that is not willing to anchor to a single-steward root today can condition its reliance on the post-ratification Committee root; OCSS does not pretend the key is already in neutral escrow, and it does not ask a regulator to trust that it is.

The Regulator Observer seat, and what actually protects an enforcement-critical rule. One of the nine Trust Committee seats is reserved for a regulator observer. The seat carries full voice: it participates in working-group review and conformance-suite approval, and its presence is the mechanism by which enforcement agencies see rule changes before they ship rather than after. It is an observer seat by design: it does not carry a binding vote on ratification, because a standards body that a single regulator could veto would not be credibly multi-stakeholder or cross-jurisdictional. The honest reading is that the seat is influence, not a legal guarantee, and a regulator should not have to rely on a seat for the certainty it actually needs. That certainty comes from three structural facts that hold regardless of the seat. First, a Rule's meaning cannot be changed silently: a change to what a Rule decides is a breaking change (§1.1), and a breaking change requires a major version, which carries a 90-day public review window, an RFC on file ≥30 days before the Trust Committee votes, and an 18-month deprecation window during which the old major keeps verifying (§4). A rule a jurisdiction relied on cannot be "changed by RFC" out from under it: the old behavior keeps verifying for 18 months, and the change was on the public record for at least 120 days before it took effect. Second, what a regulator anchors statute to is a versioned Rule: a citation to OCSS-v1.0 is pinned, and every signature is domain-separated by spec version (§3.3), so a later major cannot retroactively alter the contract a law referenced. Third, the regulator's real power is its own statute, exercised in its own jurisdiction; the seat is how that regulator shapes the spec without capturing it, but the version-pinning is what makes its reliance durable. Bulk Receipt query (§3.2) is available to any regulator with jurisdiction over the implementer, seat or no seat; auditability is not gated on Trust Committee membership.

Adding a new statute to the registry: the pathway, not a black box. A standard built on the law has to answer how the law gets in. When a new jurisdiction enacts a child-safety statute, getting it into OCSS is an RFC against the Rule registry, and the path depends on whether an existing Rule already covers it. Most new laws map onto Rules that already exist: a new state consent statute is one more cite[] entry on parental_consent_gate, which is an additive minor change (the Rule's decision does not move, only its statute mapping grows) and ships without any implementer re-certifying. A statute that creates a genuinely new obligation no Rule covers is a new Rule, proposed by RFC to the relevant working group (AI Safety · Privacy · Algorithmic Transparency · Hard Blocks), reviewed in public, and added in a minor version, still additive, since a new Rule does not change an existing one. Only a statute that conflicts with an existing Rule's decision forces a major version and the full review-and-deprecation clock above. A regulator or its delegate can file the RFC directly; the submission template and the change-control process are written up under governance & process. The point a regulator should take away: adding your jurisdiction's law is a defined, public procedure, not a favor you have to negotiate with a vendor.

What happens when a Tier 1 claim fails an audit. Conformance is binary and testable, so a false claim is detectable. If an implementer asserts Certified and a re-audit or a complaint shows it does not pass the claimed layers, the mark is suspended and the implementer is moved to or removed from the public registry. The registry is the enforcement surface, and a suspended mark is visible to every buyer and regulator reading it. The implementer may dispute through the Trust Committee's appeal process: a re-test by a second approved assessor, with the finding published either way. The Trust Committee governs the mark and the registry; it does not and cannot adjudicate the underlying statutory violation. That remains the regulator's enforcement action, for which the suspended mark and the implementer's own Receipts are evidence. OCSS makes the false claim cheap to catch and expensive to keep; it leaves the legal penalty to the law.

§5Get the Spec

The authoritative text exists today. Field-by-field semantics, size constraints, error codes, and the conformance contract are normative in the filed Internet-Draft, draft-phosra-ocstf-00. Read it there now for anything a reviewer must cross-reference to validate an implementation. This page is the orientation; the draft is the contract. The packaged artifacts below (a frozen registry snapshot, the JSON Schema, a print-ready PDF) land with v1.0 ratification and are marked coming until then; OCSS does not ship a download that misrepresents draft status.

The RFC process. OCSS changes are made by RFC, in public, never by fiat. Anyone may propose a clarification, a new Rule, or a deprecation; every change is filed as an RFC at least 30 days before adoption and reviewed by the relevant working group (AI Safety · Privacy · Algorithmic Transparency · Hard Blocks). The full change-control process (review windows, working-group sponsorship, and the major-version deprecation clock) is written up under governance & process; the public RFC repository and submission template open with the v1.0 review period.