Skip to main content
Two different concepts have historically been called “intent.” The Link intent is deployed for the hosted qualification fleet but is not a public npm onboarding surface yet:
The production manifest, trust, and client-directory routes are live, but the Golden packages are published on public npm; credential issuance is still an approved operator workflow. Do not treat this as anonymous self-service production onboarding.
The Golden provider server creates Intent V2 after it has:
  1. authenticated the parent;
  2. resolved the child inside that parent’s tenant boundary;
  3. obtained the child’s stable provider-local householdRef;
  4. verified the target platform and current policy facts; and
  5. created a time-limited ceremony with PKCE and replay protection.
Intent V2 adds a platform-scoped digest of the authenticated household authority. The raw householdRef does not cross the boundary. This enables independently authorized child memberships to converge on a shared platform target without using names, emails, or raw family IDs as correlation keys. Applications using the Golden server do not sign, parse, or transport the intent themselves:
The compact signed artifact is protocol material. Do not log it, expose it to analytics, modify its claims, or reconstruct it from browser state. Advanced conformance implementations can use the explicit @phosra/link/link-intent subpath; product applications should use the Golden server.

​
Signed writes and platform evidence

A signed Link intent is authorization to begin a ceremony. It is not evidence that controls were applied. The lifecycle produces distinct artifacts:
  • a durable binding proves the connection exists;
  • a signed rule write/receipt proves the requested policy was recorded;
  • a verified platform profile proves what Gatekeeper was instructed to apply;
  • signed platform events report concrete per-rule results; and
  • a signed release lifecycle proves revocation and eventual removal.
Parent-facing success must follow those evidence levels. An intent, OAuth code, or delivery acknowledgement alone never means “enforcement confirmed.”

​
Roadmap: generalized policy-resolution API

There is no public /api/v1/intent/resolve endpoint and no published request or response schema. Do not build an integration against examples from older roadmap documents.
A future generalized resolver may accept verified child context, jurisdiction, platform capabilities, and consent standing, then return applicable OCSS rule categories and typed defaults. That work is distinct from Link Intent V2:
  • Link Intent V2 authorizes one concrete linking ceremony.
  • A generalized resolver would help an issuer decide which policy facts apply.
  • Any future resolver output would still need standing, signed writes, platform enforcement, and evidence; resolution would not prove application.
Rule categories remain the normative OCSS vocabulary. Product catalog IDs, platform title IDs, profile IDs, and other vendor-specific database identifiers are not normative OCSS rule values.

​
Integration guidance

  • Use createGoldenLinkServer(...) for new provider applications.
  • Return householdRef only from an authenticated server-side child resolver.
  • Let Link create Intent V2 and let Gatekeeper verify it.
  • Treat generalized intent resolution as roadmap until an endpoint and schema are published.
  • Keep policy resolution, policy recording, and platform evidence as separate states.
See the Provider quickstart, @phosra/link, and the Platform quickstart.