Frequently asked questions

OCSS has two layers. OCSS Rules define what a signal means: a taxonomy of ~100 typed categories (for example os_age_signal_ingest, ai_chatbot_tier_gate, parental_consent_gate) grouped under eight runtime capabilities. The OCSS Trust Framework defines how a signal moves and who’s trusted to assert it: a two-layer envelope with an outer Ed25519 signature per RFC 9421 (HTTP Message Signatures) and an inner JWE per RFC 7516 (key management ECDH-ES+A256KW, the static-receiver-key variant, so the sender needs no prior handshake; the Concat KDF of RFC 7518 §4.6 derives the wrapping key; content encryption A256GCM), an eIDAS-style Trust List of accredited intermediaries, accreditation tiers, and a MUST / MUST-NEVER conformance contract. The relationship mirrors WebAuthn + CTAP under FIDO2: the Trust Framework carries OCSS Rules as typed payloads. (Always written out as “OCSS Trust Framework,” never the bare acronym.)

The inner payload is a typed rule from the ~100-category taxonomy, not free text. A surface switches on the rule’s type, never a vendor’s proprietary schema:

Each accredited party publishes its current signing and encryption public keys as a JWKS at a stable, well-known URL keyed by kid; senders resolve the receiver’s encryption key from the Trust List entry, never from an unauthenticated lookup. The normative rule schemas, envelope format, and the ≤24h-cache Trust List entry model are specified in the Standard, §2.3; the end-to-end verify-before-enforce sequence is on the Trust List. The protocol versions under SemVer (additive = minor, breaking = major) with a 90-day public review and RFC-first change process. See the versioning policy.

No one owns it. Phosra is the founder and current steward of OCSS v1.0 through ratification. It holds editorial authority over the draft, and nothing more. At v1.0 ratification (targeted Q3 2026), authority transfers to the multi-stakeholder 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 ratifies every major version and approves the conformance suite. Phosra is one participant of many. Founder is not owner.

OCSS is Draft for Review: v1.0 is not yet ratified, and ratification is targeted for Q3 2026. The Rules taxonomy and the Trust Framework whitepaper (draft v0.1) are published for comment now, and the IETF Internet-Draft draft-phosra-ocstf-00 has been filed. The conformance suite is in active drafting. You can read, prototype against, and comment on the spec today; treat it as a draft, not a final standard.

Yes to both. The specification is openly licensed and royalty-free: free to read, implement, and redistribute, with no fee to build against it. Coalition membership tiers carry fees that sustain neutral governance, but membership is never required to implement the standard or to claim the self-attested Implementer mark.

OCSS is statute-traced: each rule in the taxonomy is mapped to the specific statute it implements, across 91 laws in ~30+ jurisdictions, among them KOSA, COPPA 2.0 and the FTC COPPA Rule, the EU DSA, the UK Age-Appropriate Design Code and Online Safety Act, Australia’s Online Safety Act, CA AB 1043, and NY S9051. The registry tracks each law’s status (54 enacted, 22 proposed, 7 pending, 5 under injunction, 3 passed), so the standard moves as legislation moves. Being mapped is implementability, not compliance: a rule mapped to a pending bill (KOSA, COPPA 2.0, CA AB 1043, NY S9051) implements the obligation that bill describes; it does not claim compliance with an enforced law. The mapping is provision-level, not law-level: COPPA’s §312 verifiable-consent obligation lands on parental_consent_gate under Consent; KOSA §4(b)(2) duty-of-care lands on Tier and Audit; EU DSA Art. 27 systemic-risk duties land on Audit; CA AB 1043 OS age-signal delivery lands on os_age_signal_ingest under Age. Each binds differently, which is the point of tracing the rule rather than asserting “91 laws mapped.” The full crosswalk (every rule against the specific provision it implements, filterable by jurisdiction) is the regulator-facing section For regulators: what this anchors to on the Trust List; you read the rule→provision mapping there without taking anyone’s word for it. OCSS is built on the law, not instead of it.

