Governed by the entities that implement it. Owned by none of them.

• No member owns the standard.OCSS is published under an open, royalty-free license. No participant (including its founder) holds proprietary control over the specification, the rule taxonomy, or the conformance mark.
• Phosra is one participant of many.Phosra founded OCSS and holds editorial stewardship of v1.0 through ratification: the role of an editor preparing a draft for a standards body, not an owner. Phosra's commercial product lives elsewhere; this standard does not sell it.
• Founder ≠ owner.Founding a standard earns no permanent authority over it. The stewardship role is bounded in time and scope: it ends at ratification.
• Phosra stewards v1; the Trust Committee steers v2.At v1.0 ratification, governance authority transfers to the multi-stakeholder Trust Committee, which ratifies every subsequent major version and approves the conformance suite. From v2 forward, the standard is steered by its implementers.
• Parental-controls vendors implement OCSS without product capture.A competing parental-controls vendor can adopt the Rules taxonomy and Trust Framework, earn the certification mark, and ship a conformant product without depending on Phosra's product, infrastructure, or goodwill. The standard routes through multiple accredited intermediaries by design (no single steward sits in the path), so adopting OCSS never hands a competitor a chokepoint over your customers' traffic.

What an adopter actually gets

The neutrality story is the reason this is safe to adopt; the ROI is the reason to bother. If you build parental controls, your roadmap today is a queue of bilateral integrations: one per OS age signal, one per content rating source, one per platform that exposes a safety hook. That is the N×M problem: every new partner multiplies against every other. OCSS turns it into N+M. You implement the spec once and read one typed signal, and every party that also speaks OCSS is reachable through the shared Trust List instead of a new contract and a new schema. The integration you don't build is the cost saved.

Conformance comes in two tiers, and the cost-benefit is deliberately legible:

• Tier 0: Implementer (free, self-attested).You pass the conformance suite yourself and land in a public registry at no cost. Use it to ship fast and signal direction. You may say "OCSS-compatible," not "Certified."
• Tier 1: Certified ($2.5–5k/yr, independently audited).An approved third-party assessor verifies your conformance and you earn the Certified mark in a verified registry. That mark is the asset: when a school district, a regulator, or a parent asks "how do I know this works," a Certified entry is an answer they can check rather than trust. It is a procurement and trust differentiator a competitor without it cannot claim.

Working-group participation (Tier 2, $15–25k/yr) buys a seat and RFC sponsorship. It is for vendors who want to shape the rules, and it is explicitly not required to implement, certify, or ship. Conformance and influence are separate ladders; the price tag attaches only to the second. Full tiers, mark-usage terms, and the audit path are on Get Involved and Conformance.

Put the two numbers next to each other and the case writes itself. A parental-controls vendor integrating bilaterally today carries the build-and-maintain cost of one connector per OS age signal, per content-rating source, per platform safety hook. Call it a dozen partners, each a contract, a schema, and an on-call surface that drifts every time a partner ships. Tier 1 certification is $2.5–5k/yr against a single typed signal that every other OCSS speaker already emits. The standard does not promise the connectors are free to write; it promises you write the integration once (the M of N+M) instead of once per partner (the N×M), and then reach the rest of the federation through the shared Trust List rather than a new bilateral deal each time. That is the comparison to run, and it only closes once the Trust List actually holds ≥3 accredited intermediaries (see the readiness note below).

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.

On the regulator seat, and why it is an observer. The regulator seat is non-voting on purpose: a standard that a supervisory authority both writes and votes on stops being a neutral artifact the authority can independently inspect. The observer sees every proposal, every RFC, and every ratification rationale before it lands, and files comments through the same public process as anyone else: influence by transparency, not by ballot. Where a regulator's real power lives in enforcement, and that is outside the Trust Committee entirely: a statute is enforced by the agency that owns it, and OCSS Receipts are the evidence (see §1). An intermediary that violates a conformance MUST is not "voted off." Its Trust-List status is pulled the day the violation is found (see §6), and a SOC 2 Type II audit at least annually is a standing condition of Accredited placement, not a Committee favor. The Trust Committee governs the spec; the Trust List and the regulators govern conduct.

• Royalty-free.Implementing OCSS (the Rules taxonomy, the Trust Framework, the conformance suite) carries no license fee or per-use royalty.
• Open license.The specification is published under an open license. Implementers may build conformant products commercially without seeking permission.
• Patent posture.The IPR policy follows the royalty-free, open-participation model common to IETF and W3C-style bodies: contributions are made on terms that let every implementer ship. The full IPR and patent policy is published with the charter.

The trust model, in primitives

The IPR posture only matters if the thing being licensed is technically sound, so here is the trust model in concrete terms. Beyond deciding who is trusted, governance pins the cryptography that makes "trusted" mean something. The OCSS Trust Framework (Draft v0.1) is the routing layer, and these are its load-bearing MUSTs:

