News & changelog

• Outer envelope (routing layer, visible to the intermediary): signed with Ed25519 under RFC 9421 HTTP Message Signatures, with RFC 8707 resource indicators binding each signature to its intended receiver. Carries only routing metadata and a receiver-domain-separated family_hash, never identity.
• Inner payload (record layer, opaque to the intermediary): a JWE sealed to the receiver's public key. The draft specifies the cipher suite rather than deferring it: content encryption is A256GCM (AES-256-GCM) with key agreement via ECDH-ES+A256KW over X25519. zip compression is disallowed to close the JWE compression-oracle class of attack. ChaCha20-Poly1305 is reserved as an alternative content-encryption registration for the v1.1 cipher-agility track.
• Trust List: an eIDAS-style, Ed25519-signed machine-readable registry of accredited intermediaries, modeled on the EU Trusted List (EUTL, in operation since 2014). Fetched and cached for ≤24h; a revoked intermediary drops out of every verifier's view within that window. Status is Yellow below three accredited intermediaries, Red below two. "Federation-grade" requires at least three, so no single operator is load-bearing.
• Verifiable-credential pathway (SHOULD): for age and consent signals carried as verifiable credentials, intermediaries SHOULD support the W3C Digital Credentials API and OpenID4VP as the presentation transport, giving platforms a standards-track alternative to bespoke attestation. Zero-knowledge issuance (Longfellow-ZK) and TEE attestation are roadmap (MAY / v1.1), not v1.0 requirements.

Threat model (stated, not implied). The design assumes a passive-honest-but-curious intermediary and is built to stay sound under collusion of up to N−1 of N accredited intermediaries: because the inner record is JWE-sealed to the receiver, no quorum of intermediaries can read a payload. Replay is bounded by the RFC 9421 created/nonce components plus an audit row per envelope, so a re-sent envelope is detectable and idempotent. Cross-intermediary correlation is blocked by the receiver-domain-separated family_hash: the same family resolves to different opaque identifiers at different receivers, so no two intermediaries can join their logs to re-identify a minor. Key compromise is contained by mandatory rotation at ≤180 days and Trust-List revocation that propagates within the ≤24h cache TTL. The one explicitly out-of-scope threat is a stricter-rule downgrade (an intermediary silently relaxing a Block to a Warn), which the protocol cannot prevent cryptographically; it is instead caught by the immutable signed Receipt at the enforcement point (see §10 Receipt), since the receiver's audit trail will not match the sender's signed intent. We state that mitigation honestly: it is a detective control with an audit-trail adversarial bound, not a preventive cryptographic one. Open for comment ahead of the next revision.

On post-quantum: a stated decision, not an omission. v1.0 is classically secure and has no PQC path. Key agreement is X25519 (ECDH-ES+A256KW), which is not post-quantum-secure, and the Ed25519 signatures over the outer envelope and the Receipt are likewise classical. That is deliberate: X25519 and Ed25519 are the interoperable, broadly-implemented primitives a 2026 standard can demand of every adopter today, and the threat that matters for a child-safety signal is a live intermediary reading or correlating a payload now. The "harvest-now, decrypt-later" attacker is not the concern here, since a sealed routing envelope carries no long-lived secret worth banking against a future quantum machine. The cipher-agility track is real and reserved, not hand-waved: ChaCha20-Poly1305 is already registered as an alternative content-encryption suite for v1.1, the JWE alg/enc headers make the suite negotiable on the wire, and a PQC or hybrid key-agreement profile is the explicit candidate for that same v1.1 cipher-agility work. We are not claiming v1.0 is quantum-resistant; we are documenting why it is not and where the upgrade lands.

What an implementer actually builds against: each rule is typed JSON (a category ID, the capability it belongs to, and its parameters), and the integration is a verify-before-enforce sequence. Validate the outer Ed25519 signature → confirm the sender is on the Trust List → resolve the age band → evaluate the matching rule to Allow / Warn / Block → emit a signed Receipt. That same evaluated decision then drives whatever enforcement surface you own: DNS resolvers, MDM profiles, home-router firmware, OS-level controls, or in-app gates. One typed signal, the same verdict, regardless of where the block lands.

Here's the typed shape an implementer evaluates against: a Tier rule, an Age rule, and a Block rule, illustrative but to the same schema as the conformance draft. Every rule carries a category id, the capability it belongs to, the typed params for that capability, and the cite array that lands in the Receipt. The architecture decision you can make now: your engine is a switch on capability with a handler per area, and you only build handlers for the capabilities you claim.

// OCSS rule categories — illustrative typed shapes (one per capability)
[
  {
    "id":         "ai_chatbot_tier_gate",
    "capability": "Tier",
    "params": {
      "scale":    "civil-society-4tier",  // e.g. a 4-tier AI risk scale
      "min_band": "13-17",                // band that may pass
      "on_fail":  "Block"                  // Allow | Warn | Block
    },
    "cite": ["NY-S9051-§2"]
  },
  {
    "id":         "os_age_signal_ingest",
    "capability": "Age",
    "params": {
      "sources":  ["os", "app", "household"],
      "returns":  "band",                  // derived range, never DOB
      "bands":    ["0-12", "13-17", "18+"]
    },
    "cite": ["CA-AB1043-§1798.99.30"]
  },
  {
    "id":         "nfk_hard_block",
    "capability": "Block",
    "params": {
      "match":    "not-for-kids",          // hard, non-overridable
      "surfaces": ["dns", "mdm", "router", "os", "app"]
    },
    "cite": ["KOSA-§3(a)"]
  }
]

Who can issue a Receipt, and how a regulator audits one. A Receipt is signed at the enforcement point by any conformant implementer. There is no gatekeeper tier required to issue one, because the value is in the signature, not in who holds it: a self-attested Implementer's Receipt verifies the same way a Certified intermediary's does. What differs is the assurance behind the key. The audit workflow has no privileged step: the regulator asks the platform (or any party in the path) for the receipt by ID, fetches the signer's public key from the published Trust List / per-party JWKS, checks the Ed25519 signature and the version domain-separator, and reads the rule ID, age band, jurisdiction, decision, and statute citations off the verified payload. No subpoena, no trust in the platform's word, no access to the minor's identity: the band is derived, never the DOB.

Chain of custody for the trust roots. Today, while OCSS is Draft for Review, the founding steward (Phosra) signs the Trust List against the Linux Foundation AAIF root key: single-keyholder, stated plainly, because there is no Trust Committee yet to share it. That is a transitional arrangement, not the governance model. At v1.0 ratification, custody of the AAIF root key transfers to the nine-seat Trust Committee: the root key and Trust List become committee-administered, no single member (including the steward) can re-issue them unilaterally, and the Trust Committee holds a reserved regulator-observer seat. So a regulator auditing conformance can name the keyholder at every stage (Phosra through ratification, the Trust Committee after) rather than auditing an anonymous root.

// OCSS Receipt — illustrative shape (typed, signed, no PII)
{
  "id":         "rcpt_01HZ…",
  "rule":       "ai_chatbot_tier_gate",
  "capability": "Tier",
  "age":        "13-17",          // derived band, not DOB
  "jurisdiction":"US-NY",
  "audit":      "Block",
  "cite":       ["NY-S9051-§2", "KOSA-§4(b)(2)"],
  "issued_at":  "2026-03-11T18:04:22Z",
  "spec":       "OCSS-v1.0",
  "sig":        "ed25519:…"
}