How it works

OID4VCI pre-authorized code flow

The canonical flow today. Operator mints an offer via admin API; the user's wallet opens the offer URL, exchanges the pre-auth code for a token at /token, requests the credential at /credential with a holder key proof, and receives the signed SD-JWT VC back.

Authorization code flow

The roadmap flow for user-initiated issuance. Wallet initiates against the issuer's authorization endpoint (PAR + PKCE), which redirects to Hub for authentication. After login, the wallet exchanges the code and requests the credential as in the pre-auth flow.

Credential templates

A template defines a credential type: vct, display name, JSON claim schema, a deferred flag, and a signing-key reference. Operators create, list, update, and soft-delete templates via admin API. No code change to add a new credential type.

Signing

Today an in-memory EC P-256 key signs both credentials and status-list JWS. Migration target: HashiCorp Vault Transit — same pattern as Hub signing. Private key never touches the JVM heap.

Status list + deferred flow

Every credential carries a status index pointing to a signed bitmap. Verifiers fetch the list, check the bit, reject revoked credentials. Operators revoke via admin API. For credentials gated on out-of-band approval (KYC, document review), the deferred flow returns an acceptance_token — wallets poll until the operator approves or denies.

Multi-tenant isolation

Every entity (offers, issued credentials, status lists, templates) carries a tenant_id. Repository queries are tenant-scoped; admin tokens are tenant-scoped; cross-tenant access rejected at the auth filter. Per-tenant signing keys gate on the Vault Transit migration — data isolation is complete today, key isolation is the remaining polish.