Why a standard, and why open
One signal, every surface, written like an engineering specification, not a product brochure. Built by the platforms, vendors, regulators, and researchers who have to live with it.
One signal, every surface
A single typed vocabulary travels intact from statute to enforcement point: no per-vendor re-implementation, no lossy translation between DNS, MDM, routers and operating systems.
- One vocabulary across DNS, MDM, routers, OS
- No per-vendor re-implementation
- Typed, machine-readable payloads
Built on the law
Every rule traces to a statute, and the counts move with the legislation, not the marketing.
Shape the standard
- Open working groups own each rule area
- Public redline + comment against section numbers
- RFC-style, one-org-one-vote consensus
Trusted & accredited
An eIDAS-style signed Trust List, four accreditation tiers, and a binary MUST / MUST-NEVER conformance contract decide who is trusted.
For parents & advocates: a child-safety rule you set once should follow your child everywhere, not need re-configuring on each device. With OCSS, one signal carries the same meaning to your phone, the home router, and any app. If an app is age-gated at 13 under OCSS, that same signal stops it at your home router. You don't re-enter the rule per vendor, and a parental-controls product never has to guess what "age 13" meant on someone else's system.
For parental-controls & platform teams: today every vendor pair needs its own bilateral integration: N platforms × M control products. OCSS replaces that with one verified signal each side reads, so the integration count drops from N×M to N+M. You implement the rule categories for the capabilities you claim (Age, Tier, Block, Consent…), then self-attest as a free Implementer against Draft 4. The audited Certified mark is earned, not issued — and not yet claimable: the conformance suite and a second independent runner are still in drafting. Implementing is always free; membership is never a precondition to implement. The conformance path and what's not yet shippable.
Two layers, one specification
OCSS is the umbrella standard. OCSS Rules define what a signal means. The OCSS Trust Framework defines how it moves and who is trusted, like WebAuthn + CTAP sitting under FIDO2.
A taxonomy of 110 rule categories — 67 anchored, 43 provisional — spread across eight runtime capabilities (Age, Tier, Consent, Block, Alert, Privacy, Audit, Receipt) plus the Charter. Each rule is a typed, machine-readable assertion an enforcement point acts on, tied to the statute that motivates it, so you build to the spec, not to 91 separate laws. Counts are bound to registry/ocss-rules.json, not propagated prose.
{
"category": "ai_chatbot_tier_gate",
"capability": "tier",
"severity": "MUST",
"age_band": "13-17",
"decision": "warn",
"jurisdiction": "US-CA",
"cite": ["NY-S9051", "CA-SB243"],
"spec": "OCSS-draft-4"
}
The full category list and per-field schema live in §1 of the spec. The machine-readable validation schema ships with the conformance suite (draft, Q3 2026).
Starting implementation today. The normative envelope and Rule schema are written in plain IETF prose. The Trust Framework is filed as draft-phosra-ocstf-00 and the Rules layer is in §1, both buildable now against named RFCs, not a private blob format. What is still in drafting is the test harness: the JSON Schema for Rule payloads, the signed conformance test vectors (valid/invalid signatures, expired created stamps, stricter-rule-downgrade cases the verifier must reject), and a reference verifier are bundled into the suite, marked draft for Q3 2026. You can implement and self-attest against Draft 4 before then. The schema versions with the spec, so a build done in June validates against the September suite. Engineers who want the exact verify-before-enforce ordering can walk the sequence.
The routing and trust layer: a two-layer signed envelope, an eIDAS-style Trust List, accreditation tiers, and a normative conformance contract. It carries OCSS Rules as typed payloads.
Filed as IETF draft-phosra-ocstf-00. Built on named primitives, not invented ones. MUST: RFC 9421 HTTP Message Signatures over RFC 8032 Ed25519 for the outer layer; the inner payload sealed as a JWE using ECDH-ES+A256KW key wrap and A256GCM content encryption to the receiver's published JWKS; RFC 8707 resource indicators. SHOULD: the W3C Digital Credentials API with OpenID4VP. The conformance suite and its machine-readable schema are in active drafting, marked draft for Q3 2026.
Threat model, stated plainly
Layer 2 · threat modelA routing intermediary can route but never read: the inner JWE is sealed to the receiver's key, so a compromised hub leaks routing metadata, not rule contents. Cross-intermediary correlation is blocked by deriving the family_hash domain-separated per receiver, so the same household resolves to different opaque tokens at two intermediaries. Replay is bound out by the RFC 9421 signature covering a nonce and created timestamp. Key compromise is contained by mandatory rotation at ≤180 days and revocation through the Trust List, which is itself fetched and cached at ≤24h so a pulled key goes stale fast. A receiver MUST honor the strictest applicable rule and MUST-NEVER downgrade it, which closes the stricter-rule-downgrade attack.
Who signs the Trust List, and the cold start. The list is an eIDAS-style signed registry modeled on the EU Trusted List (operating since 2014): a root key signs the list itself, each intermediary entry carries its own accreditation signature, and verifiers pin the root key out of band so the first fetch has a root to check against. Today that root is in single-firm custody (Phosra). The destination is a threshold root held under the Linux Foundation AAIF — the T0 multi-holder ceremony is scheduled for 2026-09-30; that transfer is proposed, not executed. Trust is never meant to rest on a single hub: federation requires plurality, so the list flags Yellow below three accredited intermediaries and Red below two. With 0 accredited intermediaries today, a Phosra-only world rates Red — by design (the rule is shipped code; verify it), because "N+M with one hub is just N×M renamed."
The signing root is itself a threat surface. A compromise of the root key would forge the whole list, so Draft 4 treats it as supply-chain-critical: the scheduled AAIF root is a threshold key (no single holder can sign), each published list is monotonically versioned and the version MUST-NEVER roll back, and succession (adding or retiring a root holder) happens only through a counter-signed transition that the prior root attests to. A verifier that fetches a list older than the version it already trusts rejects it. If the Trust List fetch fails or the cache is stale past ≤24h, an enforcement point does not fail open: it falls back to the last validly signed list it holds and, if it holds none, refuses to honor signatures rather than trusting blind. RFC 9421 signatures carry a created timestamp verified within a ±300s clock-skew window. Outside it the envelope is rejected as replay-suspect, matching the OAuth/JWT norm so existing infrastructure clocks suffice. Formal verification of these primitives and an independent third-party audit are scheduled, not yet complete. The artifact today is a stated, reviewable threat model, not a verified implementation (see §3 and the conformance contract).
Accreditation & the conformance contract
Conformance is binary and testable. The certification mark may only be displayed by entities that pass the conformance suite and hold a valid Trust List entry.
A conformance claim under this specification attests that an implementation satisfies its declared OCSS rule lists; it is not a compliance determination under any statute or regulatory scheme, and it MUST NOT be represented as one.
OCSS is not a COPPA safe harbor. It is not a §102 KOSA discharge, not an Ofcom "highly effective age assurance" finding, not a 16 CFR §312.11 status, and not a showing of "reasonable steps." Conformance is evidence a regulator can weigh, never regulatory approval. A green checkmark is not "approved." And under §5.4, whoever grades the test cannot sell the tutoring: Phosra earns nothing on the standard, the mark, or governance.
Certification mark
Earned, not issued. Granted on passing the OCSS conformance suite — never self-issued by any implementer.
not yet claimable · suite in draftingThe MUST / MUST-NEVER contract
Four accreditation tiers
Observer → Tier 1 → Tier 2 → Steward, gated by assessor eligibility, not a flat price. Higher tiers carry more weight on the Trust List.
0 accredited todayEvery decision emits a signed OCSS Receipt (Ed25519, RFC 8032). A regulator recomputes the signature against the signer's published JWKS, with Trust List authenticity checked against the pinned root key, so a six-week subpoena becomes a ~30-second query. No PII: age is a derived band. The Receipt rail is implemented and golden-vector-tested; the public query endpoint ships in a later phase (see Status).
The signer is the Trust-Listed intermediary, found by its key in the public registry. Each party MUST emit one immutable audit row per envelope and keep Receipts queryable for ≥24 months.
Downgrade a stricter rule or trust an unsigned envelope and the assessor opens a finding. An unremedied MUST violation means de-listing: verifiers stop honoring the mark on the next ≤24h refresh.
OCSS is Draft 4, pre-release: formal verification and a third-party audit are scheduled, not yet complete. Build and self-attest now. The zeros we publish →
Implementer (Tier 0) is self-attested, free, and public-registry listed. Certified (Tier 1) is approved-assessor checked and verified-registry listed.
You're tested against the rule list of each capability you claim, and the mark shows only while you hold a valid Trust List entry.
Everywhere, across DNS, MDM, router, OS, app: verify the outer signature → decrypt the inner JWE → honor the strictest rule → emit a Receipt. Walk it · the contract.
Every rule traces to a law
OCSS maps 91 statutes across 30+ jurisdictions onto its 110 typed rule categories, so an implementer builds to the spec, not to the statute. A sample below. The searchable registry by jurisdiction lives on Resources, and the full crosswalk on Coalition. Pending laws are framed as implements, not "compliant with enforced law." Regulators: cite the open OCSS vocabulary by immutable edition — conformance is evidence you can weigh, never a compliance determination (§5.1).
| Statute | Jurisdiction | Status | Rule category |
|---|---|---|---|
| KOSA §4(b)(2) | US-Federal | proposed, implements | algorithmic_audit |
| CA AADC §22675 | US-CA | enacted (under injunction) | algorithmic_audit |
| COPPA 2.0 / FTC COPPA | US-Federal | proposed / enacted | parental_consent_gate |
| CA AB 1043 | US-CA | signed, phasing in, implements | os_age_signal_ingest |
| NY S9051 | US-NY | proposed, implements | ai_chatbot_tier_gate |
| UK Online Safety Act | UK | enacted | nfk_hard_block |
| EU DSA / EU AADC (GDPR Art. 8) | EU | enacted | commercial_data_ban |
| 18 U.S.C. §2258A | US-Federal | enacted | csam_reporting |
The coalition is forming
OCSS is vendor-neutral: no member owns the standard. The founding charter cohort is open, with seats reserved across platforms, device/OS makers, infrastructure providers, regulators, civil-society bodies, and researchers. Today: 0 accredited intermediaries. Trust Committee forming. Every seat below is open. Phosra is the steward of record as of 2026-06 — a dated fact under §1.5, not ownership — and transfer to an independent foundation is proposed, not executed.
Phosra, Inc. holds the steward-of-record role and operates one accredited router — the reference implementer, like Yubico for FIDO2. It does not own the standard. The signed succession record records transfer_status=held; the interim-steward designation is vacant, due 2026-07-09. See the verifiable exit.
Implementers & operators · all open
Infrastructure · all open
Independent oversight · reserved, designations pending
// real status shown · 0 of 11 seats filled · no organization has signed an instrument · charter cohort closing Q3 2026
Working groups
Technical work happens in four open working groups, each owning one rule area with public quarterly reviews. Meetings and drafts are public. Editorial authority transfers from Phosra to the Trust Committee on the path to ratification. Parental-controls vendors: the Consent and Block groups are where you shape what your product has to read and emit.
AI Safety
Owns the AI-risk tier scale and companion-AI rules: chatbot tier gates, simulated-companionship prohibitions, age-appropriate model behavior, and product classification. The Tier capability vendors gate AI products against.
Privacy & Consent
Owns verifiable parental consent, data minimization, retention and deletion rights, and the commercial-data ban for minors — the Consent layer vendors implement against.
Algorithmic Transparency
Owns audit, recommendation transparency, and dark-pattern intervention rules: what an algorithm shows a child, why it was shown, and to whom it is reported.
Hard Blocks
Owns mandatory blocks: CSAM, gambling, age-prohibited content and apps, and the "Not For Kids" hard-block signal every conformant provider must honor.
Latest from the coalition
Drafts, guidance, and announcements. Browse all news →
OCSS Draft 4 open for public review
The pre-release umbrella spec (Rules + Trust Framework), filed as individual IETF Internet-Draft draft-phosra-ocstf-00 (not WG-adopted), is open for public redline. Comment threads are tracked against section numbers, and merged resolutions become normative in the next revision.
Implementer's guide to signed envelopes
A practical walkthrough of verifying the outer signature against the Trust List before reading any rule payload.
OCSS Trust Framework filed as an IETF draft
The routing/trust layer (the two-layer signed envelope and eIDAS-style Trust List) is published as draft-phosra-ocstf-00 and open for review.
Frequently asked
Help define how the internet keeps children safe.
Read the spec, build against the conformance contract (suite in draft for Q3 2026), and join the working groups shaping the next revision.
Standards updates, no marketing
New drafts, conformance changes, and working-group calls, delivered when something normative changes.