Skip to content
FedTrustFederated TrustDocs

Enter at least two characters.

Type to search all documentation pages and sections. Use ↑ ↓ to move, Enter to open, and Esc to close.

Platform statuses are part of the claim

Integration readiness

Prepare a federated request without assuming unpublished runtime surfaces.

This checklist turns the public trust model into questions an engineering and security team can answer before requesting a bounded preview.

Status first Narrow authority Local final deny

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Continue with the exact boundary you own

The audience pages describe the current public contract in more detail.

Developer model Authorization model Security status Discuss preview scope