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
- Mapped to 30+ jurisdictions
- Provisions traced to statute
- Updated as legislation moves
Shape the standard
- Open working groups
- Public redline + comment process
- RFC-style, consensus governance
Trusted & accredited
- eIDAS-style Trust List
- Four accreditation tiers
- MUST / MUST-NEVER conformance
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…), pass the conformance suite, and earn a certification mark, either Implementer (self-attested, free) or Certified (independently audited), that customers and regulators can check against a public registry. See the adopter tiers and the conformance path.
| What it costs to adopt | Price | You get |
|---|---|---|
| Implementer (self-attested) | free | Build against the v1.0 draft, self-attest, list in the public registry |
| Certified (assessor-audited) | ~$2.5–5k/yr | Independent audit, verified-registry listing, the displayable certification mark |
| Working Group seat | ~$15–25k/yr | A vote in the rule area you implement (Consent, Block…) + RFC sponsorship |
| Steering Committee | ~$75–100k/yr | Invite-only; sponsors RFCs and the v1.0 roadmap (Trust Committee seats are not tied to this tier) |
The standard itself is open and royalty-free; there is no per-seat license fee to implement. The ROI is direct: each bilateral integration you retire is engineering you stop maintaining, and the mark is a market-trust asset a buyer or regulator can verify without trusting your word. Indicative pricing for the founding cohort; final schedule lands at ratification.
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 ~100 rule categories spread across nine 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.
{
"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-v1.0"
}
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 the v1.0 draft 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): the Linux Foundation AAIF root key signs the list itself, each intermediary entry carries its own accreditation signature, and verifiers pin the AAIF root key out of band so the first fetch has a root to check against. Trust is never a single hub. Federation requires plurality, so the list flags Yellow below three accredited intermediaries and Red below two, because "N+M with one hub is just N×M renamed."
The signing root is itself a threat surface. A compromise of the AAIF root key would forge the whole list, so v1.0 treats it as supply-chain-critical: the 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 on the v1.0 ratification track and 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.
Certification mark
Earned, not claimed. Granted on passing the OCSS conformance test suite.
v1.0 conformantThe MUST / MUST-NEVER contract
Four accreditation tiers
Observer → Tier 1 → Tier 2 → Steward. Higher tiers carry more weight on the Trust List.
Tier 2 · accreditedEvery 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 AAIF root key, so a six-week subpoena becomes a ~30-second query. No PII: age is a derived band.
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.
v1.0 is Draft for Review: formal verification and a third-party audit are on the ratification track, not yet complete. Build and self-attest now. Full contract & threat model →
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 (54 enacted, 22 proposed, 7 pending) onto its ~100 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."
| 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. Phosra is the founding steward of v1.0, one participant of many.
founding steward// real status shown · the registry opens at v1.0 ratification · charter cohort closing Q3 2026
Working groups
Technical work happens in four open working groups, each owning one rule area with public quarterly reviews. Any Tier 2+ member may participate; meetings and drafts are public. At ratification, editorial authority transfers from Phosra 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. 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, and product classification.
Privacy & Consent
Owns verifiable parental consent, data minimization, retention, deletion rights, and the commercial-data ban for minors, plus how the Trust Framework keeps routing metadata uncorrelated. The home of the Consent layer parental-controls vendors implement against.
Algorithmic Transparency
Owns audit, recommendation transparency, and dark-pattern intervention rules: what an algorithm shows a child, why, and to whom.
Hard Blocks
Owns mandatory blocks: CSAM, gambling, age-prohibited content and apps, and the "Not For Kids" hard-block signal.
Latest from the coalition
Drafts, guidance, and announcements. Browse all news →
OCSS v1.0 published as Draft for Review
The first complete draft of the umbrella spec (Rules + Trust Framework) is open for public redline. Comment threads are tracked against section numbers; merged resolutions become normative in the next revision. Ratification is targeted for Q3 2026.
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.