From a statute to the surface: the life of one signal.
A child-safety obligation begins as words in a statute and must end as an enforced decision at a DNS resolver, a device profile, or an app. OCSS is the path between the two. This page walks one signal end to end: how a law becomes a typed Rule, how that Rule is sealed in a signed envelope, how it is routed through an accredited intermediary that can forward it but never read it, how it is verified, how it is enforced at the surface, and how the whole decision is recorded in a signed Receipt a regulator can replay.
How to read this page. Following RFC 2119 / 8174 convention, requirements written in MUST, MUST‑NEVER, and SHOULD are normative: binding on any conformant implementation. Prose, JSON samples, field values, and the worked examples below are informative: they illustrate the normative text but do not themselves impose requirements. Where the two could be confused, the normative claim is called out explicitly. OCSS v1.0 is a Draft for Review; the normative wording can still change before ratification.
The trust boundary, stated up front. The whole construction rests on one assumption a reviewer should challenge first: the Linux Foundation AAIF root key is trusted and uncompromised. The Trust List is signed under it; revoking it has no in-band recovery path in v1.0. We treat its custody as a governance problem, not a protocol one. It lives in offline HSM custody under the steward through ratification, after which control transfers to the Trust Committee (see Governance). We name it as the explicit root of trust so the threat model below can be argued against its real boundary rather than a hidden one. Everything else (intermediary keys, receiver keys, issuer keys) is rotated and revocable on a bounded schedule; the AAIF root key is the one node where compromise is catastrophic and therefore handled out-of-band.
A statute becomes a typed OCSS Rule
Legislation is prose; enforcement points need a contract. OCSS Rules are the translation layer. A provision (say, an age-tier gate on AI companions, or a "Not For Kids" hard block) is mapped to one of the ~100 typed rule categories, each organized under one of the eight runtime capabilities (Age, Tier, Consent, Block, Alert, Privacy, Audit, Receipt). The rule names what the signal means; it does not yet say who is asserting it or how it travels.
Crucially, each rule carries the statute citations that motivate it, so a decision can always be traced back to law across the 91 statutes mapped in 30+ jurisdictions. Build to the rule, not to the statute. When the law changes, the rule is updated once, and every implementer inherits it.
Where parental consent lives
For a parental-controls operator, the rule that matters most is rarely a block. It's consent. The Consent capability (§5) carries the 14 rules that govern verifiable parental authority: the grant itself, its scope, and its expiry. When a parent approves a teen's access to an age-tiered app, that grant becomes a typed signal a vendor can act on directly. OCSS doesn't replace your consent UX; it gives the decision a portable, signed shape so the same approval can be honored at the resolver, the device, and the app without re-prompting the parent at each one.
The grant rides in the same envelope (Stage 2) and produces a Receipt (Stage 6): a parent can see that consent was given, to whom, and for what scope, and revoke it later with the revocation propagating on the same ≤24-hour cache cycle as the Trust List. Consent here is an enabling primitive, not a restriction: it lets a controls vendor offer "approve once, enforced everywhere" instead of a per-surface maze.
What this looks like in your product
A worked example, end to end, for a parental-controls operator. Nothing about your consent UX changes; the OCSS-shaped output is what's new:
- Parent grants in your app. Your existing flow collects verifiable parental consent for, say, a 14-year-old's access to an age-tiered chat app. On approve, your backend emits one
parental_consent_gaterule (Consent §5) with ascope(apps/categories), anexpiry, and the verifiedage_band. - It's sealed and routed once. The grant becomes the inner JWE payload of one envelope (Stage 2), addressed to the receivers that enforce it. You do not integrate separately with the DNS resolver, the MDM profile, and the app. You emit one signal.
- Every surface honors the same scope and expiry. The grant carries its own scope and expiry, so the resolver, the device profile, and the app act on identical bounds. When surfaces could disagree, precedence (§5.5) is normative: a stricter statutory floor or a hard block MUST‑NEVER be downgraded by a broader parental grant: consent can permit within the law, never below it.
- Revocation is one call, with proof. The parent revokes in your dashboard; you re-emit the grant with a revoked status. It propagates on the ≤24-hour cache cycle, and the change is itself recorded as a Receipt (Stage 6) the parent, or a regulator, can verify. No surface keeps enforcing a withdrawn grant past the cache window.
What you implement is small: emit the typed Consent rule and consume Receipts. What you get is a certification mark (Stage, conformance below) that signals to families and partners that your "approve once, enforced everywhere" claim is independently checkable. That is a market-trust asset in its own right, beyond the protocol detail.
What adoption actually costs you
The honest version, so you can size the work before committing engineers. The core integration is two pieces (emit one typed rule, consume Receipts), and the federation does the fan-out. The cache caveat is real and worth planning for: when your backend is briefly down, surfaces keep enforcing the last rule cached within its cache_until, so a parent's existing approval doesn't drop. A brand-new grant you can't emit won't propagate until you're back, which is the same availability profile your own API already has.
| What you do | Rough effort | Cost / mark |
|---|---|---|
| Emit one typed Consent rule from your existing grant flow + consume Receipts | Integration-scale, not platform-scale: you wire two message shapes, not a fleet of bilateral connectors | Implementer mark · self-attested · free · public registry |
| Add envelope verify-before-enforce (Ed25519 / RFC 9421 + JWE) on surfaces you operate | Off-the-shelf crypto libraries; the suites are pinned (no algorithm menu to get wrong) | Prerequisite for the verified path |
| Independent audit against the capabilities you claim | Once-yearly assessor review (suite targeted Q3 2026) | Certified mark · verified registry · annual fee. See Conformance |
Effort here is directional, not a quote. Actual cost depends on how many enforcement surfaces you operate and which capabilities you certify. The ROI is the same regardless of size: one signal replaces N bilateral vendor integrations, and the certification mark turns your safety claim into something a regulator or retail partner can verify without taking your word for it.
"category": "ai_chatbot_tier_gate",
"capability": "tier",
"severity": "MUST",
"age_band": "13-17",
"cite": ["CA-SB-243", "NY-S9051"]
}
The Rule is wrapped in a two-layer signed envelope
A typed rule on its own carries no proof of who is speaking. OCSS solves this with a two-layer envelope. The outer layer holds routing metadata and an Ed25519 sender signature over RFC 9421 HTTP Message Signatures. This is what an intermediary reads to route the message and to confirm the sender is who they claim to be. The inner layer is the rule payload itself, JWE-sealed to the receiver's public key, opaque to anyone in transit.
To stop two conformant implementations from diverging, v1.0 pins the primitives rather than leaving the cipher menu open. The inner JWE is not negotiable per-message: the only conformant suite is alg: ECDH-ES+A256KW key agreement to the receiver's X25519 key with enc: A256GCM content encryption (RFC 7518 / 8037): a single suite, so there is no algorithm-confusion surface to downgrade across. The outer signature is Ed25519 only. The RFC 9421 signature base is fixed too: the covered components are @method, @target-uri, content-digest (the whole inner JWE), created, and nonce, with the keyid carrying the sender's JWKS kid. Pinning the covered set is what lets a receiver reconstruct the exact signature base; "verify the outer layer" is otherwise underspecified by RFC 9421's flexibility.
A family_hash groups a household's signals at one receiver without letting two intermediaries correlate the same family across the network. The construction is named so two implementers can't diverge and quietly defeat the guarantee: family_hash = HKDF-SHA-256(ikm = family_id, salt = receiver_public_key, info = "ocss/family-hash/v1"), truncated to 128 bits. Because the salt is the receiver's key, the same household resolves to a different hash at every receiver. Concatenation or a bare HMAC would not give this domain separation, which is why the KDF and its inputs are normative, not illustrative. The outer layer answers "who is speaking and where does this go"; the inner layer answers "what was said," and only the intended receiver can open it.
The signing keys behind that outer layer are not assumed to live forever: the intermediary conformance contract specifies key rotation (MUST ≤180 days) and revocation latency (Trust List cache invalidation ≤24 hours) as binding requirements, both defined in the OCSS Trust Framework, so a leaked key has a bounded blast radius rather than an open-ended one. Each party publishes its own JWKS, so rotating or revoking one party's key never requires re-keying the network.
Replay freshness, with numbers. A flexible signature scheme is only as good as its freshness bounds, so OCSS pins them instead of deferring to RFC 9421 alone. A receiver MUST reject an envelope whose RFC 9421 created is more than 300 seconds old or more than 60 seconds in the future (a deliberately asymmetric skew allowance), and MUST reject a repeated nonce seen within that window. The receiver keeps a per-sender seen-nonce set for the 300-second horizon, which is what closes replay without unbounded state. These bounds presume loosely synchronized clocks (NTP-class, sub-second to low-seconds); the 60-second forward tolerance is the budget for skew, and an implementer does not get to widen the window to paper over a misconfigured clock. During key rollover, both the old and new kid are valid only for the JWKS validity overlap the publishing party declares; a nonce is scoped to a kid, so a rolled key cannot be used to replay an envelope signed under the previous one.
Threat model (informative)
The envelope is built to defend a specific set of properties. Stated plainly, so a reviewer can argue with them:
| Attack | Defended by |
|---|---|
| Intermediary eavesdropping on rule contents | Inner payload is JWE-sealed to the receiver's key; the routing party only ever holds ciphertext. |
| Sender impersonation / envelope forgery | Ed25519 signature over the outer layer (RFC 9421 HTTP Message Signatures), verified against the signed Trust List before routing. |
| Replay of a captured envelope | The RFC 9421 signature covers a created/nonce component; a receiver rejects an envelope outside its freshness window. |
| Cross-intermediary family correlation via metadata | family_hash is domain-separated per receiver, so two intermediaries cannot link the same household by comparing routing metadata. |
| Key compromise | Bounded by the ≤180-day rotation MUST and ≤24-hour Trust List revocation window; per-party JWKS limits blast radius to one party. |
| Silent rule downgrade by an enforcement point | Precedence (§5.5) is normative: a stricter rule MUST‑NEVER be downgraded, and the resolved decision is signed into a Receipt (§6). |
| Inner JWE fails to decrypt (wrong key, tampered ciphertext, A256GCM tag mismatch) | Fail closed: the receiver discards the envelope, enforces nothing from it, and emits a Receipt recording the verification failure. It never falls back to plaintext or "best-effort" enforcement. A decrypt failure is indistinguishable to the receiver from forgery and is treated as such. |
Explicitly out of scope. TLS 1.3 between every hop is a mandatory deployment assumption, not something the envelope re-provides. The signed envelope defends contents end-to-end, but transport confidentiality and downgrade resistance are TLS's job, and a non-TLS deployment is non-conformant. OCSS does not specify key storage at the endpoints (an HSM is a deployment choice, not a protocol guarantee), and does not by itself defend against a compromised Trust List operator: that risk is handled at the governance layer through accredited, independently audited operators and the pluralism requirement (≥3 intermediaries), not by the envelope. Receipt and Trust List forgery both reduce to AAIF root key compromise, which is the named root of trust front-loaded in the preamble: out of band by design, with custody (offline HSM, steward → Trust Committee transfer) treated as governance rather than a protocol guarantee. There is no formal machine-checked security proof in v1.0, which is appropriate for a draft at this stage, and it is called out here so a reviewer knows it is absent rather than assumed.
"outer": {// visible to intermediary
"from": "did:ocss:issuer:...",
"to": "did:ocss:receiver:...",
"sig": "ed25519:...", // RFC 9421
"family_hash": "..."
},
"inner": "<JWE>" // sealed to receiver key
}
Routed through an accredited intermediary that forwards, but cannot read
The sealed envelope is handed to an accredited intermediary on the Trust List. The intermediary reads the outer layer, validates the sender signature, and forwards the message to the receiver named in the routing metadata. This is the structural guarantee that distinguishes OCSS from a vendor hub: the party that moves the signal cannot read the signal. Trust comes from accreditation and audit, not from access to the contents.
The intermediary routes the envelope; it never opens it.
read(envelope.outer) // ok
verify(outer.sig) // MUST
forward(outer.to)
audit_log.append(...) // MUST
read(envelope.inner) // MUST-NEVER
Verified against the Trust List before any rule is read
Before a receiver acts on a rule, it verifies the envelope against the Trust List: a machine-readable, cryptographically signed registry of accredited intermediaries, modeled on the EU Trusted List (the EUTL, in production since 2014). Implementations fetch and cache it for no more than 24 hours, so revocations propagate quickly.
The Trust List also encodes a pluralism guarantee: its status reads Yellow when fewer than three accredited intermediaries are listed and Red below two: "federation-grade" requires at least three independent intermediaries. A network with a single intermediary is the N×M bilateral problem renamed; the spec refuses to call that federation. Verification is the gate: an envelope from an unaccredited or revoked sender is rejected before the rule payload is ever opened.
The verify-before-enforce sequence is fixed, and order matters: a receiver MUST (1) fetch or use a Trust List cached for ≤24h, (2) confirm the sender entry is present and not revoked, (3) verify the Ed25519 / RFC 9421 signature over the outer layer, (4) check freshness against replay, and only then (5) decrypt the inner JWE and enforce. The rule payload is never opened for an envelope that fails any earlier step.
Failure modes (informative)
What a conformant implementer does when verification can't complete cleanly:
- Trust List fetch fails / operator down. Keep enforcing on the last list cached within its ≤24h validity; refuse to act on a list older than its window. Fail closed for new senders, not for already-verified ones.
- Trust List poisoning. The list is itself a signed object; a receiver verifies its signature against the AAIF root key before trusting any entry, so an injected or tampered entry is rejected at fetch time, not at routing time.
- Key rotation lands mid-flight. Because each party publishes its own JWKS with overlapping validity, a signature made under the previous key verifies until that key's validity ends; a receiver that sees an unknown
kidre-fetches the JWKS before rejecting. - Intermediary unavailable mid-fetch. Fail closed for delivery, but never for an already-verified rule. A receiver that loses its intermediary keeps enforcing rules already verified and cached (within their
cache_until); it does not accept a new rule it cannot route and verify. Because routing is to "any accredited intermediary listing the target" rather than a pinned hostname (§7), a single operator dropping mid-fetch degrades latency, not enforcement: the receiver retries via another listed intermediary. - Unverified or revoked envelope. Rejected before decryption. There is no "best-effort enforce" fallback for an envelope that fails signature or Trust List checks: the spec treats an unverifiable safety signal as no signal.
Enforced at the surface
Once verified, the rule is enforced wherever the child actually is, and the same typed signal produces a consistent decision regardless of surface. When two rules apply, the strictest wins: an enforcement point MUST‑NEVER downgrade a stricter rule. The point of OCSS is that this happens identically at every layer without any vendor re-implementing the obligation.
Whichever surface you ship, the path to a public claim is the same: implement the rule list for each capability you support, run the conformance suite (in active drafting, targeted Q3 2026), and earn the certification mark. There are two marks for two paths: Implementer (Tier 0, self-attested, free, public registry) and Certified (Tier 1, independently audited, verified registry). The mark is what turns "we support OCSS" into something a partner or regulator can check. Full criteria on Conformance.
DNS
A resolver blocks or filters domains for a flagged category before a connection is ever made: the age band and tier gate arrive as a typed signal, not a hand-maintained blocklist.
MDM
A managed-device profile applies app, content, and screen-time policy at the OS management layer for a supervised child account.
Router
A home or network router enforces household policy at the gateway, covering every device on the network including those without an agent.
OS
The OS consumes an OS-level age signal (e.g. CA AB 1043's os_age_signal_ingest) and exposes the verified age band to apps, so each app does not re-collect identity.
App
The application itself applies tier gates, hard blocks, and consent requirements at the feature level: the last and most specific surface.
All five surfaces implement rule precedence identically: when an age gate (Tier) and a hard block (Block) both apply to the same target, the hard block takes precedence. Implementers do not re-engineer this logic per surface; the precedence outcome is fixed by the spec, so a DNS resolver and an in-app feature flag resolve the same conflict the same way.
Which obligation each rule carries
For an auditor, the question is always "which rule satisfies which obligation." Each OCSS Rule carries the statute citations that motivate it, drawn from the 91 laws mapped across 30+ jurisdictions. A representative slice follows; the full crosswalk lives on Resources (Legislation). Pending bills are framed as implements, not "compliant with enforced law."
| Obligation | Capability | Rule category |
|---|---|---|
| KOSA §4 duty-of-care / design (pending: implements) | Tier · Audit | algorithmic_audit |
| CA AB 1043 OS-level age signal (pending: implements) | Age | os_age_signal_ingest |
| NY S9051 AI-companion prohibition | Tier · Block | ai_chatbot_tier_gate |
| COPPA 2.0 / FTC COPPA verifiable parental consent | Consent | parental_consent_gate |
| UK Online Safety Act / UK AADC | Tier · Privacy | commercial_data_ban |
| EU AADC / GDPR Art. 8 | Privacy | commercial_data_ban |
| 18 U.S.C. §2258A/B CSAM reporting | Block · Receipt | csam_reporting |
Content-rating systems (ESRB, MPAA, PEGI) are mapped to, not endorsed; OCSS reads their ratings as inputs where a rule references them. The CSM age-rating and privacy tiers above are referenced obliquely as a civil-society 4-tier risk scale: an outreach relationship, not a signed partnership.
When rules collide, the strictest wins
Real deployments routinely have more than one rule pointing at the same enforcement point: a household policy, a jurisdiction's statutory floor, and a platform's own safety setting can all land on one decision. OCSS makes the resolution normative rather than implementation-defined: when multiple rules apply to one enforcement point, the strictest rule wins, and an enforcement point MUST-NEVER downgrade a rule to allow behavior a stricter rule forbids.
This was previously implied by the per-capability severities; v1.0 states it as a first-class conformance rule so two conformant implementations cannot disagree about a contested decision. "Strictest" is ordered within a capability (Block outranks Warn outranks Allow within Tier; a hard block in §6 is terminal), and a stricter rule from any source overrides a more permissive one regardless of which party asserted it. There is no "vendor override" path that re-opens a closed door.
Revoking a single rule mid-cache
Trust List revocation removes a party; it does not retract a rule. A rule has its own lifecycle, which matters when a provision is struck down, enjoined, or repealed while still inside an enforcement point's cache. So OCSS separates the two: each emitted rule carries a cache_until bound and a stable rule ID, and a source revokes an individual rule by re-emitting it with a revoked status under the same ID, distinct from rotating the source's signing key or pulling it from the Trust List.
An enforcement point MUST honor a rule revocation within its cache window and MUST‑NEVER keep enforcing a rule whose cache_until has lapsed without re-fetch. For a provision invalidated faster than the ordinary cache horizon (an emergency injunction, say), the source that owns the rule MUST emit the revocation, and when an injunction names a specific rule the conformance profile requires it carry a shortened cache_until matching the order's effective time. The same Receipt mechanism (§6) records that the rule was withdrawn and when. The result: a repealed or enjoined rule stops being enforced on a bounded, provable schedule, a normative duty on the source rather than a discretionary "can emit," without waiting for a key to rotate or a party to be de-listed.
Testing precedence before the suite ships
Precedence is the most error-prone surface to implement, and the formal conformance suite is in active drafting (targeted Q3 2026), so the spec does not leave implementers waiting. Precedence resolution is specified as a pure function: resolve(rules[], target) → decision takes the set of applicable rules and returns one decision with no I/O, no clock, and no network. That makes it testable in isolation today, ahead of the full suite, against the published precedence ordering: within a capability the order is fixed (e.g. Block > Warn > Allow within Tier), a hard Block in §6 is terminal, and a stricter rule from any source wins regardless of who asserted it. The draft ships a starter set of signed precedence test vectors (input rule sets paired with the one correct decision) with the spec text on The Standard; the full conformance suite extends these rather than replacing them, so a vector that passes today still passes against the Q3 suite. Build resolve() as a pure function, run it against the vectors, and your precedence logic is checkable before a single envelope crosses the wire.
A signed Receipt is emitted
Every enforcement decision produces an OCSS Receipt: a signed, regulator-ready record of what was decided and why. A Receipt signs the rule ID, the age signal, the jurisdiction, the capability, the audit decision, and the statute citation as Ed25519 over typed data, domain-separated by spec version. The underlying audit row is HMAC-SHA256-signed and append-only. It carries no PII: age is a derived band such as "13–17," never an identity.
Receipts are replayable: a regulator requests one by ID and recomputes each signature against the issuer's published JWKS, turning what is today a six-week subpoena into a roughly thirty-second query. This is what makes conformance auditable rather than asserted. The decision is made and then provable after the fact.
Regulators can request any Receipt by ID and verify it in approximately 30 seconds against the issuer's published JWKS: no vendor cooperation, no proprietary tooling, just the published keys and the signed record. Verification is fully offline: a regulator recomputes the Ed25519 signature against the issuer's published keys on its own machine, so the immutability of an audit trail is checkable without trusting the operator's database. A row that was altered no longer verifies, full stop. The authenticity of the Trust List those issuers are listed on is itself a fair question for a regulator to ask, and the answer is governance, not a vendor: the Linux Foundation AAIF root key that signs the Trust List sits in offline HSM custody under the steward through ratification, after which control transfers to the Trust Committee. Civil society is structurally embedded in that 9-seat body: 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. For seat composition and technical briefing details, see Governance.
How a regulator actually fetches one
"Request by ID" is concrete, not rhetorical. A Receipt is held by the issuing party (the enforcement operator), addressable by its id:
- Endpoint. A conformant operator exposes
GET /ocss/receipts/{id}returning the signed typed-data record. Verification is offline: the regulator recomputes the Ed25519 signature against the issuer's published JWKS with no call back to the operator, so a record can be validated even if the operator later disappears. - Authentication, and revoking stale credentials. Read access is scoped by an RFC 8707 resource-indicator token; a regulator's credential is bound to its jurisdiction, so it retrieves Receipts for decisions in scope, not the whole corpus. Those tokens are not open-ended: a conformant operator MUST bind each auditor credential to an expiry and honor revocation of a named credential within the same ≤24-hour window as a Trust List entry, so an auditor who leaves their post or loses standing cannot keep pulling records on a stale token. The credential lifecycle is the same normative lever regulators already understand from the Trust List, applied to access rather than routing.
- Retention, with a normative floor. Retention is not a unilateral operator choice in v1.0. An operator MUST retain Receipts for the longest of (a) a baseline conformance floor set by the profile for the capabilities it certifies, or (b) any statutory retention the governing jurisdiction imposes, whichever is longer, never shorter. An operator publishes its specific window in its conformance profile, but it cannot publish a window below the floor and remain certified. The auditable claim is the signature, not uptime, so an expired or rate-limited fetch never invalidates a record a regulator already holds. But the floor means the record has to exist to be fetched.
- No PII. The returned record carries a derived age band, never an identity: a regulator verifies that the right decision was made without acquiring the child's data.
This is the difference between conformance that is asserted and conformance that is checkable: independent audit results flow into the verified registry (see Conformance), and any individual decision is replayable from its Receipt. The exact endpoint shape is informative; the normative requirement is that a Receipt be independently verifiable against the issuer's published JWKS.
"id": "rcpt_...",
"rule": "ai_chatbot_tier_gate",
"capability": "tier",
"age": "13-17", // derived band — no PII
"jurisdiction": "US-CA",
"cite": ["KOSA-§4(b)(2)", "CA-AADC-§22675"],
"audit": "BLOCK",
"issued_at": "2026-06-01T00:00:00Z",
"spec": "OCSS-v1.0",
"sig": "ed25519:..."
}
Why not just integrate vendor-to-vendor?
The N×M problem, and why plurality is a conformance requirement, not an aspiration.
The default way the industry connects safety systems is bilateral: each of N policy sources builds and maintains a private integration to each of M enforcement surfaces. That is N × M connectors: every one of them lossy, hand-maintained, and re-engineered whenever a law or a partner changes. It does not scale, and it quietly concentrates power in whoever owns the most integrations.
OCSS replaces the mesh with a shared contract. Every source emits one typed signal; every surface reads one typed signal. The integration count collapses from N × M to N + M. But N+M only holds if the "+" is genuinely plural. If a single intermediary sits in the middle, you have re-created N×M and renamed it. That is why the spec makes plurality a conformance requirement: federation-grade status requires at least three independent accredited intermediaries, and the Trust List degrades to Yellow below three and Red below two. Interoperability without plurality is just a new monopoly with better marketing.
How a platform actually reaches ≥3 without re-building a silo. The point of plurality is that no adopter has to run the federation itself. You integrate against the contract (emit and consume the typed envelope), and the Trust List does the discovery. Operationally that means: an enforcement surface verifies against the signed Trust List rather than pinning one intermediary's hostname; it routes to any accredited intermediary that lists the target receiver, so a single operator outage degrades latency, not availability; and adding redundancy is adding a Trust List entry, not negotiating a new bilateral contract. Independence is a Trust Framework requirement: accredited intermediaries are separately audited (SOC 2 Type II minimum) and the Trust List degrades to Yellow if three independent operators aren't present, so "three" can't be satisfied by one vendor running three nodes. A platform building to OCSS commits to one integration and inherits the federation; it does not stand up the mesh.
What the normative claims rest on
The specifications and standards this page's normative requirements are built against. Normative references define behavior a conformant implementation must follow; informative references provide background or precedent.
Normative
- RFC 2119 / RFC 8174: Key words (MUST, MUST‑NEVER, SHOULD) for requirement levels.
- RFC 9421: HTTP Message Signatures; carries the Ed25519 sender signature on the outer envelope layer.
- RFC 8037: Ed25519 (EdDSA) signatures over JOSE; JWE (RFC 7516) for the sealed inner payload.
- RFC 8707: Resource Indicators; scopes regulator and receiver access tokens.
- OCSS Trust Framework (Draft v0.1): per-party JWKS, signed Trust List, ≤180-day key rotation, ≤24-hour revocation window, intermediary MUST / MUST‑NEVER contract. See The Standard.
Informative
- EU Trusted List (EUTL): eIDAS-style signed trust registry, in production since 2014; the precedent the OCSS Trust List is modeled on.
- draft-phosra-ocstf-00: the OCSS Trust Framework as filed at the IETF.
- draft-knodel-age-arch-00: the Issuer / Verifier / Gatekeeper / Infrastructure role model OCSS extends.
- RFC 8032 (EdDSA): Ed25519 over typed data, domain-separated by spec version, is the Receipt signing convention; W3C Digital Credentials API + OpenID4VP are SHOULD-level for credential presentation.
Read it, then test it against your stack.
The specification is a Draft for Review and the conformance suite is in active drafting (targeted Q3 2026). Read the normative text, prototype against the rule taxonomy, and tell us where it breaks.