Privacy and security
Privacy and security goals
Section titled “Privacy and security goals”The Digital Credentials API sits at a sensitive intersection between:
- a website that requests credentials
- holder software (a wallet)
- the user agent mediating the interaction
The specification is designed to improve security, privacy, and accessibility compared to common alternatives such as QR-code-based flows and custom URL schemes.
Readable requests, opaque responses
Section titled “Readable requests, opaque responses”A central design choice is:
- requests are unencrypted, so the user agent can inspect them for risk analysis and user transparency
- responses are treated as opaque, which allows protocols to encrypt sensitive personally identifiable information end-to-end
This separation supports user-agent protections without forcing the browser to understand every credential format.
User activation and mediation
Section titled “User activation and mediation”The API requires transient activation for both presentation and issuance requests. This reduces the risk of sites silently probing for credentials or repeatedly prompting the user without direct user intent.
Fingerprinting and availability leaks
Section titled “Fingerprinting and availability leaks”The specification explicitly tries to avoid leaking:
- whether a particular credential is stored on the device
- whether a wallet application is installed
For example, protocol support checks must not vary based on installed wallets or credential availability.
Protocol-level security still matters
Section titled “Protocol-level security still matters”The DC API provides an invocation layer. Security and privacy properties of the end-to-end exchange depend on the chosen protocol and credential formats.
For presentation protocols, registry inclusion criteria include supporting encrypted responses and requiring encryption for responses that contain personally identifiable information.