OCSS Trust Framework

The OCSS Trust Framework is the routing and trust layer of the Open Child Safety Specification. It defines how signals move between parties, who is trusted to move them, and how any verifying party can confirm a receipt without calling back to Phosra. The normative rules are in the OCSS specification at openchildsafety.com; this page describes the mechanism and where Phosra hosts it.

The Trust Framework is part of the OCSS standard — not a Phosra invention. Phosra hosts conforming endpoints. Any other accredited OCSS provider hosts the same endpoints with the same verifiable structure.

The two-layer signed envelope

Every OCSS signal travels inside a two-layer envelope:

Outer layer (transport) — signed by the sending party's registered key (an Ed25519 signing key declared on the Trust List). The outer layer carries the signal type, the sender DID, the recipient hint, and the inner payload as a sealed blob. The router reads only the outer layer headers it needs to move the signal — it never opens the inner payload.

Inner layer (sealed payload) — encrypted to the recipient's declared payload key (an EC P-256 JWK published on the Trust List). Only the designated recipient can open it. The router is structurally blind to the payload content; this is not a policy — it is cryptographic enforcement.

This two-layer structure means:

  • Senders authenticate with a key that any party can look up on the Trust List.
  • Payload contents are sealed end-to-end between sender and recipient.
  • The routing layer cannot inspect, modify, or replay the inner payload.

The Trust List

The Trust List is a signed JSON document that enumerates every accredited party on the network — their DID, declared signing key(s), payload key, and accreditation tier. It is the anchor of the entire verification chain: a receipt is valid only if it was signed by a key that appears on the Trust List.

The Trust List is served at a standard well-known path:

code
GET https://prodapi.phosra.com/.well-known/ocss/trust-list

This endpoint is live today, no authentication required. The response is a signed JSON document. The root signing key (root-prod-2026-06) is published separately; any verifier can fetch the Trust List, check the signature against the published root key, and determine whether a given party is accredited.

The production Trust List is validly signed against root-prod-2026-06. Production accreditation entries are added through OCSS governance — no test or sandbox keys are present in production.

Accreditation tiers

The Trust Framework defines accreditation tiers that govern which parties can write which signal types:

TierDescription
accreditedFull accreditation — can write all signal types permitted by the rule category
provisionalProvisional accreditation — can write a constrained subset pending full review

A party's tier is declared in their Trust List entry. The receiving party checks the tier at decision time — a signal from a provisional sender is handled differently from one with accredited status.

The signed-verb model

Every operation on the OCSS network is a signed verb: a typed action, signed by the acting party's key, carrying a reference to the Trust List entry that authorizes it. Receipts are not add-ons — they are the unit of the protocol. A write that produces no verifiable receipt is not a conformant write.

Signed verbs include:

  • Write receipt — records a rule decision (block / allow / restrict / escalate) for a child policy, signed by the writing party.
  • Enforcement receipt — confirms a decision was applied at an enforcement endpoint (a device, router, or app surface), signed by the enforcing party.
  • Attestation export (§9.4) — a signed CSV of conformance evidence per the §9.4 export spec, suitable for regulatory submission.

All three are verifiable against the Trust List without calling back to Phosra at verification time.

The succession record

Alongside the Trust List, Phosra hosts the OCSS succession record — the machine-checkable form of the steward-of-record designation and the anti-capture covenant:

code
GET https://prodapi.phosra.com/.well-known/ocss-succession

This endpoint is also live today, no authentication required. The record is Ed25519-signed by the steward key. It declares who holds stewardship, the transfer status, and the succession plan in a form any party can fetch and verify independently.

Verification without Phosra

A receipt issued today can be verified against the Trust List tomorrow, by a party that has never contacted Phosra, against a snapshot of the Trust List fetched at any time the receipt was valid. The verification steps are:

  1. Fetch the Trust List from /.well-known/ocss/trust-list.
  2. Verify the Trust List signature against the published root key.
  3. Look up the signing party's key in the Trust List.
  4. Verify the receipt signature against that key.
  5. Confirm the party's tier permits the signal type written.

Steps 1–5 use only the open @openchildsafety/ocss library. No Phosra-specific code or callback is required.

Next