The OCSS specification, the OCSS Trust Framework, and the implementer material that supports them are published here as the vendor-neutral coalition drafts them. OCSS is currently Draft for Review. v1.0 is targeted for ratification in Q3 2026, when editorial authority transfers from the founding steward to the Trust Committee. Some documents are published in their current draft; others are in active drafting and dated to their expected release. Status is stated honestly on every entry. Nothing here is presented as final unless it is. Everything is openly licensed and free to read, implement, and redistribute. There is no paywall on the standard.
License: open / royalty-freeSpec status: v1.0 · Draft for ReviewRatification target: Q3 2026Coalition contact:[email protected]A vendor-neutral coalition · Phosra is one participant of many
§ 1
The library
Grouped by type. Each entry lists its current status (published, draft, or a target quarter), so implementers can tell what they can build against today versus what to expect next.
Filter
Specification & whitepapers
3 documents
Specificationpublished
OCSS Trust Framework: architecture whitepaper
The reference description of the routing and trust layer: the two-layer signed envelope (outer routing metadata with an Ed25519 sender signature, inner JWE-sealed to the receiver's key), the eIDAS-style signed Trust List of accredited intermediaries, the accreditation tiers, and the MUST / MUST-NEVER conformance contract. Explains why a single vendor hub is not federation, and why the Trust List degrades to Yellow below three intermediaries and Red below two.
Defines what a child-safety signal means: the ~100 typed rule categories grouped under the eight runtime capabilities (Age, Tier, Consent, Block, Alert, Privacy, Audit, Receipt). Each category names a single obligation as a machine-readable type, so platforms enforce against the spec rather than re-reading each statute.
The full crypto document lands Q3 2026, but the boundary it formalizes is fixed now, so researchers can audit today rather than wait on prose. The primitives are not negotiable: Ed25519 over RFC 9421 on the outer layer, JWE on the inner, an eIDAS-style signed Trust List verified before any action.
Five named defenses: replay, cross-intermediary correlation, hash-strip, key compromise, stricter-rule downgrade
Stated non-goals, including why proof-of-possession is deferred to v1.1
A citable threat-model.json artifact: file a finding against a named boundary
The full crypto document is in drafting for Q3 2026, but the boundary it formalizes is fixed now. The primitives are not negotiable: the outer layer is signed with Ed25519 over RFC 9421 HTTP Message Signatures; the inner payload is JWE-sealed to the receiver's published key; the Trust List is an eIDAS-style signed JSON registry a receiver verifies before it acts.
Four defenses worth naming. Replay: the signed envelope binds a one-time message id and issued-at; a receiver MUST reject a duplicate id or a stale timestamp rather than re-enforce. Cross-intermediary correlation:family_hash is domain-separated per receiver. The construction is HKDF(family_id, receiver_did), so the same household resolves to a different hash at each intermediary and cannot be joined across them. The receiver salt is covered by the outer Ed25519 signature, so an intermediary cannot strip it down to a bare global hash without breaking verification; dropping the domain separator is itself a signature failure, not a silent downgrade. Key compromise: Accredited intermediaries MUST rotate signing keys on a ≤180-day cycle, and a rotation is itself a signed, timestamped event. The new kid appears on the next signed Trust List with its own valid-from, so rotation is provable from the list rather than asserted out of band. Stricter-rule downgrade: a receiver MUST-NEVER apply a rule weaker than the one the envelope carries. The protocol fails closed toward the stricter obligation.
What it does not defend, stated plainly
A compromised receiver endpoint or a leaked receiver private key breaks inner-payload confidentiality. The payload is only as private as that key. The published JWKS proves the key is advertised, not currently held; there is no proof-of-possession in v1.0, and a holder-of-key challenge against the JWKS is on the v1.1 roadmap, not a present guarantee.
PoP is deferred on a stated argument, not omitted: the residual risk a PoP challenge would close is an attacker who publishes a key in a JWKS it does not control, and that attacker still has to appear on a signed Trust List to be trusted. A key advertised but absent from the list is rejected regardless. With the list bounding admission, the marginal risk PoP removes is one cache cycle of a key the steward can cut sooner. The two bounds that do the work: ≤180-day mandatory rotation caps how long any single key is live, and the ≤24h cache TTL caps how long a withdrawn key is still honored. A key under active abuse is cut faster through the out-of-band signed revocation bulletin, which a verifier checks before accepting an envelope, so "no live revocation feed" is the steady-state path, not the only one. The independent security audit is scheduled to complete before ratification, so the boundary is reviewed external to the steward before v1.0 is frozen. On publication, both the document and the threat-model.json artifact ship alongside the spec source (linked from §2.6 of the spec as a downloadable file), so a researcher can cite a boundary by id and file a finding against a named assumption.
// threat-model.json · excerpt — each boundary is citable by id { "defends_against": [ { "id": "T-REPLAY", "control": "one-time msg id + issued_at, reject duplicates" }, { "id": "T-CORRELATE", "control": "family_hash = HKDF(family_id, receiver_did)" }, { "id": "T-HASH-STRIP", "control": "receiver salt is under the outer sig; stripping it fails verify" }, { "id": "T-DOWNGRADE", "control": "receiver MUST-NEVER apply a weaker rule; fail closed" }, { "id": "T-KEY-COMPROMISE", "control": "signed+timestamped rotation ≤180d; bulletin revokes in minutes" } ], "out_of_scope": [ { "id": "T-RECV-KEY", "note": "leaked receiver key voids inner confidentiality" }, { "id": "T-POP", "note": "JWKS proves advertised, not held; deferred — Trust List bounds admission; PoP is v1.1" } ] }
IETF / standards-track
1 document
IETFfiled
draft-phosra-ocstf-00: Internet-Draft
The OCSS Trust Framework filed as an IETF Internet-Draft. Builds on the role layering in draft-knodel-age-arch-00 (Issuer, Verifier, Gatekeeper) and adds the fourth role, the Infrastructure intermediary. References RFC 9421 (HTTP Message Signatures, Ed25519) and RFC 8707 (resource indicators) as normative. The ocstf slug is retained verbatim per the filed draft name.
The full guide lands Q3 2026, but the order of operations is normative now: fetch and cache the signed Trust List, verify the outer Ed25519 signature against it, decrypt the inner JWE to your own key, then read one typed rule and enforce. A receiver MUST verify before it touches the payload, MUST-NEVER enforce on an unverified envelope, and MUST fail closed when it cannot verify against a fresh-enough list.
// 1 — cache key is global per Trust List version; ≤24h TTL tl = getTrustList() // signed JSON, one shared copy // 2 — verify outer sig against an accredited signer in tl if (!verifyEd25519(env.outer, tl)) reject() // 3 — open the inner layer to your own JWKS key rule = decryptJWE(env.inner, myKey) // 4 — the typed rule you act on { "rule": "ai_chatbot_tier_gate", "capability": "Tier", "age_band": "13-17", "decision": "Warn" }
A deeper guide to envelope construction and verification: signing the outer layer (RFC 9421, Ed25519), sealing the inner layer (JWE), key publication via per-party JWKS, and verifying against the Trust List before reading any rule payload. The interface commits to off-the-shelf primitives, so you can stand up verify-before-enforce against a hand-built fixture envelope today.
Why the JWKS is the soft spot, and how Trust-List vouching, not endpoint resolution, gates a key
Key compromise by rotation, not detection: ≤180-day cycle, ≤24h cache bound, out-of-band revocation bulletin
Build-now primitives vs. ratification deliverables (JSON Schema, test vectors, reference impl)
How to run the conformance suite against the capabilities you implement, interpret MUST / MUST-NEVER results, and request listing, either via the free self-attested Implementer path or the audited Certified mark. The full corpus lands with ratification in Q3 2026; the test surface is stable now and the test set stabilizes then, so you can start your harness against a fixed interface today.
Phase 1 floor: ~18 MUST / MUST-NEVER checks for a Trust Framework intermediary
Capability suites layer on: you are tested only against what you claim, not all eight
Easiest first for parental-control: Tier and Block; stage Privacy and Audit later
// conformance case · TF-MUSTNEVER-03 · reject tampered signature { "given": "envelope with valid body, outer sig flipped one byte", "expect": "receiver rejects, enforces nothing, emits no audit row", "pass_if": "verify() === false AND enforce() not called" }
The registry of accredited intermediaries, served as cryptographically signed JSON with per-entity tier, status, and valid-through dates. The design borrows from the EU Trusted List (a signed, machine-readable list relying parties verify offline), so a receiver checks a signer without phoning home on every envelope.
What you find today: an empty, signed registry. Schema and endpoint are verifiable now, 0 intermediaries (forming), so it reports Red honestly
The three-state ladder: Provisional → Verified → Accredited, the last gated on the conformance suite plus a SOC 2 Type II audit
Accreditation and review windows open Q3 2026. DNS, MDM, OS/router, and carriers can register interest now
The ROI is integration math. A parental-control vendor wiring up to platforms, device makers, and carriers one at a time faces N×M bilateral integrations. OCSS collapses that: you read one signed signal, and any sender that conforms reaches you without a per-partner build — N+M integrations, not N×M. Worked through: a vendor with two surfaces (a DNS resolver, an MDM profile) honoring eight upstream sources is 16 bilateral integrations; under OCSS it is 2 receiver builds, and the ninth source reaches both for free. You build to the spec once and inherit everyone who already did.
You implement the receiver side only (for the capabilities you offer) and earn the Implementer or audited Certified mark a buyer or regulator can check
Claiming a capability means passing its conformance suite against your own enforcement path, not a paper attestation
The capability-to-surface map below shows which rules a product would carry before committing to a build
Ban commercial sale of minor data (commercial_data_ban)
Alert
App / home router
Screen-time report to a parent (screen_time_report)
In plain terms: the safety settings a parent already sets on a phone, computer, app, or home router are what actually enforce OCSS. No technical background is needed to follow the first chapter.
The machine-readable mapping that traces each OCSS rule to the legislation that motivates it, across the ~91 laws in the registry and 30+ jurisdictions. Drives the per-rule jurisdiction view. The panel below shows six representative statutes; the full mapping of all ~91 laws, filterable by jurisdiction and by status (enacted vs. proposed/pending), is published and maintained as law moves. How a rule maps to statute is specified in §1.4 of the spec.
The child-safety bills the coalition is watching as they move through legislatures, and the rules each would touch when enacted. Distinguishes enacted law from proposed, pending, and enjoined, and spells out what each distinction means in practice: enacted binds now; passed is signed but phasing in toward an effective date; pending is live in a chamber with no date yet; enjoined is blocked by a court and not enforceable until the injunction lifts.
So a regulator can judge whether this traces policy the way they need, the per-row shape is fixed already:
// tracker row · same status vocabulary as the per-rule view { "statute": "CA AB 1043", "jurisdiction": "US-CA", "status": "passed", "effective": "2027-01-01", "rules": ["os_age_signal_ingest"], "last_moved": "2026-Q2" }
OCSS is built on the law, not instead of it. Every rule in the taxonomy is traced to the statute that motivates it, so the standard moves as legislation moves. OCSS implements; it does not endorse. A mapping records that a rule corresponds to a legal obligation, not that any body has approved OCSS.
Most of this is already law. Of the ~91 statutes mapped, 54 are enacted (a clear majority, roughly three in five), so an implementer building to OCSS is mostly building to obligations that already bind, not betting on bills that might pass. The mapping spans 30+ jurisdictions and 25+ countries, grouped as US-State (50), US-Federal (9), EU (9), APAC (11), Americas (5), MEA (5), and UK (2). The 37 that are not yet enforced are a mix: most are proposed or pending, a handful sit under injunction, and a few passed recently and are still phasing in. Every citation carries its own status, so a rule mapped to a pending bill is never dressed up as enforced law.
91
Laws mapped
54
Enacted
30+
Jurisdictions
25+
Countries
~100
Rules traced
Status
A regulator's first question is usually "is this already law in my jurisdiction, or am I reading ahead of it?" So every citation carries a status. The six rows below are a representative slice; the same enacted/proposed split runs through the full ~91-law registry behind the per-rule view.
Law
Jurisdiction
What an OCSS rule implements
Status framing
KOSAKids Online Safety Act
US-Federal
Duty-of-care and design obligations expressed as Tier and Audit rules
implements · awaiting House passage
COPPA 2.0
US-Federal
Verifiable parental consent and data-minimization rules (Consent, Privacy)
implements · in committee
EU AADCAge-Appropriate Design Code
EU
Default high-privacy and age-assurance rules (Age, Privacy)
implements · in force
UK OSAOnline Safety Act
UK
Hard-block and reporting obligations (Block, Receipt)
Prohibition on AI simulated companionship for minors (ai_no_simulated_companionship, Block)
implements · pending in Albany
Note on status: KOSA, COPPA 2.0, CA AB 1043, and NY S9051 are pending or not-yet-enforced as of this writing. A rule mapped to one of them implements the obligation the bill describes; it does not assert compliance with an enforced law. The mapping marks each statute's status, and the per-rule view shows whether a citation is enacted, proposed, pending, enjoined, or passed.
When does a pending bill become a conformance deadline? A regulator's framing question. Each pending citation carries its own effective date when the statute names one, separate from its legislative status. CA AB 1043 is already signed with an effective date of 2027-01-01, so a product is building toward a known clock even though enforcement has not started. KOSA and COPPA 2.0 name no effective date until they pass; the mapping holds them as pending with a null effective field and stamps the date the moment a version is signed, so the conformance horizon for an implementer moves the day the law does. The rule of thumb the mapping encodes: if a bill passes carrying an enforcement date, the OCSS rule that implements it is the thing a product flips on by that date — the standard does not invent its own deadline, it inherits the statute's.
How a regulator queries this, and disputes it. The per-rule view is the audit surface: a regulator opens a rule (say os_age_signal_ingest), reads the statutes mapped to it with each citation's jurisdiction and status, and follows the citation to the section it implements. That is the same trace a conformance Receipt carries in its cite[] field, so a signed enforcement event and the public mapping point at the same statute id. A disputed citation (a regulator who reads a mapping as wrong for their jurisdiction, or a statute mapped to the wrong rule) is filed against the named citation and escalates through governance, not through a vendor: today to the editorial steward against the published criteria, and at ratification to the Trust Committee, where the reserved civil-society seats and the 72-hour public notice-and-comment window exist for exactly this. The dispute, its basis, and the resolution are recorded in the same signed format the rest of the audit trail uses, so the correction is itself traceable.
Who decides what the law gets mapped to. A regulator's fair next question is governance, not just citations. Today Phosra holds editorial stewardship of v1.0 only, through ratification, as one participant of many, not the owner. At ratification (target Q3 2026) that authority 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. The full seat structure and bylaws are at Mission & governance → the Trust Committee; the coalition takes input at [email protected].
Whitepapers, guides, and Trust List changes are published when they are ready, not on a fixed schedule.
Build against the spec today.
The OCSS Rules taxonomy and Trust Framework whitepaper are published and free to implement. Subscribe to hear when a new resource or normative draft lands. Notices go out on publication, not on a schedule.