Security and Privacy
Security model
The wallet is designed with the principle of local custody: private keys and credentials never leave the holder's device, except when the holder decides to present a credential to a verifier.
Private key storage
The holder's private keys are stored in the operating system secure store:
| Platform | Store |
|---|---|
| iOS | iOS Keychain |
| Android | Android KeyStore |
These stores are protected by the device hardware (Secure Enclave on iOS, StrongBox or TEE on Android when available). Private keys are never written to the device filesystem or transmitted to any server.
Credential encryption at rest
Credentials stored in the wallet are encrypted with AES-256 before being saved in the device's local storage. The encryption key is derived from the key material stored in the Keychain / KeyStore.
Access authentication
To access the wallet the holder must authenticate with:
- PIN (6 digits, mandatory).
- Biometrics (Face ID, Touch ID, Fingerprint) — optional, enabled by the holder.
The wallet locks automatically when it moves to the background.
Proof of possession
When the wallet requests a credential from an issuer (OID4VCI), it attaches a proof of possession: a JWT signed with the holder's private key that proves the holder controls the DID to which the credential will be issued. This prevents third parties from requesting credentials on the holder's behalf.
When the wallet presents credentials to a verifier (OID4VP), it signs the VP with the holder's private key. The verifier can check that the presentation was created by the legitimate holder and has not been tampered with.
Privacy model
Data minimization
The wallet only transmits data externally in two moments:
- Credential reception: the wallet communicates with the issuer's endpoint (OID4VCI) to obtain the credential.
- Credential presentation: the wallet sends the VP to the verifier's endpoint (
response_uri) after the holder confirms consent.
In no case does the wallet communicate the content of credentials to third parties, not even to the ISBE team.
The wallet does not send telemetry, does not sync credentials to the cloud, and does not share the holder's DID with any directory service. All storage is local.
Explicit consent
Before sending any presentation, the wallet shows the holder exactly what credential or attributes are going to be shared and with which verifier. The holder must actively confirm the send. There is no automatic presentation mechanism without confirmation.
Selective disclosure
Selective disclosure (sharing only a subset of a credential's attributes) is not available in the current implementation. The wallet always presents the complete credential. The vc+sd-jwt and ldp_vc formats that would enable this functionality are not implemented.
Presentation correlation
Each VP includes the holder's DID as the iss field. This means that if the same holder presents credentials to multiple collaborating verifiers, they can correlate the presentations via the DID.
For use cases requiring greater privacy, consult the ISBE team about available options.
Revocation verification
The wallet verifies the issuer's signature and the credential's expiry date at the time of reception. The wallet does not verify the revocation status of stored credentials (the credentialStatus field is not checked). If a credential has been revoked by the issuer after being issued, the wallet will not detect this automatically.
Communication channel
All wallet communications with issuers and verifiers are conducted exclusively over HTTPS. The wallet rejects any endpoint that does not use TLS.
Security updates
Security updates are distributed through the App Store and Google Play. It is recommended to keep the wallet updated.