Verify. Don't trust us.
This is the highest-stakes claim a child-safety vendor can make, so we built it to be checked rather than believed. The succession record is signed. The federation rates a Phosra-only world RED. The envelope is sealed so the router can't read it. And conformance is evidence a regulator weighs — never an approval we issue.
We implement OCSS. We don't own it.
OCSS — the Open Child Safety Specification — is an open standard, currently an individual IETF Internet-Draft (Draft 4, pre-release). Phosra is its reference implementer and one accredited network running on it. Like Yubico for FIDO2: we build the thing, we don't control the standard. The canonical spec, the rule registry, and the conformance suite live at openchildsafety.com — not here — so the standard can outlive any single vendor, including this one.
That separation is the asset. A standard you can't capture is a standard you can trust — which is why everything below is structured so you can confirm it independently, against signed records and open conformance tests, rather than against our word.
Trust, reduced to four verifiable claims.
Each of these is a property you can confirm from the outside — a signature you can validate, a conformance result you can re-run, an encryption boundary you can read in the protocol. None of them asks you to take our posture on faith.
A succession you can verify
OCSS is governed toward an independent foundation. The steward of record, transfer status, and succession plan publish as an Ed25519-signed record you check against the steward key — not a press release you take on faith.
Even we rate RED alone
A federation with only Phosra in it is a single point of capture, and the conformance suite is designed to flag exactly that. The standard is healthy only when several accredited networks cross-check one another.
The intermediary cannot decrypt
The OCSS envelope is sealed end-to-end. The routing layer reads only the headers it needs to move a signal; the payload is encrypted to the recipient. Phosra-the-router structurally cannot read what it carries.
Reading content is a separate layer
Content is inspected where it originates — at the classifier a platform runs, which is the competitive surface Phosra sells — never at the blind router that moves the signal. A sealed envelope proves the router didn't read your data; on its own it does not prove anyone caught what they were responsible for catching.
Evidence, never approval
Conformance is evidence a regulator can weigh — not a regulatory determination, not a safe harbor, not a stamp we issue. The boundary is written into the spec, and we quote it verbatim below.
The governance says so out loud — and signs it.
Phosra runs one accredited network of the several a real federation requires. The accreditation regime is still forming, and there are 0 independent intermediaries today, by design. Rather than ask you to trust that we'll cede control, the system is built to prove it.
A signed succession record
The steward of record, the transfer status, and the succession plan publish as an Ed25519-signed record — not a press release — so you can verify the chain of custody rather than take our word for it.
The record publishes when the interim steward is designated (governance designation, due 2026-07-09). Until then this is an illustrative shape, not a live endpoint. It will be served at openchildsafety.com/.well-known/ocss-succession.
Even we rate RED alone
A federation with only Phosra in it is a single point of capture — and the conformance suite is designed to flag exactly that. The standard is healthy when several accredited networks (a target of ≥3 routers) run it, cross-checking one another.
This isn't marketing restraint — it's a rule in the conformance suite. The code rates a Phosra-only world RED. Roles and status dated as of 2026-06.
Conformance is evidence, not approval.
This is the single line procurement and regulators care about most, so we state it exactly as the spec does — no softening, no implied stamp. OCSS conformance does not confer regulatory approval and is not a COPPA safe harbor. It is something a regulator can weigh, alongside everything else, when they evaluate you.
We are building toward OCSS Certified— a status earned from the standard and its conformance suite, never issued by Phosra. We don't self-certify, and we don't ship a “Phosra Certified” badge.
“A conformance result is evidence that an implementation satisfies the tested requirements at the time of testing. It is not an approval, a certification by the steward, or a determination of legal compliance, and it confers no safe harbor under any statute.”
Read the full §5.1 at openchildsafety.com
The controls behind every policy decision.
SOC 2 Type II is in progress, with an expected audit window of 2026 Q3 — stated as a status, not a claim. Here is the posture you can review today.
Short-lived JWTs
Production auth runs on WorkOS with short-lived JWTs and a separate sandbox tenant for development. Admin actions are gated behind explicit role checks on every request.
TLS 1.3 + HSTS
HTTPS enforced end-to-end with TLS 1.3; HSTS at the edge. A conservative Content-Security-Policy restricts script, frame, form, base, object, and worker sources.
AES-256-GCM
Postgres with tenant scoping enforced at the application layer on every query. AES-256-GCM applied to sensitive fields (OAuth tokens, provider credentials) on top of standard at-rest disk encryption.
Every decision logged
Every enforcement decision is written to a durable event stream with the rule, input, output, and statute citation. A regulator-ready export is a query, not a project.
Architected around the statutes that govern minor data.
Phosra is built around these frameworks as enforceable policies, not documentation wishes. Each links to its full mapping in the compliance hub.
COPPA / COPPA 2.0
Verifiable parental consent, minimum-necessary collection, and parent-initiated deletion are built into the enforcement engine.
Read the full mapping Statute mappingKOSA
Duty-of-care surfaces mapped across the OCSS rule categories: content filtering, design-feature limits, and parental tooling out of the box.
Read the full mapping Statute mappingEU DSA
Article 28 minor-protection obligations and risk reporting supported via queryable audit trails and transparency-report-ready exports.
Read the full mapping Statute mappingUK AADC
Age-Appropriate Design Code defaults (high-privacy, no profiling, no nudges) are enforceable policies in the registry, not documentation wishes.
Read the full mappingMinimum necessary. Parent-controlled. Never sold.
- Parent account identifiers (email, hashed)
- Child profile metadata (first name, age band, device binding)
- Policy state + enforcement events
- Audit logs for compliance reporting
- Sell, rent, or broker minor data — ever
- Use child data for advertising or ad targeting
- Share data with third-party ad networks or data brokers
- Train external ML models on child data
Conservative by default
Retention windows are parent-configurable. Defaults follow the most conservative applicable statute (COPPA / UK AADC), and audit logs are retained only as long as required for regulatory defensibility.
One click, fully erased
Parent-initiated deletion removes the child profile, enforcement state, and derived telemetry. Portability exports are available on request in machine-readable JSON.
The vendors in our data path.
US-primary data residency across all subprocessors. We update this list when the path changes.
Documented playbook. Honest timelines.
We use Sentry for application error tracking and infrastructure telemetry. When an incident is confirmed, we follow a documented playbook: contain, assess impact, notify, remediate. Breach notification within 72 hours of confirmation, consistent with GDPR Article 33 and CCPA. Affected parents are contacted directly via the email of record.
We welcome responsible disclosure. Please don't access data that isn't your own, test against production parent or child accounts, or run scanners that degrade service. Good-faith research is welcome — we credit researchers in our disclosure log with your permission.
Report an incident
If you believe you've identified a security issue or are affected by an incident, email us directly. We triage within one business day and keep you updated through remediation.
Don't take our word. Take the evidence.
Request the current SOC 2 status letter, the subprocessor DPA, or the architecture diagram — and verify the OCSS conformance results and succession record at the source. We respond within one business day.
Verify the standard itself at openchildsafety.com — spec, rule registry, and conformance suite.