# Federated Trust

> Federated Trust gives people, organizations, applications, and agents a governed way to establish identity, delegate access, and protect business secrets across company boundaries.

## Product

- [Home](https://federatedtrust.com/): Governed identity, authorization, delegation, and custody across company boundaries.
- [About](https://federatedtrust.com/about): Purpose, public design commitments, and documentation governance.
- [Trust center](https://federatedtrust.com/trust): Public control and standards status with claim labels.
- [Vendor comparison](https://federatedtrust.com/comparison): Federated Trust vs FusionAuth, C1, Okta, and Auth0 across 44 capabilities with maturity-labeled evidence.
- [Preview access](https://federatedtrust.com/preview-access): Request a bounded evaluation conversation.
- [Publication notes](https://federatedtrust.com/changelog): Dated notes for the public documentation surface.

## Documentation

- [Platform documentation](https://federatedtrust.com/docs): Audience-led guidance for people, organizations, publishers, developers, and security teams.
- [Integration readiness](https://federatedtrust.com/docs/quickstart): Prepare a bounded evaluation without assuming an unpublished SDK.
- [Glossary](https://federatedtrust.com/docs/glossary): Canonical definitions for identity, authority, custody, and claim-status vocabulary.
- [For people](https://federatedtrust.com/docs/people): Identity, recovery, privacy, and delegated application or agent access.
- [For organizations](https://federatedtrust.com/docs/organizations): Tenant policy, data-plane control, custody, support access, and portability.
- [Apps and licensing](https://federatedtrust.com/docs/apps): How software licensing stays separate from recorded data access.
- [Vault and custody](https://federatedtrust.com/docs/vault): Encrypted organization vault items and custody policy.
- [Layered authorization](https://federatedtrust.com/docs/authorization): RBAC, ReBAC, ABAC, and local final deny.
- [Security and standards](https://federatedtrust.com/docs/security): Security posture and governing references.
- [Developer model](https://federatedtrust.com/docs/developers): Integration model for builders and operators.

## Discovery

- [Full agent index](https://federatedtrust.com/llms-full.txt): Quotable docs, glossary, FAQ, and control excerpts for agents.
- [XML sitemap](https://federatedtrust.com/sitemap.xml): Canonical crawlable URL list.
- [Crawler policy](https://federatedtrust.com/robots.txt): Public crawl allow rules.
- [Security contact](https://federatedtrust.com/.well-known/security.txt): Vulnerability reporting contact.
- [Humans](https://federatedtrust.com/humans.txt): Humans.txt for the public site.

## Claim status

Public security statements distinguish implemented, limited/pilot, designed, planned, independently validated, and governing-reference claims. Those labels are part of the claim.

- Federated Trust Vault: planned as a separately deployable service; its target payload suite is AES-256-GCM in versioned envelopes, not a current generally available control.
- Customer-controlled connected and sovereign/offline data planes: designed target profiles, not generally available offerings; each requires a validated package and explicit infrastructure, key custody, offline policy/revocation, update, recovery, observability, support, and evidence responsibilities.
- OAuth authorization code, S256 PKCE, authorization-server metadata, OpenID Connect-oriented issuer/UserInfo surfaces, JWT/JWK handling, and WebAuthn-oriented passkey ceremonies: limited/pilot implementation evidence, not blanket certification or universal profile claims.
- SAML 2.0 federation and SCIM 2.0 provisioning: planned profiles, not generally available controls.
- NIST SP 800-63-4, NIST SP 800-38D, the federal Enterprise SSO Playbook, and RFC 9700: governing references, not certification statements.
- ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205), NIST SP 800-227, OAuth token exchange, rich authorization requests, and proof-of-possession: planned targets or references, not claims of current universal deployment.

## Core boundaries

- Authentication passwords are verified, not recoverable. A pepper strengthens a verifier; it does not reveal the original password.
- Federated Trust controls the versioned pepper for a Federated Trust-hosted authentication realm; a business operating an isolated tenant-local or sovereign realm controls that realm's separate pepper and reset plan.
- Recoverable business credentials belong in encrypted organization vault items with an explicit custody policy.
- Licensing an app permits software use. Tenant consent and authorization separately determine data access.
- RBAC, ReBAC, and ABAC contribute to policy decisions. Signed capability verification, attenuation, and exact reference-service request binding have limited/pilot code evidence; independent issuer-key resolution and relying-party rollout remain gated.
- Designed local-enforcement contract: the resource service retains final deny; conformance must be proven for each relying service.
- Customer data-plane control uses typed SDK, RPC, or API contracts; it does not imply unrestricted database access.

## Optional

- Indexing: Public documentation is crawlable and indexable. Canonical URLs, page-level metadata, and claim-status labels remain authoritative.