A predictable integration sequence
1. Register the app
Use the white-label admin app’s developers section or the equivalent CLI or MCP contract to declare the publisher, responsible party, environments, callback surfaces, and requested operations.
2. Create a tenant installation
Keep commercial entitlement, tenant installation, workload identity, and data grants as separate records and decisions.
3. Connect Layer 1
Use Federated Trust authentication and ReBAC authorization for the actor, memberships, relationships, roles, grants, policies, tenant context, and narrow cloud decision. All fact writes go to Layer 1.
4. Enforce Layer 2
Present the workload and delegated authority to the app’s resource service, which evaluates audience, tenant, revision, revocation, and resource-local deny conditions without creating a new relationship or grant.
5. Declare the offline profile
If the app must operate disconnected, consume a Layer 1-signed, versioned, expiring projection; define staleness, degrade or fail-closed behavior, revocation, update, rollback, secure-time, and recovery; and send every fact write to cloud Layer 1.
The separate publisher, license, tenant installation, workload identity, consent, and data-grant lifecycle is designed; the governed mutation and release path is not generally available.
Typed policy and relationship evaluation exists in code and tests. Independent Federated Trust deployment, operational evidence, and relying-party integration remain incomplete.
Managed, customer-controlled connected, and sovereign/offline profiles are designed target shapes, not generally available offerings. Each requires a validated package and explicit infrastructure, custody, update, recovery, observability, and support responsibilities.
Local audience, tenant, revision, revocation, and resource-policy enforcement is a required design contract; conformance must be proven for each relying service.
Lifecycle management is first-class in every surface
The first-pilot product contract uses one federatedtrust.com Worker for identity, admin, and account-center route groups in a single deployment with shared libraries/contracts and attached Cloudflare resources. This prevents shared-library version skew across Tier-0 login surfaces. Identity splits into a separate Worker later only if Tier-0 isolation from admin is required at scale. Each white-label domain has its own admin app and developers section. This is a target contract, not a claim that a generally available deployment exists.
UI
The developers section is the human lifecycle surface for application registration, environments, credentials, installations, grants, rotations, and retirement.
CLI and MCP
Command-line and agent workflows are first-class surfaces over the same governed lifecycle contracts, not secondary automation around the UI.
Packages and skills
Approved versioned packages are distributed through npm and JSR, with agent skills for internal consumers and third-party developers; package names, publication, compatibility, and support evidence remain explicit release gates.
Pilot scope
The product build is limited to the first pilot; BIZ-1/2/3 govern any broader investment envelope.
The separate publisher, license, tenant installation, workload identity, consent, and data-grant lifecycle is designed; the governed mutation and release path is not generally available.
Typed service contracts preserve portability
SDK, RPC, and API boundaries
Versioned contracts keep applications independent of the physical datastore and prevent raw database access from bypassing policy.
Deployment-neutral identity
The same application contract can target a hosted or customer-controlled data plane when that profile is available.
Explicit status
Integration documentation must distinguish implemented, limited, designed, planned, independently validated, and governing-reference claims.
Managed, customer-controlled connected, and sovereign/offline profiles are designed target shapes, not generally available offerings. Each requires a validated package and explicit infrastructure, custody, update, recovery, observability, and support responsibilities.
Agents are workloads with delegated authority
Separate identity
An agent or automation process acts through its own workload identity and does not store a person’s reusable credential.
Narrow task boundary
The target delegation carries audience, actor chain, resource, action, purpose, lifetime, and revocation information.
Secrets by reference
Applications and agents should receive short-lived use authority or secret references, not broad vault exports or plaintext embedded in prompts.
Strict attenuation, a size-limited signed-envelope verifier, runtime-opaque verified artifacts, and exact reference-service request binding exist in code and tests. Independent issuer-key resolution and relying-party rollout evidence remain gated.
Roadmap reference for narrowing delegated authority across actors and workloads; it is not represented as a generally available issuance flow.
OAuth 2.0 Rich Authorization Requests (RFC 9396)Roadmap reference for structured authorization detail. Current integrations must not assume this request shape is accepted.
DPoP (RFC 9449)Roadmap reference for sender-constrained OAuth tokens. It is not a blanket statement that current clients are sender constrained.
Integrate to the declared profile, not an acronym
Federated Trust uses standards as governing references and roadmap inputs, but each client and relying service must document the exact flows, algorithms, assurance assumptions, and sender constraints it supports.
Identity profile
Do not infer an assurance level, protocol flow, or phishing-resistance property from the platform name alone.
Authorization profile
Do not assume token exchange, rich authorization requests, or sender-constrained tokens are accepted until the integration profile says so.
Cryptographic profile
Do not assume post-quantum algorithms are active until the envelope suite and key directory explicitly advertise them.
| Profile area | Public baseline | A deployment must disclose | Status |
|---|---|---|---|
| Public availability and evidence | No generally available integration or independently validated deployment profile is published as of 2026-07-12. | Service/version, maturity, operator, evidence owner, evidence date, review scope, and unresolved gates. | Designed |
| OAuth and OpenID Connect flows | No universal authorization, federation, or device flow is asserted by these platform pages. | Enabled flows, PKCE requirements, redirect rules, client type, client authentication, consent, and logout behavior. | Designed |
| Tokens and sender constraints | Token exchange, Rich Authorization Requests, and DPoP are planned rather than generally available. | Issuer, audiences, signing algorithm and key source, lifetimes, refresh policy, sender constraint, revocation, and clock-skew policy. | Designed |
| Human and workload assurance | No universal assurance level or phishing-resistance claim applies across relying parties; workload and delegated identities remain separate from a person. | Authenticator classes, proofing level, step-up rules, workload credential, actor-chain semantics, and recovery process. | Designed |
| Data plane and key custody | Managed, customer-controlled connected, HYOK, and sovereign/offline shapes are designed profiles, not generally available offerings. | Infrastructure operator, datastore owner, KMS/HSM owner, who can invoke unwrap, backup/export format, deletion, retention, recovery, and residency. | Designed |
| Support and break glass | Platform operation is not tenant data authority; support delegation and local final deny are designed conformance requirements. | Grantor, grantee, scopes, expiry, approvals, step-up, recipient release, audit evidence, revocation, emergency access, and customer notification. | Designed |
Authorization-code issuance, exact registered redirects, and focused negative tests exist for named clients. This is limited implementation evidence, not a universal OAuth conformance claim.
OAuth PKCE S256 (RFC 7636)Registered public-client authorization-code paths require S256 PKCE in code and focused tests; each deployed client and callback still needs its own integration evidence.
OAuth authorization-server metadata (RFC 8414)A scoped metadata surface exists in code and conformance tests. Published fields and endpoint behavior remain deployment-specific and are not represented as universal support.
OpenID Connect Core 1.0Issuer metadata, ID-token, JWKS, and UserInfo-oriented surfaces have focused implementation evidence. No OpenID certification or universal flow/profile claim is made.
JSON Web Token (RFC 7519)Signed access and identity token contracts exist with issuer, audience, lifetime, key-id, and algorithm checks. Their assurance remains bound to the named issuer and verifier profile.
JSON Web Key (RFC 7517)Versioned public verification keys are exposed through a JWKS-oriented implementation path; rotation and relying-party cache behavior require deployment evidence.
Web Authentication Level 2RP-ID- and origin-scoped passkey registration and authentication ceremonies exist in code and focused tests. Availability and authenticator policy remain host/profile specific.
SAML 2.0SAML enterprise federation is a planned connection profile. No generally available SAML service-provider or identity-provider conformance is claimed.
SCIM 2.0 (RFC 7643 and RFC 7644)SCIM user and group lifecycle provisioning is planned. No generally available SCIM schema or protocol conformance is claimed.
NIST SP 800-63-4Governing reference for risk-based identity proofing, authentication, federation, privacy, and lifecycle decisions. Assurance outcomes are service-specific.
OAuth 2.0 Security Best Current Practice (RFC 9700)Governing reference for OAuth threat mitigations. Each integration must publish its actual profile and controls.
ML-KEM (FIPS 203)Roadmap target for post-quantum key establishment in versioned, crypto-agile recipient envelopes after implementation and interoperability validation.
ML-DSA (FIPS 204)Roadmap target for selected durable signatures such as manifests and key-directory material, not a claim about current tokens.
SLH-DSA (FIPS 205)Roadmap target for selected long-lived signature use cases where its security and performance tradeoffs fit.