In the Trust Framework, an intermediary routes signed envelopes between parties without ever reading the payload. An accredited intermediary is one listed on the signed Trust List, having met the accreditation requirements for its tier: Provisional (routes Open signals), Verified (Open + Gated), or Accredited (Open + Gated + Restricted, including CSAM/ICAC, requiring the conformance suite plus a SOC 2 audit and Trust List placement). The list is eIDAS-style: machine-readable, cryptographically signed, fetched and cached at most every 24 hours. Federation requires plurality: the list degrades to Yellow below three accredited intermediaries and Red below two; see the pluralism guarantee and the accreditation tiers. Most products never become intermediaries. They integrate as issuers or surfaces against the same list.

The standard is built so that routing never requires identity. Age is carried as a derived band (for example “13–17”), not as an identity. The envelope is two layers: an outer layer with routing metadata and the sender’s signature, visible to the intermediary, and an inner layer JWE-sealed to the receiver’s key and opaque to the intermediary. Intermediaries operate under a hard MUST-NEVER contract: they MUST NEVER decrypt payloads, retain contents past delivery, correlate routing metadata across families without consent, or accept payloads that would re-identify a minor across intermediaries. A receiver-domain-separated family_hash prevents cross-intermediary correlation: it is an HMAC-SHA-256 keyed per receiver, with the receiver’s DID as the domain-separation input, so the same family resolves to a different tag at every receiver and no two intermediaries can join their logs on it. There is no PII in an OCSS Receipt.

What stops a single intermediary from building an identity graph over time? Domain separation defeats correlation across intermediaries; the constraint that defeats it within one is the MUST-NEVER clause that an intermediary MUST NEVER retain contents past delivery. A persistent hash→family map is retained content. Building a longitudinal graph from yesterday’s family_hash values is the prohibited behavior, not a loophole around it. The map is delivery-scoped by contract, and Accredited-tier intermediaries are audited (SOC 2 Type II) against exactly that clause. This is policy enforced by accreditation, not a cryptographic impossibility proof. An intermediary that ignores the contract is in violation and is delistable, which is the lever, not a claim that it physically cannot.

Threat model (stated so it’s testable). OCSS assumes honest-but-curious intermediaries and protects against: (1) intermediary correlation across families via routing metadata; (2) payload decryption by intermediaries; (3) PII leakage in Receipts; (4) replay: the RFC 9421 signature covers a created timestamp (a covered component required by the RFC) and a nonce, which OCSS raises from RFC 9421’s SHOULD to a normative MUST in the signature base; receivers reject a previously-seen nonce inside the created freshness window, and the RFC 8707 resource indicator scopes an envelope to one receiver, so a captured envelope cannot be replayed to a different surface; and (5) stricter-rule downgrade: an intermediary MUST NEVER weaken a rule in transit, and the receiver always takes the stricter of the wire rule and its own policy floor, so a misbehaving hop fails closed, never open.

Key compromise is bounded, not assumed away. v1.0 binds exactly one signature suite (Ed25519, no RFC 9421 algorithm negotiation, so there is nothing to downgrade), and every Trust-Listed key MUST rotate at most every 180 days, each rotation publishing a new kid beside the retiring one. Routine revocation rides the next signed list inside the ≤24h cache horizon, so a stolen key is usable for at most one cache cycle. For a key under active abuse, an out-of-band revocation bulletin signed by the Linux Foundation AAIF root key names the DID and kid and cuts it dead in minutes, without adding a per-decision call to any central authority. Everything chains to one pinned Linux Foundation AAIF root key held under offline, multi-party controls (IPR & trust anchor), not trust-on-first-use. An implementer pins that key out of band: it ships with the spec distribution and is fingerprinted in the release, never fetched from the network it is meant to authenticate; the step-by-step bootstrap & discovery procedure on the Trust List is what you follow to obtain and verify it before any signature is checked.

Honestly out of scope. OCSS does not protect against compromised end-party systems (a breached sender or receiver) or side-channel attacks (timing, traffic-analysis, or two intermediaries colluding outside the protocol), which sit outside the trust boundary and are the operator’s responsibility. Post-quantum migration is named, not hidden: the v1.0 suite is classical (Ed25519, ECDH-ES), and a PQ/hybrid signature path is a v1.1 roadmap item gated on the same SemVer-major RFC process, alongside TEE attestation (“Tier 4”). The full normative primitives are on the security model.

