Authentication & Identity
The EDK provides a layered authentication and identity system that goes beyond simple token validation. It covers the full lifecycle from initial authentication through identity proofing, binding, and ongoing assurance.
| Layer | What it does | Key modules |
|---|---|---|
| JWT Validation | Validate access tokens from multiple IdPs (OIDC, Keycloak, Azure AD, Auth0, Okta) | lib-authn-jwt-validation |
| Identity Verification (IDV) | Composable verification workflows, OIDC, wallet/OID4VP, document, biometric, OTP | lib-identity-idv |
| Identity Matching | Privacy-preserving HMAC-hashed links between external identifiers and internal identities, with LoA tracking | lib-identity-matching |
| Identity Reconciliation | Policy engine that decides whether to accept an existing identity, run IDV, step up, or reject | lib-identity-reconciliation |
| Identity Resolution | Pluggable resolver chain that maps external identifiers to internal identity IDs | lib-identity-resolution |
| Auth Bridge | Bridges OAuth2/OIDC authorization servers with wallet-based OID4VP credential presentation | lib-oid4vp-auth-bridge |
How They Fit Together
A typical wallet-based authentication flow touches all layers:
For simpler deployments without wallets, JWT validation alone is sufficient, the identity layers are opt-in based on which modules are on the classpath.
Identity Modules at a Glance
Identity Verification (IDV)
Graph-based verification workflows that compose method nodes into multi-step identity proofing. A SequenceNode might chain OIDC login → document verification → biometric check. A ThresholdNode might require 2-of-3 methods to succeed.
Each method is a pluggable driver: OIDC, Wallet/OID4VP, Document, Biometric, OTP, ClaimMatch, REST API. Results carry assurance levels (eIDAS LoA, NIST AAL), evidence records, and resolved identifiers that feed into identity matching.
Identity Matching & Reconciliation
External identifiers (holder keys, subject IDs, email hashes, claim tuples) are linked to internal identities using HMAC-SHA256 hashing with domain-separated keys. Sensitive attributes are encrypted with AES-256-GCM. This means the identity store never holds plaintext external identifiers.
Each link binding stores an AssuranceSummary, the LoA, OIDC ACR/AMR, and evidence reference from the verification that established the link. This is what enables step-up decisions: the reconciliation engine compares the stored assurance against the required assurance for the current operation and decides whether to accept, step up, or re-verify.
See Identity Matching & Reconciliation.
Identity Resolution
A pluggable resolver chain that maps an external identifier to an internal identity ID. Resolvers are tried in priority order, the built-in MatchingIdentityResolver uses the identity matching store, but custom resolvers (LDAP lookup, OIDC introspection, directory service) can be added via multibinding.
See Identity Resolution.
Auth Bridge
The OID4VP Authentication Bridge connects wallet-based credential presentation to OAuth2/OIDC authorization servers. A user scans a QR code, presents credentials from their wallet, and the bridge handles verification, identity matching, optional IDV, and user resolution, then returns the result as OIDC claims to the authorization server.
See Auth Bridge.