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.
Typed policy and relationship evaluation exists in code and tests. Independent Federated Trust deployment, operational evidence, and relying-party integration remain incomplete.
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.
Federated Trust Vault is not generally available. Its planned payload suite is AES-256-GCM in versioned envelopes, subject to deployment and cryptographic evidence.
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.
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.
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.
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.
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.
Governing reference for risk-based identity proofing, authentication, federation, privacy, and lifecycle decisions. Assurance outcomes are service-specific.
Enterprise Single Sign-On Playbook 1.3Governing reference for sponsorship, inventory, integration, lifecycle, and federation-by-agreement practices.
OAuth 2.0 Security Best Current Practice (RFC 9700)Governing reference for OAuth threat mitigations. Each integration must publish its actual profile and controls.
NIST SP 800-38DGoverning reference for Galois/Counter Mode authenticated encryption. Reference use does not assert FIPS module validation.
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.
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.
NIST SP 800-227Roadmap reference for selecting and using key-encapsulation mechanisms as the post-quantum envelope profile matures.
OAuth 2.0 Token Exchange (RFC 8693)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.
Maturity labels describe the public engineering posture; governing-reference labels identify design inputs. These labels are not a certification, agency authorization, FIPS-validated cryptographic-module claim, or guarantee that every deployment has the same controls. Assurance and responsibilities are established for a named service, integration, evidence date, and risk context.