What the coalition is
The multi-stakeholder group that implements, governs, and earns trust under the Open Child Safety Specification. A standard for child-safety interoperability is only worth as much as the breadth of who implements it.
Cross-industry by design
The coalition is deliberately cross-industry: the parties that issue safety signals, the parties that enforce them at a surface, and the civil-society bodies, regulators, and academics who keep the whole thing honest.
- Issuers of safety signals
- Enforcement points at every surface
- Regulators, civil society & academics
Honestly forming
- Stated plainly: we are recruiting
- Honesty reads as credibility
- No wall of unearned logos
Charter cohort
- Closes Q3 2026
- Aligned with v1.0 ratification
- Seats the Trust Committee
No member owns it
- Vendor-neutral standard
- Consensus governance
- Open working groups
Phosra is one participant of many
Phosra founded OCSS and holds editorial stewardship of v1.0 through ratification. That is the extent of its special role: founder and steward of one draft. At ratification the editorial pen passes 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. From then on the Committee ratifies every major version and signs off on the conformance suite.
Founder and steward, not owner
No member, Phosra included, owns the standard, and governance transfers to the Trust Committee at ratification. The coalition is the point; the founder is one seat at the table.
- Editorial stewardship of v1.0, through ratification only
- Governance transfers to the Trust Committee at ratification
- One seat at the table, like every other member
Additive minor versions pass by simple majority. Breaking (major) versions and any capability deprecation require a two-thirds supermajority plus a 90-day public review and an 18-month deprecation window, so no faction can quietly delete a capability another vendor depends on.
The structure is the anti-capture mechanism: 3 of the 9 Trust Committee seats are reserved for named civil-society bodies, and accreditation runs on one organization, one vote, so a large implementer cannot accumulate weight proportional to market share.
Unresolved disputes escalate to the Council, then to binding neutral arbitration; the regulator observer seat cannot be outvoted into silence. Members may exit at any time; the license is irrevocable for published versions. Full mechanics on Mission & governance.
Open seats by category
The Charter cohort is recruiting across these categories. Each is an open seat, not a filled one, and several map to reserved seats on the Trust Committee. No member logos are shown, because the coalition has no signed members to display.
founding steward// real status shown · the registry opens at v1.0 ratification · charter cohort closing Q3 2026 · participant count today: 0 / forming
Every rule traces to a law
OCSS Rules is a vocabulary of ~100 typed categories, and the count is honest about its own ambiguity. The Go reference implementation enforces 96 categories; 104 are declared in the taxonomy (some reserved for laws not yet in force); 106 appear in the law-mapping table because a few statutes split across two categories. We publish "~100" rather than pick a flattering number, and v1.0 ratification reconciles all three to one canonical figure under the RFC-first change process. Below, a sample of how categories trace to the statutes that motivate them. The full registry of ~91 laws across 30+ jurisdictions lives on Resources.
| Rule category | Capability | Maps to (statute) | What it asserts |
|---|---|---|---|
os_age_signal_ingest |
Age | CA AB 1043 §1798.99.x | Consume an OS-level age band from Apple/Google rather than re-collecting birthdate. (CA AB 1043 is signed but phases in; OCSS implements it, and it is not yet enforced.) |
ai_chatbot_tier_gate |
Tier | NY S9051; CA SB 243 | Gate an AI companion against a four-tier risk scale; block simulated companionship for minors where the law requires it. |
parental_consent_gate |
Consent | COPPA 2.0; GDPR Art. 8 | Require verifiable parental consent before account creation or data collection for a child below the jurisdiction's threshold. |
algorithmic_audit |
Audit | KOSA §4(b); EU DSA | Mitigate algorithmic harms to minors and keep the recommender auditable: what it shows, why, to whom. |
commercial_data_ban |
Privacy | CA AADC §22675; UK AADC | Bar the sale or sharing of a minor's data and default to data-minimizing settings. |
nfk_hard_block |
Block | UK Online Safety Act | Hard-block titles a civil-society rating body flags "Not for Kids," with no soft-warning fallback. |
csam_reporting |
Receipt | 18 U.S.C. §2258A | Emit a signed, regulator-ready report for mandated CSAM/ICAC reporting paths. |
// "maps to" is a translation of a legal obligation into a typed, testable rule, not approval, endorsement, or legal substitution · KOSA and CA AB 1043 are pending/phasing-in, framed as "implements" not "compliant with enforced law" · ESRB / MPAA / PEGI are mapped-to, not endorsers
One category, end to end
A skeptical reviewer shouldn't have to take the taxonomy on faith. Here is ai_chatbot_tier_gate as a typed OCSS Rule, then the two-layer envelope that carries it on the wire. The intermediary reads the outer routing metadata and verifies the Ed25519 signature; the inner payload is JWE-sealed to the receiver and stays opaque to anyone in the middle.
Verify-before-enforce, normatively
Verify-before-enforce is a fixed sequence, and the order is normative. AEAD before trust would let a forged sender waste a decrypt, so decryption comes last.
(1) The receiver fetches the sender's JWKS and the Trust List entry. (2) It verifies the Ed25519 signature over the canonicalized outer per RFC 9421, binding the @method, @target-uri, created, and nonce components. (3) It confirms the sender's key is currently Trust-Listed and unexpired. (4) Using its own key, it decrypts the inner JWE (compact serialization, alg:ECDH-ES+A256KW, enc:A256GCM, with the AEAD tag verified before any plaintext is acted on). (5) Only then does it enforce on its surface: a DNS resolver, router, MDM profile, OS control, or app. A failed signature, a missing Trust List entry, or an AEAD tag mismatch is a hard reject, never a downgrade to a weaker rule.
This is not prose an implementer has to interpret. The rule envelope is published as a JSON Schema (2020-12), the Trust Framework wire format as CDDL alongside the RFC 9421 signature-base construction, and the decision logic (verify → trust-check → decrypt → enforce, with the hard-reject branches above) as a normative state machine an auditor can replay against the conformance vectors. family_hash is HKDF-SHA256(ikm=family_id, salt=receiver_id, info="ocss/family/v1"), keyed to the receiver, so the same child yields a different identifier at every receiver. Schema, CDDL, the state machine, and the vector repository land in Conformance with the suite (marked [draft], Q3 2026); the count-reconciliation (96 enforced / 104 declared / 106 mapped → one canonical figure) happens at v1.0 ratification under the RFC-first change process, not by editorial fiat.
How to read the registry
Every participant and every external reference on this site carries an explicit status chip. A visitor can trust the registry precisely because it never overstates a relationship. The states, from strongest to weakest:
A signed, active participant or Trust-Listed entity. A Trust-Listed intermediary appears in the cryptographically-signed Trust List: the machine-readable registry the Trust Framework distributes (modeled on the EU Trusted List, fetched and cached every 24 hours) so receivers can verify an intermediary's standing without a phone call. (None today; the coalition is forming.)
Application or accreditation in process, not yet complete.
An entity collaborating on the spec under agreement. Named only once a written agreement exists. Accreditation as a Trust Framework intermediary is not ceremonial: it requires a SOC 2 Type II audit, annual renewal, and cryptographic key rotation at least every 180 days. That is the hard floor under the Trust Framework's MUST / MUST-NEVER contract (an intermediary MUST verify every sender's Ed25519 signature and MUST NEVER decrypt the JWE-sealed payload it routes).
Early outreach underway; no agreement, no commitment. Not a member.
An illustrative name shown only to demonstrate a layout. Always labeled "Placeholder names shown; not endorsements."
A defined seat or category actively recruiting, with no party attached.
// if a name does not carry a live chip, it is not a member · we do not publish placeholder counters ("200+ organizations") as if real · real count today: 0 / forming
The registry is downstream of cryptography, not a marketing wall. The Trust Framework signs every routing envelope with Ed25519 (RFC 9421 HTTP Message Signatures), seals each payload to the receiver's key as a JWE envelope opaque to the intermediary, and publishes accredited intermediaries through an eIDAS-style, cryptographically-signed Trust List modeled on the EU Trusted List (in production since 2014). A receiver verifies a counterparty by checking signatures against that list, not by trusting a logo.
Threat model: what the design defends against
Key distribution & freshness
Each party publishes a JWKS at a stable endpoint; receivers cache it with the key's stated lifetime. The Trust List itself is a single signed document fetched and cached on a ≤24h background schedule (never inline), so signature verification stays O(1) per envelope and a Trust List timeout falls back to the last good cached copy rather than failing open.
Replay
The RFC 9421 signature covers a nonce and a created timestamp; receivers reject stale or already-seen envelopes, and every accepted envelope writes one immutable audit row — so a captured envelope can't be re-injected.
Cross-intermediary correlation, and the collusion bound
family_hash is keyed to the receiver via HKDF-SHA256(family_id, salt=receiver_id), so the same child routed through two intermediaries yields two unlinkable identifiers, and the MUST-NEVER contract forbids correlating routing metadata across families without consent. We state the bound honestly: this stops a passive intermediary from linking, but it does not defend against an issuer colluding with a receiver, since both hold inputs to the same derivation. That residual risk is governed, not hand-waved away. The audit trail and the MUST-NEVER clause are what bind it, and closing it cryptographically (unlinkable presentation via Longfellow-ZK) is on the v1.1 roadmap, not claimed for v1.0.
Trust List signing key & compromise window
The Trust List is itself a single point of trust, so its signing key gets the strictest handling in the design: held in an HSM under m-of-n threshold control, used only in a witnessed key ceremony, with a pre-published offline rotation key so the list survives a primary-key loss. Intermediary signer keys rotate at least every 180 days. A compromise is detected and acted on inside the cache window, not just on the next refresh: every list carries a monotonic sequence number and a next_update deadline, and receivers MUST treat a list past next_update or one that fails sequence-monotonicity as stale, refusing new senders rather than failing open. On a confirmed compromise the issuer pushes an out-of-cycle re-signed list and a CRL-style revocation; the target is detection-to-revocation in ≤24h, well inside the cache lifetime, with forced refresh faster. Because the inner payload is JWE-sealed to the receiver, a compromised intermediary can drop or stall traffic but never read it.
Concentration: the “3rd intermediary” case
A single dominant intermediary is treated as a failure state, not an efficiency. The pluralism guarantee bounds the blast radius: Trust List status goes Yellow below 3 accredited intermediaries and Red below 2, so trust never silently concentrates in one hub; federation only counts at ≥3. "N+M with a single + is just N×M renamed."
A stricter-rule downgrade is treated as an attack, not a fallback: a failed signature or a missing Trust List entry is a hard reject, never a quiet relaxation to a weaker rule. The spec is filed RFC-style at the IETF precisely so this threat model gets adversarial third-party review. Independent security audit of the spec and the Trust Framework crypto is part of the v1.0 ratification path, and academic working-group seats exist to do exactly that scrutiny. Full envelope schema and conformance vectors live in Conformance and on The Standard; current Trust List status is on Trust List.
We map to; we don't endorse
OCSS draws its vocabulary from existing rating systems and civil-society frameworks: age-appropriate-design codes, content-rating boards, child-development research. OCSS implements; it does not endorse.
Mapped-to is not membership
Mapping a statute or rating framework into the taxonomy does not make that body a member, partner, or endorser, and being mapped-to is not consent to be listed. Referenced bodies stay referenced unless and until they appear in the registry with a live chip.
Mapped-to is not approval, endorsement, or legal substitution for the law. OCSS translates a statutory obligation (say KOSA §4(b) or the California Age-Appropriate Design Code) into a typed, testable rule, enforced consistently across an app store, router, DNS resolver, and MDM profile. The statute remains the authority; OCSS is the wire format that carries it.
Who should join, and why
Each category joins for a concrete, structural reason, not for a logo on a wall.
Parental-controls operators & platforms
The ROI is structural: integrate once against the spec and reach every other party through the signed Trust List, an N + M shape rather than the N × M bilateral contracts you maintain today and re-cut every time a law passes or a platform ships. You build one verify-before-enforce path plus the rule categories for the capabilities you claim, and enforce one policy across app stores, devices, routers, and DNS through a single conformance test. Pass it and the Certified mark is a market trust asset a retailer or regulator can independently verify, not a badge you grant yourself. Version moves are governed (additive minors, 18-month deprecation on breaking changes), so the roadmap commitment is bounded, not open-ended.
Infrastructure & device vendors
Route signals against a shared, signed Trust List rather than negotiating N × M bilateral integrations. Accreditation is phased, not all-or-nothing: start as a Provisional intermediary routing Open content, earn Verified to add Gated, and reach Accredited to handle Restricted material (CSAM/ICAC paths) once you clear the conformance suite, a SOC 2 audit, and Trust List placement.
Regulators
Hold a reserved observer seat (advisory, non-voting) to verify that conformance is binary and testable and that each rule traces to statute, without anchoring policy to any one vendor. Your verification entry point is concrete: pull any party's Receipt by ID and recompute each signature against the signer's published JWKS, checking Trust List authenticity against the Linux Foundation AAIF root key (a former six-week subpoena becomes a ~30-second query), and replay the published conformance vectors against the normative state machine yourself. The suite is audited by approved third-party assessors (not by Phosra and not self-graded), and assessor approval criteria are part of the public charter. Drafts reach observers under NDA before ratification, with a comment window that closes before any text lands, so conformance review precedes statute alignment rather than chasing it. Changes follow an RFC-first process: a new or amended law (say if NY S9051 is revised) enters as an RFC, gets ≥30 days of public review before adoption, and lands as an additive minor version under SemVer. Breaking changes get a 90-day public review and an 18-month deprecation window.
Civil-society bodies
See your published frameworks mapped faithfully into a machine-readable contract, with the guarantee that OCSS maps to your work without speaking for you.
Academics
Adversarially review the security model (the signed envelope, the Trust List, the pluralism guarantee) and take working-group seats.
The full category list
Parental-controls operators, device/OS makers, carriers, civil-society bodies, regulator observers, and academics: each an open seat in the Charter cohort.
What it costs, what you build, when you can test
A product lead can't commit engineers to "one spec instead of 91 statutes" as a slogan. Here is the concrete trade. Without OCSS, a parental-controls vendor maintains a separate integration per upstream signal source and per jurisdiction: roughly N × M bilateral contracts that grow every time a new law passes or a new platform ships. With OCSS, each party integrates once against the spec and reaches every other party through the signed Trust List: N + M. You implement one verify-before-enforce path and the rule categories for the capabilities you claim. Once you pass conformance you display the certification mark, which is a market trust asset a regulator or a retailer can check, not a logo you grant yourself.
Self-attested against the rule list of each capability you claim. Public registry, no third-party check. Build the verify-before-enforce path; enforce on your surface (DNS / router / MDM / OS / app).
Independently verified by an approved assessor, with annual re-certification: the mark a retailer, regulator, or platform can rely on. Available at v1.0 (Q3 2026); Charter-cohort members get the draft suite first.
A seat in one of the four working groups (AI Safety, Privacy, Algorithmic Transparency, Hard Blocks) and the right to sponsor RFCs against the spec you build on.
Invite-only. Eligibility for the nine-seat Trust Committee that ratifies every major version once stewardship transfers from Phosra.
// indicative annual fees for the adopter ladder · separate from the Trust Framework intermediary ladder (Provisional → Verified → Accredited), which additionally requires a SOC 2 Type II audit and Trust List placement
Budgeting the intermediary path? The hard line items are external, so we name the real-world ranges rather than pretend they're free. A SOC 2 Type II audit is the gating cost: typically a 3–6 month observation window the first year and an order of $15k–60k in assessor fees depending on scope and auditor, then an annual renewal at the contract's MUST cadence (independent audit yearly, key rotation ≤180 days). That sits on top of the adopter-ladder fee above, not inside it. The point of stating it plainly: a product lead can put a number and a quarter against "become an Accredited intermediary," not just a logo.
When can we test our implementation?
The honest answer, dated, because an integration commitment needs a checkpoint, not a vibe:
Read the draft and build the path. The rule taxonomy and the envelope structure are published as Draft for Review. The worked example above gives you a typed rule, a two-layer envelope, and the five-step verify-before-enforce sequence with named primitives (Ed25519 / RFC 9421, JWE ECDH-ES+A256KW / A256GCM); that is enough to start the plumbing today. The JSON Schema and CDDL are the contract you code against in the interim; the conformance vector repository and CI examples land with the suite so you can wire them into your pipeline the moment they ship.
Conformance suite, marked [draft]. Test vectors and the suite arrive with the Charter cohort close and v1.0 ratification; we publish the suite when it exists, not a test count before it does. Early-access test vectors go to Charter-cohort participants first.
Certification opens. Self-attest for the "Implementer" mark; book an approved assessor for "Certified." The mark is then yours to display and a counterparty's to verify.
The Charter cohort closing Q3 2026 is the lever here: cohort members get the draft suite and test vectors before the public, and a seat in the working group that finalizes them. If your roadmap needs to integrate child-safety enforcement in 2026, that's the window to influence what you'll be tested against. Membership tiers and the join path are on Get Involved.
Latest
A forming coalition should show its clock. Here's where the work stands, dated. The full feed lives on News.
OCSS v1.0 published as Draft for Review. The two layers are open for comment: OCSS Rules (~100 typed categories) and the OCSS Trust Framework. Not ratified; this is the review window, not the final text.
Trust Framework filed at the IETF as draft-phosra-ocstf-00, with the Linux Foundation's Agentic AI Foundation proposed as the long-term governance home — the same body that took in MCP in December 2025.
Charter cohort recruiting across the twelve seat categories above; the cohort closes Q3 2026, aligned with v1.0 ratification and the seating of the Trust Committee.
Conformance suite in active drafting. Test counts and downloads are marked [draft] for Q3 2026; we publish the suite when it exists, not a number before it does.
Claim an open seat before the cohort closes.
The Charter cohort closes Q3 2026, aligned with v1.0 ratification. Join the coalition and take a seat at the table.