Skip to content
Federated TrustAbout

About Federated Trust

A neutral trust layer for people, agents, and the organizations they serve.

Federated Trust documents a governance answer to a plain problem: identity may need to travel across organizations, while authority should remain narrow and context-specific. The deployment profiles, vocabulary, and status labels make that intended separation reviewable without overstating current availability.

Read the platform documentation

The four invariants

Design commitments the platform enforces.

Each commitment maps to controls in the standards library and to an explicitly labeled status entry in the trust center.

Identity travels

The recognised actor is established once and evaluated in every context that follows. Signing in never grants blanket access.

Authority stays narrow

The target delegation contract scopes authority to an organization, service, resource, action, purpose, and lifetime. Attenuation must not expand authority.

Status is part of the claim

No public statement is made without a status label from the platform taxonomy. Certification is a distinct category, not a subtitle.

Final deny is a conformance requirement

The resource service must apply local policy. Every deployment profile still has to prove its expiry, revocation, partition, rollback, and recovery behavior.

How the public documentation is governed

Three responsibilities, kept separate on purpose.

  1. Claim review.

    Wording changes should preserve the design invariants and keep each availability or assurance statement attached to an explicit maturity label.

  2. Reference traceability.

    Governing references and planned protocol inputs remain distinct from implementation evidence, certification, and independently validated controls.

  3. Deployment evidence.

    A profile should not move beyond designed status until its named package, operator responsibilities, evidence date, review scope, and unresolved gates are recorded.