Trust List / Registry

The OCSS Trust List is modeled directly on the EU Trusted List (EUTL), the registry that, since 2014, has let any relying party in Europe verify which trust-service providers are qualified without a central lookup. OCSS borrows that architecture deliberately:

• Signed, not API-gated. The list is a single signed document, fetched and cached by each participant for no longer than 24 hours. There is no central verify API on the critical path. A participant verifies the list's signature against the Linux Foundation AAIF root key, caches it, and routes against its local copy. Availability of the standards body is never load-bearing on an enforcement decision.
• Cryptographically anchored. Each entry binds an accredited entity to a decentralized identifier (did:ocss:…) and the JWKS: the public keys it signs with. Per RFC 9421 HTTP Message Signatures, a signal's outer envelope carries an Ed25519 signature plus a resource indicator (RFC 8707) scoping the envelope to its intended receiver. A verifier resolves the sender's DID against the cached list, pulls the matching kid from its JWKS, and checks the signature. No network round-trip, no trust-on-first-use. a registry entry binds a DID to the keys it signs withdid did:ocss:example-corp JWKS { "keys": [ { "kty": "OKP", "crv": "Ed25519", "kid": "2026-01", "x": "11qYAYK…" } ] }
• Append-and-revoke. Entries carry a validity window. Routine revocation rides the next signed list, within the 24-hour cache horizon: short enough to contain a compromised key, long enough that an intermediary stays reachable when the standards body is down. That window is a deliberate trade, not an oversight. A stolen key is usable for at most one cache cycle. OCSS bounds the exposure instead of eliminating it, because the alternative (a soft-fail on a live revocation lookup before every enforcement decision) would put the standards body back on the critical path, which is the exact dependency the design exists to remove. For the case where one cache cycle is too long, §4a defines an out-of-band emergency revocation path.

The Trust List is the who's trusted half of the OCSS Trust Framework. The signed-envelope format is the how signals move half; the Trust List tells a receiver whether the entity that signed an envelope is one it should accept. Parental-control vendors and family-safety apps integrate against the same Trust List to route signals to accredited intermediaries, so a consent decision a parent makes in one product, and the enforcement rules it triggers, travel unchanged to every device and surface that resolves the same list.

A crypto reviewer should not have to infer the primitives. They are fixed, and they are normative:

• Outer envelope: signature is Ed25519, MUST. The routing layer is an RFC 9421 HTTP Message Signature. v1.0 binds exactly one algorithm: Ed25519 over the covered components. RFC 9421's multi-algorithm machinery is intentionally not open in v1.0. A single mandated suite removes downgrade negotiation, and adding a second algorithm is a SemVer-major change gated on the working-group RFC process. A verifier that sees any other alg rejects the envelope.
• Inner envelope: JWE sealed to the receiver. The payload is a JWE in Compact Serialization with alg: ECDH-ES+A256KW (or direct ECDH-ES) and content encryption enc: A256GCM. The intermediary sees the outer routing metadata and never the plaintext; it cannot decrypt, and the MUST-NEVER contract forbids it from trying. The receiver's encryption key is the same key published in its Trust List JWKS, so the sender needs no side channel to obtain it. Forward secrecy across the archive is structural, not incidental: ECDH-ES derives a per-message content key from an ephemeral sender key, so an archived envelope opened years later, even with the receiver's long-term key, exposes only that one message. There is no shared session key whose compromise unzips a whole correspondence.
• Cross-intermediary correlation is designed out, and the derivation is published, not hand-waved. Routing carries a family_hash = HKDF-SHA256(ikm = household_secret, salt = receiver_did, info = "ocss/family-hash/v1"), truncated to 128 bits. The salt is the receiver's DID, so the value a household presents to intermediary A is unequal to the one it presents to intermediary B: two colluding intermediaries hold outputs of the same PRF under different salts and cannot join them. Because household_secret is high-entropy (never a guessable identifier like an email or phone number), an adversary holding many signals from the same household (the known-plaintext case) still faces a keyed PRF with no shorter path than guessing the secret. Re-identifying a minor across intermediaries is an explicit MUST-NEVER, and the derivation is fixed in the spec so a cryptographer can audit it rather than trust the claim.
• Replay is bounded by the envelope, not the network. The RFC 9421 signature covers a fixed component set (@method, @target-uri, content-digest, plus the signature parameters created, nonce, and keyid), and the RFC 8707 resource indicator scopes the envelope to one receiver. A captured envelope cannot be replayed to a different surface. The acceptance window for created is ±300 seconds of clock skew; a verifier remembers nonces for the width of that window so a same-window replay is also caught. Anything older is stale and dropped.
• Stricter-rule downgrade is rejected. An intermediary MUST NEVER weaken a rule in transit. It may not turn a nfk_hard_block into a warning or relax a tier gate. The receiver re-evaluates the typed rule against its own policy floor and takes the stricter of the two, so a misbehaving hop can fail closed but never fail open.
• Key compromise is bounded by rotation. Every Trust-Listed key MUST rotate at most every 180 days, each rotation publishing a new kid alongside the retiring one. A compromised key's blast radius is therefore one cache window for revocation plus one rotation interval for issuance: both finite, both stated, neither relying on the standards body being online.

