Phosra Link branding and evidence language

Phosra Link should be recognizable across every parent application. The hosted qualification fleet renders the SDK-owned PhosraLink component from @phosra/link/react rather than rebuilding the ceremony behind a custom modal.

This page describes the published Golden @phosra/link surface. Public npm currently serves 0.6.1. Production discovery is live, while environment-bound credentials are issued through the approved operator workflow.

import { PhosraLink } from "@phosra/link/react"

<PhosraLink
  createSession={createAuthenticatedSession}
  onEvent={recordLinkEvent}
  onExit={closeLink}
/>

The component owns its Phosra Link wordmark, OCSS provenance line, review copy, platform handoff, status language, recovery, retry, and error states. The host application may style the page around the component; it must not replace the component’s evidence language with a more optimistic result.

Compatibility

PhosraLink is the required React export in the private 0.7.10 candidate.
PhosraLinkDialog is the same component under its longer compatibility name.
Older @phosra/connect examples and hand-wired grant_id success screens are compatibility material, not the Golden integration for new applications.
Native kits may have their own supported package and version. Do not claim a web package automatically enforces branding inside a separate native client.

This is the honest boundary: the current web SDK structurally owns the surface it renders. It cannot prevent an application from deleting the component and writing an unrelated screen, so conformance review still checks the integrated product.

Never show a fake green

Connection, delivery, and enforcement are different facts:

Verified state	Safe language
Ceremony created or authorized	“Continue secure sign-in” / “Authorization received”
Durable binding recorded	“Connected—checking platform confirmation”
Controls recorded	“Controls recorded; application not yet confirmed”
Complete signed platform report	“Platform reported all requested controls active”
`applied` with `E4` evidence	“Enforcement confirmed”
`degraded`, `refused`, or `stale`	Show the limitation; do not use success green.
Revoked, release pending	“Disconnected—removal confirmation pending”
Signed release complete	“Disconnected”

An HTTP 2xx, OAuth callback, durable delivery acknowledgement, or successful command return is not proof that controls are active. The SDK advances the UI only from its server-authoritative snapshot and signed platform evidence.

Platform co-branding

During the platform authorization leg, parents should remain oriented: identify the platform and clearly state that the request is part of Phosra Link. Avoid a bare login page that looks unrelated to the flow. The platform must not claim that controls are verified merely because the parent authenticated. The Golden Gatekeeper catch-all supplies the protocol authorization route. Keep your surrounding sign-in and profile-selection pages consistent with your platform while preserving the Phosra Link context and validated return path.

Shared-profile confirmation

The SDK-owned authorize surface recommends a separate platform profile, then offers the fixed action order Choose another profile, Confirm sharing, and Cancel and return. It must disclose that the strictest protections required by any linked child apply to the shared profile and that viewing history, recommendations, and screen time cannot be reliably attributed to one child. Before token exchange, the profile label comes from the authenticated platform catalog recovered from its server-side sealed catalog. The signed selected-profile presentation follows during token exchange. The initial release shows the verified same-family member count, not existing member names or numeric ages. Those labels require a future provider-signed display resolver. Hosts must not insert names, ages, raw IDs, policy values, or a custom confirmation screen from browser state.

Ongoing provenance

After a profile is actively managed, show an ambient label such as “Managed via Phosra” in the platform’s parental-controls or profile settings. This label states provenance; it is not an enforcement-confirmed badge. For a shared profile, keep the label while at least one authorized child member remains. A partial member removal must not clear it. Remove it only after the final signed release has been observed and native settings have been restored.

Review checklist

The app renders the supported SDK component for the parent ceremony.
The component’s wordmark, OCSS provenance, statuses, and error states remain visible.
Parent identity, platform identity, and rule copy come from the authenticated server session.
“Enforcement confirmed” appears only for current complete evidence.
Degraded, refused, stale, and release-pending states remain distinguishable.
The platform authorization leg is clearly part of Phosra Link.
Shared-profile actions, recommendation, disclosures, and authenticated catalog/count-only identity remain SDK-owned.
“Managed via Phosra” tracks the actual active shared target, not one member’s connection.

See the Provider quickstart for integration code and the disconnect guide for release language.

​Compatibility

​Never show a fake green

​Platform co-branding

​Shared-profile confirmation

​Ongoing provenance

​Review checklist

Compatibility

Never show a fake green

Platform co-branding

Shared-profile confirmation

Ongoing provenance

Review checklist