Example. A parental-control app learns a child is 16 (via an OS age signal) and queries the Trust List for accredited Block-tier intermediaries. It sends a request to enforce a hard-block rule against CSAM; the intermediary validates the sender signature, routes the sealed payload, and returns an immutable Receipt carrying the statute citation for the decision. The app stores that Receipt for parental review or a later regulatory inquiry — without ever exposing the child’s identity to the intermediary.

Read the spec and the implementer guides, then build against the capabilities you need. Conformance has two paths against the same spec: self-attested (Tier 0, the “Implementer” mark, free, listed in a public registry, no third-party check) and independently verified (Tier 1, the “Certified” mark, audited by an approved assessor, listed in a verified registry). You are tested against the rule list of each capability you claim, across the nine areas (Age, Tier, Consent, Block, Alert, Privacy, Audit, Receipt). The concrete path: read the typed rule schemas and envelope format in the Standard, §2.3; emit a signed signal or run the five-step verify-before-enforce sequence on your enforcement surface (DNS resolver, MDM/device profile, router, OS age-signal hook, or app-level gate); then run the suite for each capability and request the mark. See Conformance for the MUST / MUST-NEVER contract and both registries.

On the conformance suite itself, we’ll be precise rather than reassuring. It is in active drafting; the frozen, versioned test vectors and machine-checkable sample inputs publish in the conformance-suite repository in Q3 2026, alongside v1.0 ratification. That date gates the certification mark, not your ability to build and self-check today: the spec is implementable from the normative prose now, and the envelope examples, the typed-rule JSON schemas, and an illustrative Ed25519/JWE round-trip are on the reference code & test vectors section, enough to validate your verify-before-enforce path against worked examples before the frozen vectors land. What we will not do is hand you a vector set we then renumber; freezing it to the ratified spec is the point of waiting. Conformance follows the IETF idiom you’d expect: capability-scoped MUST/MUST-NEVER assertions tested as discrete vectors (in the spirit of RFC 8174 keyword normativity), with deprecation handled under the SemVer-major, 18-month-window versioning policy rather than ad-hoc removal (the discipline RFC 6648 argues for). We do not quote a test count we haven’t written, and we won’t pretend the suite ships before it does.

The ROI first. Today, to have your consent and tier decisions honored on someone else’s devices, you negotiate a bilateral integration per partner (a key exchange, a payload contract, an audit, a renewal) with every platform, OS, and carrier, one at a time. That is the N×M tax. Integrate once against the Trust List and you emit one typed, signed signal that every accredited surface already knows how to verify and enforce: N×M collapses to N+M, and a new accredited counterparty becomes reachable the moment it appears on the list, with no new code on your side.

What you build. You integrate as an issuer (you emit signals), a surface (you enforce them), or both. You do not need to become an intermediary. There is no API to hold or auth to budget for: you GET a static signed Trust List from a well-known URL, verify it against the pinned Linux Foundation AAIF root key, cache it ≤24h, and read it locally. The full path is on the Trust List.

The transition is additive, not a cutover. You do not flip a switch. While some platforms speak OCSS and others still want a bilateral deal, you run both: keep your existing per-partner integrations exactly as they are, and add the Trust List path alongside them. For a counterparty that’s accredited, you route the signed signal and retire that one bilateral contract on its own renewal cycle; for one that isn’t yet, nothing changes. There is no flag day and no contract you’re forced to break. OCSS support is something you turn on per counterparty as each appears on the list.

What you get, against what you spend now. The Certified mark runs $2.5–5k/yr including the approved-assessor audit. It is a third-party-verifiable claim a procurement team, an app-store reviewer, or a regulator can check, not a logo you self-apply. Set that against a single bilateral integration today: an engineer-month or more to build, plus the security review, the legal round, and the renewal, per partner, repeated for every platform, OS, and carrier you want to reach. The free Implementer mark gets you listed immediately at no cost. The trade is the recurring N×M integration line-item for a flat annual fee that does not grow with the number of counterparties; both marks sit on a public registry — see the cost breakdown.

