Internal
Layered RBAC, ReBAC, and ABAC decisions
Typed policy and relationship evaluation exists in code and tests. Independent Federated Trust deployment, operational evidence, and relying-party integration remain incomplete.
Public security posture
Every claim carries its status.
The public documentation separates implemented, limited, designed, planned, independently validated, and governing-reference claims. Those labels remain part of each claim as the platform and publication surface evolve.
Program snapshot
Controls by maturity label.
Each public control is counted under exactly one status from the platform taxonomy.
How to read these labels
Maturity is part of the claim, not a subtitle.
Status is never decorative. Every public control carries exactly one label from the platform taxonomy.
- ImplementedLive path with current evidence
- Independently validatedAssessed for a named scope
- Limited / pilotCode exists; gates remain
- DesignedApproved target, not GA
- Governing referenceDesign input, not a cert
- PlannedStated engineering target
Implementation coalition
Industry Leading Implementers
Cross-disciplinary expertise for cloud delivery, data intelligence, regulated software, physical security, and platform engineering.
Control inventory
Every control, labeled.
28 public controls across 4 maturity labels. Pick a status on the left to review the matching inventory.
Limited / pilot
9 controls in this labelCode or contracts exist, but integration, operational, or assurance gates still prevent general availability.
Internal
Bounded capability delegation
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.
Source linked
OAuth 2.0 authorization code (RFC 6749)
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.
Open governing sourceSource linked
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.
Open governing sourceSource linked
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.
Open governing sourceSource linked
OpenID Connect Core 1.0
Issuer metadata, ID-token, JWKS, and UserInfo-oriented surfaces have focused implementation evidence. No OpenID certification or universal flow/profile claim is made.
Open governing sourceSource linked
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.
Open governing sourceSource linked
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.
Open governing sourceSource linked
Web Authentication Level 2
RP-ID- and origin-scoped passkey registration and authentication ceremonies exist in code and focused tests. Availability and authenticator policy remain host/profile specific.
Open governing sourceSecurity disclosures
Report an issue, or ask for evidence.
Security researchers, procurement teams, and prospective operators can all reach us directly.