How it works

Server-side holder wallet

Cloud Wallet stores verifiable credentials on behalf of authenticated users. The user holds an account; the wallet holds the credentials. No mobile app required — users receive, hold, and present credentials from a browser.

Receive flow (OID4VCI)

User has an account. An issuer hands the user a credential offer URI (QR / email / deep link). The user posts the URI to POST /wallet/credentials/receive. Cloud Wallet exchanges the pre-authorized code, fetches the credential from the issuer, validates the signature, binds it to the user's holder key, and stores it encrypted.

Server-side key storage

Each user has an RSA-2048 holder key managed by the wallet. Keys live in encrypted database rows; the wallet process decrypts at sign time. This is the medium-assurance tier — robust for most use cases but not ARF-high-assurance. For hardware-backed keys, use the Native Wallet SDK.

Present flow (OpenID4VP)

A verifier sends the user a request_uri. The user forwards it to the wallet at POST /wallet/presentations/prepare. The wallet matches available credentials against the presentation definition and returns a preview — what's requested, what would be disclosed. The user consents at POST /wallet/presentations/submit; the wallet builds a signed VP token with holder binding and posts it to the verifier's response endpoint.

Encryption at rest

Credentials and holder keys are encrypted with AES-256-GCM at rest. Per-user DEK wrapping; the wallet's master key comes from Vault Transit. A leaked database dump is unusable without the Vault envelope key.

Audit log

Every credential received, every presentation submitted, every consent decision — persisted with timestamp, verifier identity, and the specific claims disclosed. Users can inspect their own audit log; operators can audit for incident-response.