Security and privacy
What leaves the phone
Section titled “What leaves the phone”Only the fields the holder approves, for that one request. The wallet shows the requester’s name and the list of fields before anything is sent. A request for “over 21” releases a yes or no, not a birth date.
What your systems receive
Section titled “What your systems receive”| Path | Your page / app sees | Stored where |
|---|---|---|
| Website | the result (state and the requested fields) after the Verify API verified it | on the Verify API for your tenant, read with your secret key; in your own database only if you store it |
| In person | the AcceptanceResult on the operator’s device |
nowhere, unless your app stores it |
| Wallet app | the credentials the holder put there | the phone’s secure storage, keys in hardware |
The Verify API keeps a result only as long as needed to read it; it does not build profiles across tenants, and a secret key reads only its own tenant’s results.
The guarantees behind a result
Section titled “The guarantees behind a result”| Threat | What stops it |
|---|---|
| A forged or edited credential | the issuer’s signature over every field, checked against the issuers you trust |
| A copied credential | device binding: the answer is signed with a key that never leaves the holder’s phone |
| A replayed answer | the session transcript: every answer is bound to this exchange’s nonce and the verifier’s identity |
| An expired or withdrawn credential | validity dates in the credential, and the issuer’s revocation status |
| A fake verifier phishing the holder | the wallet names verifiers from a trusted reader list; unknown verifiers are shown as unknown |
| A stolen, unlocked phone sharing someone’s ID | for credential types you protect, a liveness step and a face match against the credential’s own photo before anything is signed (Prove it’s you) |
| A forged QR on your site | unknown or expired sessions never verify; an expired session cannot be approved |
What to do on your side
Section titled “What to do on your side”- Ask for the minimum fields for the decision. Prefer
age_over_21to a birth date. - Do not store the portrait unless you have a reason and a retention rule; it is biometric personal data.
- Keep the secret key on the server, the reader private key in secure storage, never in source.
- Decide the policy for
INCONCLUSIVEand for stale revocation answers before launch.
Standards behind all of this: Standards and interoperability.