Security
This page explains how the Wallet SDK separates app unlock, key-use authorization, storage encryption, and reader trust. Configure each explicitly so your UX can stay simple without hiding the security knobs.
App Unlock
PIN and optional biometric unlock in the sample apps protect access to the app. They are demo-layer. They are not the SDK signing policy.
Signing Policy
Issuance, presentation, and proximity signing use the key-use authorization set when the holder key was created. The default is strong biometrics bound to the current enrollment set. See Keys and Storage.
Timed biometric reuse covers a short window of recent platform authentication. It does not replace holder consent for a presentation.
Encrypted Storage
Credentials and DIDs live in an encrypted SQLDelight database. The database key is stored in Android Keystore or the iOS Keychain unless you supply a DatabaseEncryptionKeyProvider. Signing keys stay in the platform keystore.
Reader Trust
For proximity sharing, the wallet can authenticate the reader that signed the request. Import public Reader CA material and choose whether anonymous readers are allowed.
The sample apps start permissive so you can test immediately. Require a trusted reader for production-like flows. Import only public trust material into the wallet — never a reader private key.
Reader authentication is separate from the reader trusting your credential issuer. Configure the issuer's IACA on the reader, independently of Reader CA configuration in the wallet.
Next Steps
- Configure Reader CAs in a proximity session — Proximity Sharing.
- Recover the signing identity — Backup and Recovery.
- Collect consent before submit — Presenting Credentials via OID4VP.