Digital Credentials API: mobile IDs and identity on the web
Understand the W3C Digital Credentials API, browser-mediated wallet requests, selective disclosure, privacy risks and the limits of this developing technology.
What changed in 2026
The W3C published an updated Digital Credentials Working Draft on 20 October 2026. The proposed API gives websites a browser-mediated way to request presentation or issuance of credentials held in a digital wallet. Possible credentials include a mobile driving licence, government identity, education record or proof of employment. The browser sits between the site and credential manager so it can show which site is asking and require a deliberate user action.
Working Draft is the key phrase. It means the design is progressing through the W3C Recommendation track, but details can change and availability can differ across browsers and operating systems. A production service should use capability detection, follow current platform documentation and retain an accessible alternative. A draft API should not become the only way a person can prove eligibility, recover an account or obtain an essential service.
Understand the issuer, holder and verifier flow
An issuer creates a credential, a holder stores it through a wallet or credential manager, and a verifier requests evidence from it. The website does not simply read the wallet. It initiates a supported presentation protocol through the browser, the person chooses an appropriate credential and consents, and the verifier validates the protected response under the relevant trust framework. The API transports the interaction; it does not decide whether an issuer is trustworthy or whether a claim satisfies a law or business rule.
Ask only for the minimum information required. A service checking an age threshold may need proof that the person is over that age, rather than a complete birth date, address and identity number. Whether selective disclosure is available depends on the credential format, protocol and implementation. Record the business purpose for every requested claim and avoid retaining raw identity data merely because the wallet can provide it.
Design for consent, privacy and fraud resistance
The draft requires user mediation and origin binding, which help prevent a site from silently examining available credentials. Those controls do not remove social engineering. A fraudulent site may still invent a convincing reason to request sensitive data. Interfaces should show the requesting organization, purpose, requested claims and consequences before the operating-system or browser prompt appears. Do not train users to approve a vague request just to continue.
Verify signatures, issuer status, expiry, revocation or status information, audience binding and replay protection according to the chosen protocol. Protect logs because even a failed identity exchange can reveal timing, device and account information. Build retention limits and deletion into the design. A screenshot or photocopy of a digital credential is not equivalent to a cryptographically verified presentation and should not silently become a fallback proof.
Plan a responsible pilot
Start with a low-risk, optional use case and test on the actual browsers, wallets and devices used by the audience. Provide plain-language consent, keyboard and screen-reader operation, cancellation, retry and a human support route. Measure completion and error rates without collecting the claims themselves unless they are necessary. Test what happens when no compatible wallet exists, a credential is expired, the person declines, the network fails or the verifier cannot establish issuer trust.
Separate technical verification from authorization. A valid credential may establish a claim but still be insufficient for a particular transaction. Document the applicable policy and manual review path. Monitor the W3C publication history and implementation notes before expanding the pilot, because protocol identifiers, issuance support and privacy protections remain active areas of work in 2026.
Worked example: prove eligibility without copying an ID
Consider an event website that needs to confirm that an attendee is above a required age. The service should document why the threshold applies, request the narrowest supported proof and avoid asking for an address or full document number. Before opening the browser credential chooser, it should explain the request in ordinary language and offer a manual route for people without a compatible wallet.
The verifier checks the protected response, trusted issuer, freshness and intended audience, then stores only the eligibility decision and audit data that policy requires. It does not save a screenshot of the credential. Testers cover a valid proof, an expired credential, a different audience, a replayed response, refusal and an unsupported browser. Legal and privacy review still determines whether the workflow is appropriate in the relevant jurisdiction.
Quick checklist
- Treat the API as developing technology.
- Request only claims required for the stated purpose.
- Keep an accessible non-wallet route.
- Validate issuer, signature, status, audience and replay controls.
- Minimize identity logs and retention.
- Test refusal, expiry, unsupported devices and recovery.
Primary references
Standards and platform support change. Use these authoritative sources to check the current specification and migration guidance.