The Digital Credentials API lets a website request a credential through the browser and the user's credential manager. The API is designed around a platform chooser and explicit user mediation. That improves the default privacy model, but the verifier still owns the hard parts: request design, origin binding, freshness, and what the relying party does with the returned data.

The browser is a mediator

W3C's Digital Credentials specification describes an interface through which a verifier asks the user agent to present a credential. The browser's credential chooser is part of the security model. The specification states that user mediation is required for every credential operation, and it integrates with Permissions Policy to reduce cross-origin abuse.

That means a web page does not silently read a wallet. The user sees a chooser and makes a decision. The interface is designed to make the request visible and to keep the credential manager on the user's side of the boundary.

The browser is not the relying party. It cannot decide whether the verifier needs a particular claim, whether the user is eligible for a service, or whether a credential is still valid for the requested purpose. Those decisions need application logic and a server-side validation path.

Request less than you collect

Start with the business decision. A site that needs to know whether a user is old enough may not need the user's birth date, legal name, or address. A site that needs a membership status may not need a unique government identifier. Data minimization is both a privacy control and a security control because it reduces the value of a logging or storage mistake.

Build the request from the smallest claim set that supports the decision. State the purpose in the interface and keep a stable record of the request template that was approved. If the credential format supports selective disclosure or a derived claim, use it when the user agent and credential manager support the feature.

Avoid using a permanent identifier as a session key. The specification warns that digital credentials can carry highly personal and long-lived identifiers. A verifier should prefer a pairwise or service-scoped identifier when the protocol supports one, and should avoid correlating the same credential across unrelated services.

Validate the response outside the browser

Treat the browser response as untrusted input. Verify the credential issuer, format, signature, audience, nonce, timestamp, and requested claim set on the server. Bind the response to the transaction that started the request so an attacker cannot reuse an old presentation. Reject a response that contains claims the verifier did not request unless the protocol explicitly permits optional disclosures and the application has a policy for them.

For cross-device flows, validate the proximity or session mechanism defined by the protocol. A QR code or device handoff can make the interaction easier, but the verifier still needs to know that the response belongs to the current request. The API specification treats proximity as a security-essential constraint for some presentation flows.

Do not log the raw credential payload by default. Keep the issuer, format, validation result, requested claims, and a correlation ID. If a claim must be retained, document the purpose and retention period. The credential manager's user interface does not remove the verifier's obligation to protect the data after it arrives.

Plan the failure paths

Test a denied request, an unavailable credential manager, an unsupported protocol, an expired credential, and a malformed response. The application should fail closed and tell the user what it can do next without revealing another user's account state.

Test the feature in a cross-origin frame. A page that embeds a verifier should not be able to bypass the Permissions Policy decision or inherit a broader credential request from its parent. Keep the credential interaction on a dedicated origin when possible, and review every frame's allow attribute.

The useful control is a narrow request

Digital Credentials can reduce the number of passwords and copies of identity documents in a web workflow. The security benefit depends on a verifier that asks for the minimum, validates the response on the server, binds it to the transaction, and stores the result for no longer than the service needs.

The browser chooser makes the user's decision visible. It does not make the verifier's decision correct. A well-designed deployment treats the chooser as one control in a chain that starts with the business question and ends with a retention policy.

References