Phosra Link Branding Requirement

Phosra Link is the parent’s trust anchor the way Plaid Link is the account-linking one. A parent who has connected one platform through Phosra Link should recognize the exact same branded consent on the next platform, in the next app. Consistency is the trust mechanism — so the branding is mandatory and cannot be altered per-app.

​

1. The requirement

Any Phosra Link connect or consent surface — the sheet where a parent reviews what will be applied and grants consent — MUST display the Phosra Link branding:

• The phosra · OCSS lockup — the phosra wordmark (spark integrated as the “o”) next to the OCSS bracket-document mark. Not one or the other; the lockup.
• The trust signals, verbatim:
  • “Accredited on the OCSS Trust List.” — shown up front (the router is accredited).
  • “Verified on the OCSS Trust List.” — the only green, shown on success.
• The “never a fake green” honesty rule — the verified green appears only after the server binds the grant and verifies it to the OCSS root. Never on load, never optimistically, never as decoration.

A PCA MUST use the published kit — it renders all of the above; a PCA does not. A PCA MUST NOT hand-roll the consent screen, wrap the kit in a chrome that hides its marks, override its type/color, or re-implement the ceremony behind its own UI. The branded consent is the kit’s component — a PCA styles what surrounds the sheet, never the sheet.

​

2. Why it is enforced

The parent is trusting Phosra Link — a recognizable, consistent, accredited surface — not each vendor’s bespoke screen. That recognition is only worth anything if it is identical everywhere, exactly as Plaid Link is identical across every bank and app. Restyled or ad-hoc consent breaks the recognition and, with it, the trust. Enforcement is structural: the branded consent (marks, trust signals, the fail-closed green) lives inside the kit component, not in PCA code. A PCA — or a platform — cannot strip it without replacing the kit, and replacing the kit is the non-conformant act the assessor checks for.

​

3. Platform co-branding

The platform’s own OAuth / login leg MUST co-brand:

Phosra Link · <Platform>

Never a bare, unbranded auth form. The parent must see, at the login step, that they are still inside a Phosra Link ceremony connecting this platform — not dropped onto an anonymous page. The kit carries the platform’s verified logo (from its accredited Trust-List entry, via GET /providers/{did}/connect → icon_url), never a logo the app pastes in.

​

4. The “Managed via Phosra” provenance label

Co-branding (§3) covers the moment of connection. Provenance covers everything after: once a child’s account or profile is governed by a Phosra-delivered enforcement profile, the platform MUST surface a persistent, ambient “Managed via Phosra” provenance indicator on that account/profile — so a parent or user can tell, at any time, that the account is externally managed and where the rules come from.

• Where: wherever the platform shows account/profile status (settings header, a managed-account badge, the parental-controls pane). It is persistent, not a one-time toast.
• Wording: “Managed via Phosra” (or “Managed via Phosra Link”). It states provenance — it is not a trust-verified green and MUST NOT borrow the verified-green treatment from §1.
• Honesty: show it only while an active enforcement profile is bound. If the connection is revoked and the profile clears, remove the label — never leave stale provenance.

This is distinct from the connect/consent marks: those prove the ceremony was genuine; the provenance label keeps the ongoing management legible long after the sheet is dismissed.

​

5. Conformance

Shipping an unbranded, ad-hoc, or restyled Phosra Link connect surface — or omitting the “Managed via Phosra” provenance label on a managed account — is NON-CONFORMANT. The branding requirement is assessed — it is part of the OCSS conformance surface, checked at Production Accreditation by the governance-designated verifying-agency (the Touchstone role) alongside the crypto and enclave checks:

• Conformant — the connect/consent surface is rendered by PhosraLinkKit or @phosra/connect at a supported version, with the phosra · OCSS lockup and the Trust-List trust signals intact, the verified green gated on a root-verified grant, and a persistent “Managed via Phosra” provenance label on every managed account/profile.
• Non-conformant — a hand-rolled consent screen; the kit restyled so its marks or trust signals are hidden/altered; a green “verified”/“connected” state shown before the server binds and verifies the grant (a fake green); a bare platform auth form with no Phosra Link · <Platform> co-brand; or a managed account with no “Managed via Phosra” provenance indicator.

A non-conformant branding finding blocks the entry’s promotion off standin to a production-accredited Trust-List entry.

​

The published assets (do not re-create)

These render the required branding. Cite them; do not fork or reimplement them. iOS — PhosraLinkKit

• Sources/PhosraLinkKit/Views/Marks.swift — the real marks as source: PhosraWordmark, OcssMark, Spark, CheckMark (verbatim geometry, tinted by color — no asset bundle).
• Sources/PhosraLinkKit/Views/BrandTokens.swift — the palette. The verified green is BrandTokens.deep (#00794A); it is applied only on the verified state.

Web — @phosra/connect

• src/web/assets.tsx — PhosraWordmark, OcssMark, Spark (inlined SVG, verbatim geometry).
• src/web/connect.css — the branded stylesheet: .phosra-connect__brand, .phosra-connect__wordmark, .phosra-connect__ocss, and the --pc-green600 token. Ship it as-is; do not override its rules.
• src/web/ConnectFlow.tsx — the trust copy lives here: data-phosra-connect="trust" → “Accredited on the OCSS Trust List.”, and data-phosra-connect="verified" → “Verified on the OCSS Trust List.” (the only green).