A predictable integration sequence
1. Register the app
In the designed path, the publisher is declared through the Console developers section or the equivalent CLI contract (an MCP contract is planned): 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 accepted first-pilot architecture has three authorities: Federated Trust Identity for protocol and ceremony, Console for the external workbench and public management contract, and a private Writer for mutation. There is no public Writer host. Shared libraries and contracts stay versioned together so login surfaces do not drift. Each white-label domain has its own admin app and developers section. This describes accepted architecture, not a generally available deployment.
UI
The Console developers section is the designed human lifecycle surface for application registration, environments, credentials, installations, grants, rotations, and retirement. Console application registration exists only in limited, named-host scope.
CLI and MCP
Command-line and agent workflows are designed as first-class surfaces over the same governed lifecycle contracts, not secondary automation around the UI. An operator CLI exists in limited scope; the MCP surface is planned.
Packages and skills
Approved versioned packages are designed to ship through npm and JSR, with agent skills for internal consumers and third-party developers. No public package has been released; 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.
Most of this path is designed, not generally available. Each step carries its own status.
- Limited / pilot
Each organization signs in its own people
Organization A establishes the person through its own sign-in and trust anchor. OpenID Connect, PKCE, and passkey ceremonies have scoped pilot evidence.
- Designed
Organizations link their anchors on purpose
Trust between companies is an explicit, pinned agreement between two anchors, never an open network. OpenID Federation 1.1 is a seam over that bilateral model.
- Designed
An AI agent acts under its own identity
The agent in Organization B is a workload with a narrow grant from a person there, not a copy of anyone’s credential. Bounded capability delegation has pilot evidence; the agent identity contract is designed.
- Designed
The receiver verifies, then decides locally
Organization B checks the signed message against Organization A’s anchor through the link, then its own service applies local policy and keeps final deny.
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-09-28. | 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.