Can you refuse an intermediary? Yes. Control stays with the operator. The intermediary never decrypts your payload (it’s JWE-sealed to the receiver), and you choose which accredited intermediaries you route through; pinning a subset is your decision, not the coalition’s. If an intermediary misbehaves, the MUST / MUST-NEVER contract is the lever: violations are cited in writing against a specific clause, with a defined remediation-or-appeal window to the Trust Committee (the body that admits, suspends, and revokes intermediaries), and sanctions propagate on the signed-list cadence, visible to every participant, with an out-of-band emergency bulletin for active abuse. Every routed decision leaves an immutable audit row you can replay, so “audit its logs” is a verifiable query, not a trust exercise.

OCSS maps to them; it does not speak for them. The standard provides typed categories that can carry an external rating or signal as a payload, so an existing rating system’s output can be enforced consistently across surfaces. Being mapped is not membership and is not endorsement. Bodies such as ESRB, MPAA, PEGI, NCMEC, and INHOPE are referenced as systems OCSS interoperates with, not as participants in the coalition. “OCSS implements; it does not endorse.”

Platforms, device and OS vendors, infrastructure and DNS operators, regulators (as observers), civil-society organizations, and academic researchers. The coalition is forming and the founding cohort is open, closing Q3 2026. Membership runs from a free self-attested tier up to an invite-only founding tier; see Get Involved for the tiers, benefits, and application. Membership buys a seat and a vote, not ownership of the standard.

A single vendor’s API recreates the N×M integration problem under a new name: every party still integrates bilaterally with that one hub, and that hub is a single point of control and failure. OCSS is designed for plurality: multiple accredited intermediaries on a signed Trust List, turning N×M bilateral integrations into N+M. The Trust List explicitly degrades its status when fewer than three accredited intermediaries exist, because “N+M with one + is N×M renamed.” Federation requires more than one trusted party by design, and the standard is owned by the coalition, not by any vendor — including its founding steward.

Not yet, and the site will not imply otherwise. The coalition is forming: no members have signed, and the Trust List and member registry are open but unpopulated. The honest state is “recruiting founding members,” which is exactly what this site says. Any organization listed in the future will be one that has signed a participation agreement; the standard does not claim endorsements it does not have.

Start with the statute traceback on the Trust List: a rule-to-provision crosswalk across 30+ jurisdictions, so you can see which OCSS rule maps to which clause (for example a Block-tier rule mapped to ["KOSA-§4(b)(2)","CA-AADC-§22675"]). At enforcement time, every decision produces an OCSS Receipt, a signed, timestamped record carrying the rule ID, capability, age band, jurisdiction, audit decision, the statute citation(s), and the enforcer: which intermediary routed it and which surface (DNS resolver, OS, MDM, router, or app) applied it. So you are not taking a vendor’s word that a rule was honored; you can see who enforced it, where. Receipts are replayable: request one by ID from the enforcing party’s audit endpoint, recompute each signature against the signer’s published JWKS, check the Trust List itself against the pinned Linux Foundation AAIF root key, and the immutable audit row is court-ready evidence, turning a six-week subpoena round-trip into a roughly 30-second query. You do not have to discover the AAIF root key on trust: it is published with the spec distribution and fingerprinted in the release, and the bootstrap & discovery procedure is the same one every implementer follows — no ministry “holds” it and there is no per-query call to a central authority. An accredited intermediary’s audit-row availability is part of its Trust List obligations, surfaced on the signed registry; suspension of a non-responsive party rides the same signed-list cadence. There is no PII to handle: age is a derived band (“13–17”), not an identity.

Two boundaries, drawn straight. First, a rule being mapped to a statute is a claim of implementability, not a certification of legal compliance; that determination remains yours. Second, where two jurisdictions read the same obligation differently — and they do — that divergence is resolved in policy, not in the spec. OCSS is jurisdiction-neutral by construction: a Receipt carries its own citations, so a GDPR DPA, the UK ICO, and a US state AG each read the same signed evidence against their own law without OCSS arbitrating between regimes. Reconciling conflicting interpretations across 30+ jurisdictions is not OCSS’s job and OCSS does not pretend it is. Regulators don’t accredit; they observe, via a reserved Trust Committee seat with read access to the conformance suite and the signed audit format.