How it works

Session lifecycle

A verification flow is a session. Your app creates one, the wallet presents against it, Broker verifies, and your webhook receives the result. Sessions move through three states with a configurable TTL.

Trust-chain validation — all ten checks

Every presentation passes ten independent checks. Any one failure rejects the VP token with a logged reason, so audit reviews reproduce the decision exactly. No check is optional; no check can be bypassed by configuration.

Wallet profile + presentation definition

Two concepts separate which wallets you accept from what you're asking for.

Wallet profile

Accepted formats (vc+sd-jwt, mso_mdoc), the Trust Registry to consult, and optional Policy Engine wiring.

Presentation definition

W3C Presentation Exchange 2.0 — the credential type, required claims, and selective-disclosure constraints. The wallet matches available credentials and prompts the user to consent.

Replay prevention

Two layers: a per-session nonce that binds the wallet's signed authorization request, and a 24-hour VP-token hash cache in Redis. Cross-session replay and within-session resubmission both fail.

Claim extraction + webhook delivery

After verification, Broker POSTs a normalised claims object to your callback URL with an HMAC-SHA256 signature and an idempotency key. Retries use exponential backoff over 30 minutes. A signed-JWT variant is available when your webhook receiver prefers verifying without a pre-shared secret. Undisclosed claim paths are literally absent, not nulled.