Trust anchor. Everything chains to one root: the Linux Foundation AAIF root key. It is the governance root of trust that signs the Trust List and signs no payloads. It is distributed with the spec and pinned by each participant at integration time, not learned trust-on-first-use from the network. A participant that has the AAIF root key can verify the Trust List signature, and from the list, every intermediary's JWKS. A compromised root key is the one event the cache horizon does not contain, so the AAIF root key is held under documented governance controls (offline, multi-party) and its rotation is itself a published, signed event, never a silent swap.

DID resolution. A did:ocss:… is not resolved over the open network. It resolves inside the signed Trust List: the list is the resolver. The entry for a DID carries that entity's JWKS inline, so there is no separate DID-document fetch for a network attacker to hijack, no DNS step to poison, and no JWKS endpoint whose availability becomes load-bearing. The only thing a verifier trusts over the wire is the list document itself, and that is checked against the pinned AAIF root key before any entry in it is believed.

Emergency key handling. An intermediary publishes two keys at all times: the active signing key and a pre-registered next key (a distinct kid already in its JWKS). Routine rotation promotes the next key on the ≤180-day cadence. An emergency (suspected compromise) skips the cadence: the steward (or, post-ratification, the Trust Committee) issues the revocation bulletin of §4a against the live kid, the operator promotes its pre-registered next key immediately, and the gap is bounded by bulletin propagation rather than a full rotation interval. Because the standby key was registered ahead of the incident and never co-located with the active one, emergency rotation never requires minting trust from a cold start.