• Two-layer signed envelope.Every signal is an outer object (routing metadata plus an Ed25519 sender signature, visible to the intermediary) wrapping an inner payload that is JWE-sealed to the receiver's public key and opaque to the intermediary. The intermediary routes; it cannot read. Signatures follow RFC 9421 (HTTP Message Signatures); audience scoping follows RFC 8707 (resource indicators).
• eIDAS-style Trust List.Accredited intermediaries are listed in a machine-readable, cryptographically signed registry modeled on the EU Trusted List (EUTL, in production since 2014). Verifiers fetch and cache it on a ≤24-hour TTL, so a revocation propagates within a day without any out-of-band coordination.
• 180-day key rotation, MUST.Every Trust-Listed intermediary MUST rotate signing keys at least every 180 days, publish a per-party JWKS, and emit one immutable audit row per envelope. It MUST NEVER decrypt payloads, retain contents past delivery, or correlate routing metadata across families without consent. A family_hash is domain-separated by the receiving party so the same household cannot be correlated across two intermediaries.
• Append-only, hash-chained audit trail.The "one audit row per envelope" is tamper-evident, not just logged: each row records {ts, iss, aud, kid, nonce, family_hash, decision_class, prev_hash, row_hash} where row_hash = SHA-256(prev_hash ‖ canonical(row)), chaining every row to its predecessor. Rows carry routing metadata only: never decrypted payload, never PII. Minimum retention is 13 months (one full audit cycle plus margin), and the chain head is attested at least annually under an independent SOC 2 Type II engagement scoped to security and availability of the routing service. A silent deletion or back-dated edit breaks the hash chain, so a missing row is detectable rather than invisible.

The envelope, field by field

Prose is not a spec, so the encoder/decoder contract is pinned to named fields, types, and algorithm identifiers. The wire format is JSON; the canonical form for signing is the RFC 9421 signature base over the listed covered components (not a re-serialization of the JSON), which keeps the signature stable across whitespace and key-order differences. Unknown fields MUST be preserved and ignored, so a v1.0 verifier survives a v1.1 sender.

The JWE suite is bound, not negotiated: A256GCM for the content and ECDH-ES+A256KW for key agreement, with compression (zip) disallowed to sidestep compression-oracle leakage on small payloads. The Trust List signing scheme is the same Ed25519 primitive as the envelope, applied to the EUTL-style register; this is the one concrete choice behind the "eIDAS-style" framing: eIDAS is the structural model, Ed25519 is the actual signature.

Per-party JWKS discovery

Each Trust-Listed party publishes its public keys at a fixed, well-known location derived from its Trust-List identity: https://<party-host>/.well-known/ocss-jwks.json, served over TLS, no authentication (the keys are public by definition). Discovery is not bootstrapped from that endpoint's TLS certificate; that would be circular. The binding of identity → key set lives in the signed Trust List: a verifier resolves iss against the Trust List entry (itself Ed25519-signed by the registry), reads the JWKS URL and the expected key fingerprints from that signed entry, then fetches the JWKS and accepts only keys whose fingerprints the Trust List already vouches for. The HTTPS fetch is a transport convenience; trust is anchored in the registry signature, so a compromised host cert cannot inject a key the Trust List did not list. Rotation publishes the new kid in both the JWKS and the next signed Trust List snapshot, and verifiers cache on the ≤24h TTL.

Verify, then enforce: the integration sequence

An engineer integrating OCSS reads one typed Rule payload and runs a fixed sequence before acting on it. There is no "trust the sender and check later" mode:

1. Resolve the envelope's iss against the cached signed Trust List; reject if the party is absent, expired, or revoked.
2. Fetch (or read cached) JWKS, select the key by kid, and confirm its fingerprint matches the one the Trust List vouches for.
3. Verify the Ed25519 signature over the RFC 9421 signature base; check aud matches you, exp is in the future, and nonce is unseen.
4. Decrypt the inner JWE with your private key to read the typed Rule, e.g. {"rule":"ai_chatbot_tier_gate","age":"13–17","decision":"warn"}.
5. Only now enforce, on whatever surface you own (DNS resolver, MDM profile, router/CPE rule, OS-level age signal, or an in-app gate), and emit your own signed Receipt for the decision.

The same verified Rule drives every surface, which is the point: a parental-controls vendor enforcing at DNS and an OS maker enforcing at the platform layer act on the identical signal, so a parent's one policy lands the same way in both. Conformance is checked by the conformance suite against the rule list of each capability you claim, and passing it earns the Implementer (self-attested) or Certified (audited) mark. The suite is in active drafting; published test counts and the downloadable runner are marked for Q3 2026, and we will not quote a count we cannot yet stand behind.