Credentials, programmable
A wallet for users who don't want to manage keys.
Cloud Wallet holds verifiable credentials on behalf of authenticated users. Receives credentials via OID4VCI, encrypts them at rest, and handles two-step consent before presenting them — so your users get credential portability without running a mobile wallet app.
What Cloud Wallet does
Cloud Wallet is a server-side credential store. Authenticated users receive credentials via the OID4VCI pre-authorized code flow; the wallet stores them encrypted with AES-256-GCM. When a broker session asks for a credential, the user previews what's about to be disclosed, gives explicit consent, and the wallet builds a signed VP token with holder binding and submits it. All presentations are logged.
Flow
How a credential flows
- Step 1
User receives a credential offer URI from an issuer (e.g. via QR code).
- Step 2
User calls POST /wallet/credentials/receive with the offer URI.
- Step 3
Wallet exchanges the pre-authorized code, fetches the SD-JWT, encrypts it, and stores it.
- Step 4
Later, user calls GET /wallet/presentation/prepare to preview what a broker session wants.
- Step 5
User calls POST /wallet/presentation/submit with consent; wallet signs the VP token and sends it to the broker.
Standards
Protocols and formats
OID4VCI
Pre-authorized code flow for receiving credentials from an issuer.
OID4VP
Request/response protocol for presenting credentials to verifiers.
SD-JWT VC
Credential format with selective-disclosure commitments.
AES-256-GCM at rest
Per-credential encryption with random IV. Database dumps are unreadable without the key.
Compliance
Consent-first, encrypted-first
The wallet never presents a credential without explicit user consent. Everything at rest is encrypted. Every presentation is logged.
- Two-step presentation flow — prepare (preview) then submit (consent) — never one-shot
- AES-256-GCM encryption at rest with per-credential random IV
- Holder binding via per-user RSA key — VP tokens are cryptographically bound to the user
- Per-user credential scoping — users cannot access each other's credentials
Integration
Wire three API calls, add a consent checkbox
Your app holds the user session. When the user clicks to receive a credential, call POST /wallet/credentials/receive with the offer. When a broker session is active, call /prepare to preview, then /submit with consent. The wallet handles encryption, key binding, and submission.
- Per-user RSA-2048 holder key managed by the wallet
- All presentations audit-logged for compliance and user transparency
- Works with any OID4VCI issuer and any OID4VP verifier
FAQ
Frequently asked
- Is my credential data safe on the server?
- Credentials are encrypted at rest with AES-256-GCM. A database dump is unreadable without the encryption key. The current architecture uses a shared key; planned Vault Transit integration will give each user a unique wrapped key so one user's compromise doesn't expose the whole user population.
- Can the server operator see my credentials?
- Not from a raw database dump. The wallet process can decrypt credentials at presentation time, but an operator with only database access cannot read them. The operator can see metadata (issuer, timestamp). For full privacy, use a client-side mobile wallet instead.
- What if I revoke a credential?
- products.cloudWallet.faqs.q3.a
Ready to hold credentials for your users?
Request access to stand up Cloud Wallet and connect it to your issuer.