# Federated Trust — full agent index > Federated Trust gives people, organizations, applications, and agents a governed way to establish identity, delegate access, and protect business secrets across company boundaries. - Canonical: https://federatedtrust.com/ - Short map: https://federatedtrust.com/llms.txt - Sitemap: https://federatedtrust.com/sitemap.xml - Security contact: https://federatedtrust.com/.well-known/security.txt - Humans: https://federatedtrust.com/humans.txt ## Public routes - [Federated Trust | Governed identity, authorization, and custody](https://federatedtrust.com/): Federated Trust gives people, organizations, applications, and agents a governed way to establish identity, delegate access, and protect business secrets across company boundaries. - [About | Federated Trust](https://federatedtrust.com/about): The purpose, public design commitments, and documentation governance of Federated Trust. - [Publication notes | Federated Trust](https://federatedtrust.com/changelog): Dated notes for changes to the Federated Trust public documentation surface. - [Platform documentation | Federated Trust](https://federatedtrust.com/docs): Audience-led guidance for people, organizations, application publishers, developers, security teams, and operators using Federated Trust. - [Glossary | Federated Trust](https://federatedtrust.com/docs/glossary): Canonical definitions for Federated Trust identity, authority, delegation, custody, deployment, and claim-status vocabulary. - [Integration readiness | Federated Trust](https://federatedtrust.com/docs/quickstart): Prepare a bounded Federated Trust evaluation without assuming an unpublished SDK or generally available service. - [For people | Federated Trust](https://federatedtrust.com/docs/people): What people should expect from identity, recovery, privacy, and delegated application or agent access in Federated Trust. - [For organizations | Federated Trust](https://federatedtrust.com/docs/organizations): How Federated Trust separates tenant policy, data-plane control, custody, support access, and portability for businesses. - [Apps and licensing | Federated Trust](https://federatedtrust.com/docs/apps): The Federated Trust application model for publishers, partners, customers, internal software, external software, consent, and revocation. - [Vault and custody | Federated Trust](https://federatedtrust.com/docs/vault): The planned Federated Trust Vault model: encrypted payloads, customer custody, organization recovery, BYOK/HYOK profiles, agents, and crypto agility. - [Authorization | Federated Trust](https://federatedtrust.com/docs/authorization): How Federated Trust cloud authentication and ReBAC authorization interoperate with per-app authorization, capability delegation, and offline or edge enforcement. - [Security and standards | Federated Trust](https://federatedtrust.com/docs/security): The Federated Trust public security posture, with implemented, limited, designed, planned, independently validated, and governing-reference claims kept distinct. - [For developers | Federated Trust](https://federatedtrust.com/docs/developers): How developers integrate the two-layer trust model through first-class UI, CLI, MCP, packages, skills, workload identity, and local authorization. - [Preview access | Federated Trust](https://federatedtrust.com/preview-access): Open a validated email draft to discuss a bounded Federated Trust preview and its actors, authority, custody, and evidence boundary. - [Identity platform comparison | Federated Trust](https://federatedtrust.com/comparison): Filterable comparison of Federated Trust, FusionAuth, C1, Okta, and Auth0 across deployment, protocols, authorization, agents, and governance, with maturity-labeled claims. - [Trust center | Federated Trust](https://federatedtrust.com/trust): Public security and standards posture for Federated Trust, with an explicit maturity status attached to every claim. ## Documentation by audience - [For people](https://federatedtrust.com/docs/people) — People - [For organizations](https://federatedtrust.com/docs/organizations) — Businesses - [Apps and licensing](https://federatedtrust.com/docs/apps) — Builders - [Vault and custody](https://federatedtrust.com/docs/vault) — Businesses - [Authorization](https://federatedtrust.com/docs/authorization) — Security teams - [Security and standards](https://federatedtrust.com/docs/security) — Security teams - [For developers](https://federatedtrust.com/docs/developers) — Builders ## Documentation excerpts ### One person. Explicit authority in every context. URL: https://federatedtrust.com/docs/people Federated Trust separates who a person is from what any one organization, application, or agent may do. Joining a business context does not erase personal boundaries, and signing in does not grant blanket access. #### Identity establishes the actor, not unlimited permission Authentication answers whether the presented credential belongs to an account. Authorization still evaluates the organization, relationship, resource, action, and current policy. - Context is visible: Interfaces should identify the organization and application context in which a person is acting before a consequential action is approved. - Step-up follows risk: Sensitive actions can require stronger or more recent authentication according to the relying service’s risk decision. - Access is revocable: Membership, relationship, role, and delegated authority can change independently of the person’s identity record. #### A sign-in password is not a vault secret Authentication passwords are verified, not displayed back to the account holder or an organization. A pepper can strengthen a password verifier against database-only theft, but it does not make the original password recoverable. - Authentication recovery: Account recovery resets or replaces an authenticator after appropriate checks; it does not decrypt the old password. - Recoverable business credentials: A password or secret that a business must retain belongs in an encrypted organization vault with an explicit custody policy. - Personal material stays separate: Business recovery authority should never silently extend to a person’s private vault or unrelated credentials. #### Applications and agents act through separate grants - No inherited omnipotence: An application or AI agent does not automatically receive every permission held by the person who started it. - Purpose and time matter: Delegated authority should identify the task, audience, allowed action, resource boundary, and expiration where the integration supports it. - The resource still decides: The service holding the resource applies its own policy and can deny an otherwise valid request. ### Keep organizational authority with the organization. URL: https://federatedtrust.com/docs/organizations Organizations define who may administer their business context, which applications may be installed, where protected data is held, and how business-owned secrets can be recovered. Operating the platform does not itself grant tenant data authority. #### Trust plane and data plane are separable Federated Trust is designed to coordinate identity, application registration, policy, and delegation while protected business data remains in a deployment selected for that organization. These profiles are not generally available yet. - Provider-hosted: The designed managed profile reduces operational burden while retaining tenant boundaries, scoped support, and export responsibilities. - Customer-controlled: The designed connected profile places the data store and key services in infrastructure controlled by that customer, with typed service interfaces rather than unrestricted database coupling. - Isolated and sovereign: A sovereign or offline profile requires a validated deployment package, local key custody, bounded offline policy and revocation, rollback protection, secure time, recovery drills, and explicit update, observability, and support responsibilities. #### Support access is a grant, not an operator privilege - Explicit appointment: The designed model lets a customer appoint a service provider or partner to administer a defined resource set without granting platform-wide authority. - Least privilege: Support access should be scoped, time-bound where practical, attributable to a named actor or workload, reviewable, and revocable. - Local final deny: Every conforming customer-controlled service or vault must retain the final policy check before protected data is returned or changed. #### Enterprise connections need named protocol profiles Federation and lifecycle standards are configured per connection; a platform name alone does not prove every flow or provisioning behavior. - OIDC connections: OpenID Connect-oriented enterprise connection and issuer surfaces have limited implementation evidence; tenant pinning, assignment, claims, recovery, and lifecycle remain connection-specific. - SAML: SAML 2.0 is a planned enterprise federation profile and is not represented as generally available. - SCIM: SCIM 2.0 user and group provisioning is planned, including explicit ownership, reconciliation, deprovisioning, and evidence responsibilities. #### Business recovery must be chosen and disclosed An organization may need authorized custodians to recover business-owned vault items created by employees. That requires encryption-key custody—not password peppering—and should be visible to every affected user. - Named custodians: Recovery authority belongs to a defined organization role or approval quorum, never every administrator by implication. - BYOK is customer-managed, not automatically provider-blind: In a BYOK profile, the customer manages the key, but the service runtime may still be authorized to invoke unwrap. BYOK alone is not a zero-knowledge claim. - HYOK keeps unwrap authority with the customer: A validated HYOK profile keeps unwrap authority in the customer-controlled key service and gives the provider runtime no unwrap path. Sovereign profiles use a local KMS or HSM under the same rule. - No universal provider key: The target custody model does not depend on one provider-wide key that can decrypt every tenant’s vault. ### License the app. Grant the data separately. URL: https://federatedtrust.com/docs/apps Federated Trust is designed for customers and partners that build software for their own teams, their customers, or a broader market. The governed publishing and installation path is not generally available yet. A commercial entitlement permits use of an app; it never silently authorizes access to tenant data. #### The application lifecycle has distinct decisions - Register and publish: A publisher identifies the application, its responsible party, release identity, requested integration surface, and declared data needs. - License or subscribe: A commercial relationship determines whether a tenant may install or use the software. It is an entitlement, not a data grant. - Install and consent: A tenant administrator evaluates requested access, creates or approves the tenant-specific application identity, and grants only the required authority. - Operate and revoke: Workload actions remain attributable, policy-bound, auditable, and independently revocable from the software license. #### Internal and external apps use the same trust boundary - Customer-built: A business can build internal software without giving the publisher or platform operator standing access to its data. - Partner-built: A partner can distribute software across multiple customers while every installation receives its own tenant context and grants. - Publicly licensed: A broadly available app still receives access only after the installing tenant’s policy and consent decisions. #### Applications consume governed interfaces Customer control of the data plane does not mean every app receives raw database or query-language access. - Typed contracts: Applications integrate through versioned SDK, RPC, or API contracts that preserve authorization and validation boundaries. - Workload identity: Automation acts as an identified workload, optionally on behalf of a person, rather than borrowing a reusable human credential. - Resource-specific enforcement: The service holding the data verifies tenant, audience, action, and local policy before performing the operation. ### Protect business secrets without confusing them with sign-in passwords. URL: https://federatedtrust.com/docs/vault Federated Trust Vault is a planned, separately deployable service—not a generally available offering today. Its contracts keep recoverable secrets distinct from authentication passwords and make custody, recovery, and deployment responsibility explicit. #### Planned payload protection and versioning The target Federated Trust Vault payload suite is AES-256-GCM in versioned encryption envelopes. Deployment documentation must identify the active suite and its evidence before describing that control as implemented. - Authenticated encryption: AES-GCM protects confidentiality and detects unauthorized changes when nonces, keys, and associated data are handled correctly. - Keys are separate authority: Ciphertext storage, encryption-key custody, and authorization are separate responsibilities; possession of one should not imply the others. - No universal key target: The target architecture avoids a single provider-wide decryption key across unrelated organizations. #### Organization visibility requires an encryption custody policy If a business must recover credentials created by an employee, that item must be stored as business-owned encrypted material and wrapped to an approved organization custodian or recovery quorum. - Disclose the boundary: People should be told when an organizational vault is recoverable by authorized business custodians. - Separate personal vaults: Personal material should remain outside organization recovery unless the owner makes a distinct, informed grant. - Support is delegated: A partner can assist only when the tenant grants a scoped recovery role, key recipient, or quorum share under the applicable profile. #### Pepper protects a verifier; it does not reveal a password - One-way authentication: A password verifier is designed to confirm a password without storing a recoverable copy of that password. - Pepper is defensive input: A separately held pepper can make stolen verifier data harder to attack, but losing or rotating it can require users to reset passwords. - Custody follows the authentication realm: The Federated Trust operator controls the versioned pepper for a Federated Trust-hosted sign-in realm. A business operating an isolated tenant-local or sovereign realm controls that realm’s separate pepper and reset plan. - Vault encryption is the business feature: Recoverable shared passwords belong in encrypted vault items governed by organization custody and access policy. #### Post-quantum readiness is a migration program The crypto-agility plan targets hybrid recipient envelopes and selected durable signatures. It does not describe today’s symmetric encryption as post-quantum public-key encryption. - Key establishment: ML-KEM is planned for post-quantum key establishment after implementation and interoperability validation. - Durable signatures: ML-DSA and SLH-DSA are planned candidates for long-lived manifests, key-directory material, and audit checkpoints where appropriate. - Algorithm agility: Envelope records need explicit suite, key, and version identifiers so recipients can migrate and reject downgrade attempts. ### Decide with policy. Delegate with a narrow artifact. URL: https://federatedtrust.com/docs/authorization The governing model has two composed layers: Federated Trust supplies cloud authentication and the single authorization write authority, while every app evaluates access to its own resources strictly downstream of those facts. An app can be cloud-first, offline-capable, or both without introducing a competing relationship engine. #### Two layers interoperate instead of competing REPO-017 is the consolidated governing corpus. FederatedTrust owns a first-pilot product, but the target remains a designed deployment profile until its release and operating evidence exists. - Layer 1: Federated Trust: Federated Trust provides cloud authentication plus ReBAC-centered authorization and is the only writer of firm, membership, relationship, role, cross-party or coalition grant, and policy facts. - Layer 2: downstream app evaluation: Each application evaluates its resource-specific decision from live Layer 1 facts or a verified Layer 1 projection plus resource-local state. It may deny or narrow, but cannot invent a grant or run a competing relationship engine. - Cloud and offline paths: Cloud-first and offline-capable applications use the same decision logic. Offline evaluation consumes a signed, versioned, expiring Layer 1 projection, accepts no relationship or policy writes, and fails closed by default for sensitive operations when the projection is stale past its bound. - Pilot product boundary: FederatedTrust owns the product for the first pilot. Broader investment remains governed by BIZ-1/2/3 and is not implied by the authorization architecture. #### Three policy lenses answer different questions - RBAC: job-shaped access: Roles provide understandable bundles for recurring responsibilities, but should not become the only source of truth. - ReBAC: durable relationships: Relationship-based policy expresses who owns, belongs to, manages, sponsors, or is affiliated with a resource or organization. - ABAC: contextual narrowing: Attributes such as tenant, environment, assurance, purpose, device, time, or transaction risk can further constrain a request. #### Capability-based authorization is a delegation target CapBAC is not a fourth competing policy engine. Size-limited signed-envelope verification, opaque verified artifacts, attenuation, and exact reference-service request binding exist in code; independent issuer-key resolution and relying-party rollout evidence remain gated. - Attenuation only: A delegated artifact can become narrower in resource, action, audience, purpose, or lifetime; it cannot create authority the delegator did not have. - Actor chain: Human, application, agent, and downstream workload identities remain distinguishable for policy and audit. - Short-lived and revocable: High-risk delegation should use bounded lifetimes, unique identifiers, current policy revision, and a revocation path. #### Layer 2 retains per-app final deny A Layer 1 decision or valid delegation is necessary but not sufficient to read or change a protected application resource. - Audience match: A service rejects authority issued for another relying service or environment. - Resource-local evaluation: The service evaluates the exact resource, current tenant state, Layer 1 revision and revocation state, and local deny conditions before acting. - Fail closed: Unknown subject mappings, ambiguous tenant context, unverifiable delegation, or an expired projection for a sensitive operation ends in denial. ### Controls, references, profiles, and roadmap—clearly labeled. URL: https://federatedtrust.com/docs/security Security language should make verification easier, not hide maturity behind acronyms. Every item below is labeled so tested code is not confused with an operated service, a designed deployment shape, independent validation, or a future engineering target. #### Implementation boundary Code-level evidence is useful, but it is not the same as general availability or an independently operated control. - Authorization substrate: Layered authorization, signed capability verification, attenuation, and exact reference-service request binding have focused code and test evidence; independent operation and relying-party rollout remain gated. - Vault service: Federated Trust Vault is planned as a separately deployable service. No generally available Federated Trust Vault encryption control is claimed today. #### Designed deployment profiles These profiles express the target architecture. They are not generally available until the package and its operating evidence are validated. - Customer data-plane control: The connected target places the datastore and key services in customer-controlled infrastructure while applications use governed service contracts. - Sovereign and disconnected operation: The offline target additionally requires local custody, bounded offline policy and revocation, rollback protection, secure time, signed updates, recovery drills, and assigned support and observability responsibilities. #### Protocol implementation profiles These labels describe scoped code and test evidence. They do not assert certification or every optional feature in the underlying standard. - OAuth and OpenID Connect: Named public-client paths use authorization code with S256 PKCE, exact redirects, metadata, signed tokens, public verification keys, and scoped identity claims. Each deployment still publishes its exact profile. - Passkeys: WebAuthn-oriented ceremonies bind credentials to an RP ID and expected origin; host policy and authenticator requirements remain explicit per deployment. - Enterprise roadmap: SAML 2.0 federation and SCIM 2.0 directory lifecycle are planned profiles, not generally available controls. #### Governing references These sources guide design and review. They do not create a certification or identical assurance outcome across every relying party. - Digital identity: NIST SP 800-63-4 informs risk-based identity proofing, authentication, federation, privacy, recovery, and lifecycle decisions. - Federation programs: The federal Enterprise SSO Playbook informs sponsorship, inventory, integration, operations, and federation-by-agreement. - OAuth security: RFC 9700 informs threat mitigations; each client and service still needs an explicit integration profile. #### Crypto-agility and delegation plan Planned items are not represented as deployed or generally available. - Post-quantum envelopes: ML-KEM is targeted for hybrid key establishment in versioned recipient envelopes after validation. - Post-quantum signatures: ML-DSA and SLH-DSA are targeted selectively for long-lived signed material where their tradeoffs fit. - Delegated authorization: Token exchange, rich authorization details, and proof-of-possession are roadmap references for narrower workload authority. ### Build once around stable trust boundaries. URL: https://federatedtrust.com/docs/developers The first-pilot FederatedTrust product gives internal and third-party developers one two-layer contract. Federated Trust cloud authentication and authorization own the shared facts; each app evaluates its resource decisions downstream without coupling to another tenant’s database or keys. #### 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. #### 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. #### 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. #### 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. #### 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. ## Glossary - **Identity**: The recognised person, application, or agent established independently from any single application. - **Authority**: What a recognised actor is permitted to do inside a specific organization context. Authority is narrower than identity. - **Custody**: The party that holds the protected business material and the key services. Custody is decided per deployment profile. - **Delegation**: A recorded, reviewable, revocable grant of narrowly-attenuated authority from one actor to another. - **Relying service**: A resource server or business surface that evaluates authorization at request time. It retains final deny in every profile. - **Deployment profile**: One of managed, customer-controlled, or isolated: a named target shape for where business data and keys live and who operates them. - **Final deny**: The resource service retains the last word on any action. No claim can override the local deny. This invariant survives every deployment profile. ## Trust center status vocabulary - **Implemented** (`implemented`): Implemented in a Federated Trust service path with current evidence. The named deployment and evidence scope still matter. - **Limited / pilot** (`limited-pilot`): Code or contracts exist, but integration, operational, or assurance gates still prevent general availability. - **Designed** (`designed`): An approved target shape or contract that is not represented as generally available. A validated deployment package is still required. - **Planned** (`planned`): A stated engineering target that is not represented as implemented, generally available, or deployed today. - **Independently validated** (`independently-validated`): Implemented and assessed independently for a named scope and evidence date. This label does not extend beyond that evidence. - **Governing reference** (`governing-reference`): Authoritative material used to guide design and review. This status is not a certification or a universal conformance claim. ## Public controls (status is part of the claim) - **Federated Trust Vault target payload suite** — Planned: Federated Trust Vault is not generally available. Its planned payload suite is AES-256-GCM in versioned envelopes, subject to deployment and cryptographic evidence. - **Customer-controlled and sovereign data planes** — Designed: 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. - **Application publishing, licensing, and tenant installation** — Designed: 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. - **Scoped tenant support delegation** — Designed: Explicit, scoped, expiring, reviewable support authority is implemented as a reference contract and test substrate, but general Federated Trust service enforcement is still designed work. - **Layered RBAC, ReBAC, and ABAC decisions** — Limited / pilot: Typed policy and relationship evaluation exists in code and tests. Independent Federated Trust deployment, operational evidence, and relying-party integration remain incomplete. - **Bounded capability delegation** — Limited / pilot: 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. - **Resource-service final deny** — Designed: Local audience, tenant, revision, revocation, and resource-policy enforcement is a required design contract; conformance must be proven for each relying service. - **Organization custody and quorum recovery** — Planned: Explicit organization-custodian and multi-party recovery workflows are planned. They never turn an authentication password into recoverable data. - **OAuth 2.0 authorization code (RFC 6749)** — Limited / pilot: 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)** — Limited / pilot: 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)** — Limited / pilot: 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.0** — Limited / pilot: Issuer 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)** — Limited / pilot: 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)** — Limited / pilot: Versioned public verification keys are exposed through a JWKS-oriented implementation path; rotation and relying-party cache behavior require deployment evidence. - **Web Authentication Level 2** — Limited / pilot: RP-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.0** — Planned: SAML 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)** — Planned: SCIM user and group lifecycle provisioning is planned. No generally available SCIM schema or protocol conformance is claimed. - **NIST SP 800-38D** — Governing reference: Governing reference for Galois/Counter Mode authenticated encryption. Reference use does not assert FIPS module validation. - **NIST SP 800-63-4** — Governing reference: Governing reference for risk-based identity proofing, authentication, federation, privacy, and lifecycle decisions. Assurance outcomes are service-specific. - **Enterprise Single Sign-On Playbook 1.3** — Governing reference: Governing reference for sponsorship, inventory, integration, lifecycle, and federation-by-agreement practices. - **OAuth 2.0 Security Best Current Practice (RFC 9700)** — Governing reference: Governing reference for OAuth threat mitigations. Each integration must publish its actual profile and controls. - **OAuth 2.0 Token Exchange (RFC 8693)** — Planned: 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)** — Planned: Roadmap reference for structured authorization detail. Current integrations must not assume this request shape is accepted. - **DPoP (RFC 9449)** — Planned: Roadmap reference for sender-constrained OAuth tokens. It is not a blanket statement that current clients are sender constrained. - **ML-KEM (FIPS 203)** — Planned: Roadmap target for post-quantum key establishment in versioned, crypto-agile recipient envelopes after implementation and interoperability validation. - **ML-DSA (FIPS 204)** — Planned: Roadmap target for selected durable signatures such as manifests and key-directory material, not a claim about current tokens. - **SLH-DSA (FIPS 205)** — Planned: Roadmap target for selected long-lived signature use cases where its security and performance tradeoffs fit. - **NIST SP 800-227** — Planned: Roadmap reference for selecting and using key-encapsulation mechanisms as the post-quantum envelope profile matures. ## Integration readiness - **Start with the public status boundary**: Review the status taxonomy before selecting an integration path. No generally available SDK, sandbox, or universal deployment profile is promised by this page. - Record which capabilities are limited-pilot evidence, designed contracts, planned targets, or governing references. - Treat every availability statement as service- and evidence-specific. - **Name the actors and organization context**: Describe the person, application, agent, and relying service separately, including the organization context in which each actor operates. - Do not reuse a person’s credential as a workload identity. - Make the actor chain visible for policy and audit. - **Describe the minimum authority**: Write the proposed audience, resource, action, purpose, lifetime, and revocation path before designing an issuance flow. - Delegation can become narrower; it must not create authority the delegator did not hold. - Token exchange, rich authorization requests, and proof-of-possession remain planned profile inputs. - **Define local final-deny evidence**: Specify how the resource service will verify audience, tenant, policy revision, revocation, expiry, and exact resource binding before acting. - Unknown mappings, stale policy, and ambiguous tenant context should fail closed. - Partition and recovery behavior must be proven for the selected deployment profile. - **Request a bounded preview discussion**: Share the proposed actors, authority boundary, data-plane profile, and evidence expectations so the team can decide whether a preview evaluation is appropriate. - The request page opens an email draft; nothing is submitted until you send it. - Any accepted preview scope and maturity claims should be captured in writing. ## Home FAQ - Q: Does Federated Trust replace our IdP? A: The design does not require replacing an existing identity provider. Each integration must still document how a person or workload proves identity and how authority is evaluated in the current organization context. - Q: Is this a hosted service or something we deploy ourselves? A: The public documentation describes managed, customer-controlled, and isolated target profiles. They are designed shapes, not generally available offerings, and each still requires a validated deployment package. - Q: How does "final deny" survive the network partition case? A: Local final deny is a required design contract. Each deployment profile must prove its offline-policy, revocation, expiry, rollback, and secure-time behavior before claiming conformance during a partition. - Q: What are the six status labels for? A: Every public claim uses one of six labels: Implemented, Limited pilot, Designed, Planned, Independently validated, or Governing reference. Status is part of the claim. - Q: Can an agent act on behalf of a person? A: Bounded capability delegation has limited-pilot code evidence. The target contract keeps agent identity separate and binds delegated authority to a specific audience, resource, action, purpose, and lifetime. - Q: How do we request access to the preview? A: The preview-access page validates the required details and opens a structured email draft. Sending that draft starts a conversation about whether a bounded evaluation is appropriate. ## Claim boundaries - Do not invent certification, pricing, or general availability claims. - Prefer the short map in llms.txt for routing; use this file for quotable detail. - Indexing: public documentation is crawlable; canonical URLs and status labels remain authoritative.