Federated identity

Witnora does not replace an enterprise identity provider. It verifies an identity assertion issued by the customer's existing trust system, binds the sanitized result to an action mandate and execution evidence, and records what that authenticated principal was authorized to do.

Supported adapters:

• Standard OpenID Connect discovery and JWKS, including Okta, Auth0, and Microsoft Entra issuers.
• SPIFFE JWT-SVID bundles.
• SPIFFE X.509-SVID certificate chains at the customer-owned gateway.
• Existing Witnora Ed25519 runtime identities as the native adapter.

The persisted agentcert.identity_assertion.v0.1 object contains the exact issuer, audiences, subject, provider, selected non-sensitive claims, expiry, key ID, and SHA-256 digests. Witnora never persists the bearer token, private key, or full claim set.

Trust flow

1. A project admin registers an exact issuer, audience, algorithm allowlist, and optionally a tenant allowlist or SPIFFE trust domain.
2. The gateway submits a short-lived OIDC token, JWT-SVID, or X.509-SVID for verification.
3. Witnora stores a sanitized VerifiedPrincipal; replaying the same token ID or credential digest is rejected.
4. A mandate may bind its grantee to that assertion. The action digest then includes the assertion ID.
5. A short-lived execution grant and the runtime claim carry the assertion digest, preventing identity substitution after approval.
6. The signed action receipt reports the authenticating provider, mandate, independently observed outcome, and evidence strength.

Security boundaries

• Issuer and audience comparisons are exact. Discovery issuer metadata must equal the configured issuer.
• Algorithms are restricted to RS256, PS256, ES256, and EdDSA.
• Assertions are project scoped, expire with the source credential, and cannot be replayed or rebound across tenants.
• SPIFFE IDs must match the configured trust domain. X.509 verification checks certificate time, chain signatures, trust anchors, and exactly one SPIFFE URI SAN.
• Verifying identity does not itself authorize an action. Authorization still requires policy and, when configured, an immutable mandate and approval.

API outline

• POST /v1/projects/{projectId}/identity-providers
• GET /v1/projects/{projectId}/identity-providers
• POST /v1/projects/{projectId}/identity-assertions
• GET /v1/projects/{projectId}/identity-assertions

Use identityAssertionId when proposing an action and granteeIdentityAssertionId when creating a mandate. Existing actions without these fields remain compatible and are explicitly reported as self asserted.