Post-quantum posture, stated honestly. v1.0 is classical: Ed25519 for signatures, ECDH-ES for envelope key agreement. Both are durable against today's adversaries and neither is claimed to be quantum-resistant. The standard's response is structural rather than a premature primitive swap. Signatures are short-lived, bounded by the ≤180-day rotation and the ≤24-hour list horizon, so a future quantum forgery has a narrow, expiring window rather than a standing one. Confidentiality is the harder problem (a "harvest-now, decrypt-later" adversary archives today's JWE for a future quantum machine); the PQ migration path is therefore scoped to the envelope, gated on the NIST ML-KEM (FIPS 203) ecosystem maturing in JOSE, and tracked as a SemVer-major change through the working-group RFC process: additive hybrid suites, never a silent algorithm flip. It is named here as a known item on the roadmap, not buried.

Who decides. Through v1.0 ratification, accreditation and revocation decisions are made by the editorial steward against the published criteria. At ratification the authority transfers to the Trust Committee (9 seats), which approves the conformance suite and is the body that admits, suspends, and revokes intermediaries. This is a deliberate governance transfer, not a permanent vendor prerogative: the same reason the Trust List is signed by the AAIF root key under collective control rather than any one company's.

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.

Due process. A suspension or revocation is issued in writing with the violated MUST / MUST-NEVER clause cited. The affected entity has a defined window to remediate or appeal to the Trust Committee before a suspension escalates to terminal revocation; the decision and its basis are recorded in the same signed audit format regulators can replay. Routine sanctions propagate on the normal list cadence, visible to every participant within the cache horizon, no private side channel.

Emergency revocation (out-of-band)

The 24-hour cache window answers "contain a bad key by tomorrow." It does not answer "a key is being actively abused and we need it dead now." For that case the spec defines a signed, out-of-band revocation bulletin: a minimal root-key-signed document, distinct from the full list, that names a DID and one or more kids and marks them revoked effective immediately. Participants subscribe to the bulletin channel (a lightweight signed feed at a well-known path) in addition to the daily list; a compliant verifier checks the bulletin set before accepting an envelope, so a compromised key can be cut off in minutes without forcing a full-list re-fetch and without ever introducing a per-decision call to a central authority. The bulletin is fail-safe: if its channel is unreachable, the daily list's next_update bound still caps exposure at one cache cycle.

Two open questions every regulator asks, answered straight. Cross-border coordination: OCSS is jurisdiction-neutral by construction. A Receipt carries its own statute citations (cite: ["KOSA-§4(b)(2)", "CA-AADC-§22675"]), 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. Endorsement boundaries: where OCSS references ratings systems such as ESRB, PEGI, or MPAA, it maps to those scales as inputs; it does not endorse them or speak for them. Regulators and policy bodies don't accredit; they observe, via a reserved Trust Committee seat with read access to the conformance suite and the signed audit format.

A regulator's real questions are operational, so they are answered operationally.

• Subpoena path. Enforcement evidence is the OCSS Receipt: a signed, replayable record of one enforcement decision (rule ID, age band — never identity, jurisdiction, capability, decision, statute citations, timestamp). A regulator requests Receipts by ID from the surface or intermediary that holds them and recomputes each signature against the signer's published JWKS offline, with no live cooperation from the standards body required, because the evidence verifies itself. The design target is to compress a multi-week document-production cycle into a query that resolves in seconds, since the verifier is a signature check, not a custodial retrieval.
• List goes stale mid-investigation. A stale list does not invalidate prior evidence: a Receipt is verified against the signer's published JWKS and its own embedded list reference, not against the current list. An ICAC investigator replaying last quarter's Receipts is checking signatures, so the list being momentarily stale or an intermediary having since been revoked changes nothing about whether yesterday's decision was validly signed. Going forward, staleness fails safe: a verifier past next_update stops accepting new envelopes rather than trusting an old roster.
• Root key compromise. This is the one event the 24-hour horizon does not contain, so it is governed, not merely hoped against. The AAIF root key is held offline under documented multi-party controls: no single individual can sign with it, key operations are logged, and rotation is itself a published, signed root-key event rather than a silent swap. If the key were compromised, recovery is a signed re-key distributed through the same channel the spec ships in and pinned anew by participants; it is a deliberate, auditable act, because a trust root that could rotate quietly would be a trust root an attacker could rotate quietly.
• Escalation when governance conflicts with statute. The regulator observer seat carries read access and a voice, not a veto, by design, since a standards body cannot bind a sovereign. The escalation path is the reverse: where a Trust Committee decision conflicts with a regulator's law, the regulator enforces its statute against the participant directly, and OCSS's signed audit trail is the evidence that makes that enforcement easier, not a shield against it. A documented decision and its cited clause are recorded in the replayable audit format precisely so a regulator can point enforcement at it. "Build to the spec, not instead of the law" is the operative rule.

Through v1.0 ratification these controls are operated by the editorial steward against published criteria; at ratification the authority (including who may invoke an emergency revocation bulletin and who approves an AAIF root re-key) transfers to the Trust Committee. The transfer is the point: the trust root is meant to outlive any one operator.

DNS resolvers, MDM and device-management providers, router and OS vendors, carriers, and other infrastructure operators interested in the Charter cohort can register interest now to be reviewed when the process opens alongside v1.0 ratification.

Regulators and policy bodies don't accredit as intermediaries; they watch. They may join as Observers to the Trust Committee (9 seats; one seat is reserved for a regulator observer), with read access to the conformance suite, the signed audit trail format, and accreditation decisions. Email [email protected] for the observer pathway.

Building a parental-control product or family-safety app? You're a primary audience here, not an afterthought to the infrastructure operators. Learn how your product can integrate against the Trust List to route consent and enforcement signals to accredited intermediaries.