Getting on the Trust List

The OCSS draft defines a Trust List as the signed document that would enumerate parties and their proposed standing on a network. This page explains the draft model and the sandbox evaluation boundary; it does not describe a currently operating production federation.

Honest status — read first. Phosra does not claim a production federation, current accreditation, or independently adopted Trust List entries. Self-service onboarding to a production Trust List is not live — the available flow is a sandbox and preview surface. Teams evaluating a real workflow can email [email protected] with their intended role(s) and public signing key to discuss the design-partner beta.

Accreditation lanes (§5.4)

The OCSS specification defines three accreditation lanes based on the capability band you intend to operate on (§5.4):

Lane	Band	Path
Implementer	Open band	Free, self-serve: signed self-declaration published in the registry. No assessor required. The declaration creates the accountability.
Assessed	Gated band	Self-attestation + a Trust List evidence bundle + randomized, steward-funded spot-verification. An existing SOC 2 Type II or ISO 27001 certificate is accepted as evidence but must not be required (§5.4).
Audited	Restricted band	Independent audit by any assessor meeting published objective criteria — never a steward-appointed list (§5.4).

Tier disambiguation. The draft Trust List schema carries a tier field such as accredited or provisional (§3.6). The three proposed accreditation lanes (§5.4) describe how a future governance process could assign a tier. These fields can appear in sandbox fixtures, but Phosra does not claim a current independent accreditation decision. Tiers are separate from the four capability bands (§3.6).

Per-role onboarding artifact

In the draft model, the main difference between roles at onboarding time is the artifact proposed for a Trust List. The available path today is sandbox evaluation or a design-partner conversation, not production accreditation.

Issuer

Draft-defined onboarding artifact: Ed25519 signing key registered on the OCSS Trust List

Register an Ed25519 signing key under your did:ocss: identifier. Signed rule writes you originate are then verifiable by any party holding the Trust List (§11.9). The write operation is POST /api/v1/policies/{policyID}/rules (§8.3.1).

Current status: Implementation Status separates available evaluation surfaces from design-partner and roadmap capabilities.

Verifier

Draft-defined onboarding artifact: Trust List read access — subscriber record linking family policy to the Verifier's proposed Trust List DID

For sandbox evaluation, use a synthetic DID and subscriber record to exercise the proposed link to a family policy store. CONSUME-side subscription management is GET/PUT /api/v1/alerts/subscriptions (§8.3.3); inbound signal ingest is POST /api/v1/webhooks/inbound/{source} (§8.3.2).

Current status: Implementation Status separates available evaluation surfaces from design-partner and roadmap capabilities.

Gatekeeper

Draft-defined onboarding artifact: enforcement-endpoint URL declared on the draft Trust List record

In a sandbox evaluation, declare an enforcement-endpoint URL on the synthetic Trust List record and inspect the proposed signed enforcement-confirmation flow (§8.3.8). A production receipt rail and independent accreditation pathway remain roadmap.

Current status: Implementation Status separates available evaluation surfaces from design-partner and roadmap capabilities.

Infrastructure Intermediary

Draft-defined onboarding artifact: routing attestation: a proposed Trust List entry as an independently operated router node (§11.9 federation floor)

The proposed production path is to register as an independently operated router node (§11.9 federation floor). A routing attestation — a signed Trust List entry declaring the envelope bands and SLO cells operated — would be the onboarding artifact (§8.3.6, §5.4). The federation floor requires at least three independently accredited routers; Phosra does not claim that a production federation exists today.

Current status: Implementation Status separates available evaluation surfaces from design-partner and roadmap capabilities.

Economics and the covenant

Royalty-free vocabulary. The OCSS rule vocabulary — all rule categories, the verb model, the envelope format — is royalty-free per §5.5. No licensing fee is owed for implementing the specification vocabulary.

The draft discusses possible economics for future accreditation paths at openchildsafety.com (§5.5). Those draft terms do not establish a currently operating certification program.

§12.2 covenant — not yet a signed instrument. Joining as a founding signatory converts to a covenant, not yet a signed legal instrument. The distinction is honest and material: a covenant is a public commitment; it does not create a legal instrument until the governance body designates one (§12.2). OCSS Draft 4 is an independent pre-release draft intended for standards-track submission; it is not ratified and has no official IETF Datatracker record. Conformance evidence is something a regulator can weigh; it is not a compliance determination or a safe harbor (§5.1).

Next steps

To begin the onboarding conversation:

Generate a did:ocss: identifier with an Ed25519 signing key (@openchildsafety/ocss includes key generation utilities).
Identify your role(s) from the four §3.2 roles — you may hold more than one.
Email [email protected] with the workflow you want to evaluate, your intended role(s), and the evidence that would make a bounded design-partner pilot useful.

Sandbox self-registration uses synthetic identities only. The Implementation Status page separates available evaluation surfaces from roadmap capabilities.

OCSS Roles — the four §3.2 roles in detail.
Trust Framework — the two-layer signed envelope, Trust List, and accreditation tiers.
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.