OCSS Roles
The four roles on this page are defined by the Open Child Safety Specification (§3.2) at openchildsafety.com. Phosra implements them; it does not define or own them. The canonical text — role definitions, verb model, and conformance requirements — lives at openchildsafety.com.
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)
| Role | What it does |
|---|---|
| Issuer | Originates an attribute: an OS vendor's declared age range, a mobile driver's licence, a parent's verifiable consent assertion. |
| Verifier | Validates a presented attribute against an assurance level — typically a parental-controls provider confirming consent before acting on a signal. |
| Gatekeeper | Enforces the access decision: the regulated platform deciding whether to gate a feature or transmit a signal. |
| Infrastructure Intermediary | Routes signed envelopes between Gatekeeper and Verifier. The Trust Framework's structural contribution is support for multiple accredited intermediaries simultaneously. |
The lane verbs (§4.3)
| Verb | Meaning | Who uses it |
|---|---|---|
| BROADCAST | One attestation fans out to many consumers (an age band, verified once) | Issuer |
| DIRECTIVE | One signed control fans out to every enforcement point that can honor it | Issuer |
| CONSUME | Ingests a signal and acts on it | Verifier |
| ATTEST | Writes the signed, recomputable record that proves an action happened as logged | Gatekeeper, Infrastructure Intermediary |
| EMIT (gated qualifier) | Originates an abuse signal on the alert lane — open only when the vocabulary gating it is fully defined (§4.3, §10.6) | Gatekeeper (not all) |
A verb is not a sender role — roles touch multiple verbs. In the OCSS draft model, a parental-controls vendor can participate as both Issuer and Verifier: it originates consent assertions (Issuer, BROADCAST / DIRECTIVE lane) and validates signals from Gatekeepers (Verifier, CONSUME lane). Holding multiple draft roles does not imply that a production network or accreditation decision exists (§3.2).
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
Proposed adapter pattern. The OCSS draft describes an Issuer-adapter pattern in which an adapter could originate signed envelopes from native platform signals instead of requiring a platform to call OCSS endpoints directly. This is a design pattern, not a claim that any OS vendor, app store, or major platform has adopted OCSS (§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 a draft posture for parental-controls vendors. A design can issue consent assertions and verify Gatekeeper signals while holding both roles (§3.2). The receiver-profile duties (verify, decide, discard) are defined at §5.2.4; no current production peer standing is implied.
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
Receipt-MUST on the Restricted band. Every enforcement decision on the Restricted band MUST produce a signed enforcement confirmation receipt posted to your declared endpoint URL (§8.3.8). The enforcer floor at §4.6 is normative — this is not optional.
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 — Platform participation is not implied. The OCSS draft assigns substantial Gatekeeper obligations to OS vendors, app stores, social platforms, and streaming services. Phosra does not claim those platforms participated in drafting or adopted the draft. Teams can inspect the reference harness and bring a real workflow to the design-partner beta before discussing any broader governance role.
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
Federation floor — roadmap acceptance criterion. The OCSS federation floor requires at least three independently accredited router nodes (§11.9). Phosra does not claim a production federation or current router accreditation; hosted routing and broader accreditation pathways remain roadmap. See Conformance Status for the current evidence boundary.
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.
When you call 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.
When you encounter “Issuer” or “Verifier” in a governance or legal context, verify which axis is being invoked. This page covers §3.2 network roles only.
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.
If the standard and this mirror ever conflict, the standard (at openchildsafety.com) wins. Authoritative text at openchildsafety.com.