Snapshot from OCSS
spec_version=ocss-v4-draft-4. Authoritative role definitions and specification text live at openchildsafety.com.Roles and verbs — two independent axes
OCSS assigns every participant two independent labels: a role (the kind of party you are on the network) and one or more lane verbs (the operations you perform). They are not the same, and knowing the difference prevents a common misread.The four roles (§3.2)
The lane verbs (§4.3)
The four roles in detail
Issuer
You are reading this if you originate child-safety attributes — an OS-level age signal, an app-store age attestation, or a parent’s verifiable consent assertion. You sign and broadcast that attribute to other parties on the network.OCSS §3.2 definition (verbatim): “Originates an attribute: an OS vendor’s declared age range, a mobile driver’s licence, a parent’s verifiable consent assertion.”
What you implement
POST /api/v1/policies//rules — signed write receipt; both BROADCAST (one attestation → N consumers) and DIRECTIVE (one control → N enforcement points) are realized on this rule-plane (§8.3.1, §4.3 DIRECTIVE note) Representative rule categories:app_store_age_attestation, os_age_signal_ingest
Platforms expose, they do not call. For OS vendors, app stores, and major platform operators, the expected posture is the Issuer-adapter pattern: an accredited adapter originates signed envelopes from your native signals rather than your platform calling OCSS endpoints directly. This caller-inversion makes the lane claimable by parties already at the table without requiring platform roadmap commitments before a running reference harness, published economics, and a literal governance seat exist (§5.2.6, §1.6).
Verifier
You are reading this if you consume child-safety signals and act on them — a parental-controls app, a monitoring service, or any system that validates an age band or consent assertion before making a decision.OCSS §3.2 definition (verbatim): “Validates a presented attribute against an assurance level — typically a parental-controls provider confirming consent before acting on a signal.”
What you implement
GET/PUT /api/v1/alerts/subscriptions — CONSUME-side subscription management for receiving signed signals from accredited Gatekeepers; POST /api/v1/webhooks/inbound/ — inbound age-band / consent signal ingest (§8.3.2, §8.3.3 CONSUME lane) Representative rule categories:parental_consent_gate, parental_event_notification
Issuer + Verifier is the common posture for parental-controls vendors. OCSS assigns first-class peer standing in both roles simultaneously — you issue consent assertions and verify signals from any accredited Gatekeeper (§3.2). The receiver-profile duties (verify, decide, discard) are defined at §5.2.4.
Gatekeeper
You are reading this if you operate a regulated platform where a child’s experience is rendered or gated — a game, a streaming service, a social platform, a browser, or a DNS resolver.OCSS §3.2 definition (verbatim): “Enforces the access decision: the regulated platform deciding whether to gate a feature or transmit a signal.”
What you implement
POST /api/v1/policies//confirm — enforcement confirmation posted to the Gatekeeper’s declared endpoint URL (§8.3.8) Representative rule categories:web_filter_level, content_block_title
EMIT qualifier — not every Gatekeeper holds it. EMIT is a gated qualifier per §4.3 and §10.6 — the lane is open only when the vocabulary it must speak is fully defined; not every Gatekeeper holds this qualifier See §4.3 and §10.6 for the conditions under which EMIT is open.
§1.6 — The open seat. The major platforms (OS vendors, app stores, social platforms, streaming services) carry the heaviest Gatekeeper build obligations in the OCSS specification and did not hold a seat in the drafting rounds. The seat is open (§1.6). The Implementer accreditation lane (§5.4, open band) needs no assessor — a signed self-declaration published in the registry is enough; no commitments are asked before a running reference harness, published cost schedule, and a literal governance seat exist. That is a statement about the lane, not about Trust-List admission in general — see below for what actually getting onto the Trust List involves today.
Infrastructure Intermediary
You are reading this if you route signed envelopes between Gatekeepers and Verifiers — a DNS-layer resolver, a carrier network, an MSP, or a federation node.OCSS §3.2 definition (verbatim): “Routes signed envelopes between Gatekeeper and Verifier. The Trust Framework’s structural contribution is support for multiple accredited intermediaries simultaneously.”
What you implement
signed routing attestation + §8.3.6 profile-compilation pass for enrolled enforcement points Representative rule categories:school_alert_routing, monitoring_alerts
Routing is not ownership. Operating a policy store or routing envelopes confers no standing to originate obligations in it. The Infrastructure Intermediary routes sealed envelopes and compiles enforcement profiles (§8.3.6) — it never opens payloads. Blindness is cryptographic, not a policy option (§3.3).
Management API vs. OCSS protocol layer
Two surfaces, one integration. The Phosra developer API has two distinct layers:- Management API (Phosra control plane): developer organizations, API keys, policy stores, usage rollups — the
/api/v1/developers/*surface. This is Phosra-specific; other OCSS providers have their own control planes. - OCSS protocol layer: signed rule writes, enforcement confirmations, routing attestations — the operations defined in §8.3.1 through §8.3.8 of the specification. Any conformant OCSS provider exposes these with the same signed shape.
POST /api/v1/policies/{policyID}/rules, you are performing an OCSS protocol operation. The signed receipt it returns is verifiable against the Trust List without calling back to Phosra.
Governance roles — kept separate
The specification distinguishes network roles (what a party does on the protocol — the four above, §3.2) from governance roles (who sits on the Trust Committee, who qualifies as an assessor, who is a founding signatory). The source for this separation is §11.8 “Roles, not names” (GOV-RN-01): normative text names roles, never legal entities — a role binding changes by succession record, not by amendment. These use overlapping vocabulary but are independent axes.- A founding signatory holds a covenant commitment to the specification — not a protocol role or a Trust Committee seat.
- A Trust Committee seat is a governance position (§12.2 and cited clauses) — it does not map to any of the four network roles.
- An assessor is eligible under the objective criteria of §5.4, regardless of which network roles they hold.
Advisor — not a §3.2 role
“Advisor” is a §8.4 product surface — informative reference-implementation operations — not one of the four §3.2 protocol roles. When you encounter “advisor” in the Phosra API or documentation, it refers to that surface, not to a fifth network role alongside Issuer, Verifier, Gatekeeper, and Infrastructure Intermediary.Next
- Getting on the Trust List — the sandbox self-serve path and the production accreditation application, per role.
- Conformance Status — live vs. preview surface-by-surface.
If the standard and this mirror ever conflict, the standard (at openchildsafety.com) wins. Authoritative text at openchildsafety.com.