For years, proving your identity online has meant turning a physical document back into an image. You photograph a driver's license or passport, upload it, and wait while software determines the legitimacy of the document and the personal information it details.
Digital credentials change what a verifier is looking at. Instead of inspecting a picture of an ID, the verifier can cryptographically confirm that the data was provided by the trusted authority that issued it.
The infrastructure for that model is now reaching ordinary phones and browsers. EU member states are due to offer at least one EU Digital Identity Wallet by the end of 2026. New Zealand released the wallet inside its Govt.nz app on March 31, 2026, with credentials scheduled to arrive progressively from mid-year. Google added support for Aadhaar Verifiable Credentials in Google Wallet in India in April 2026. Chrome and Safari can now request credentials from compatible wallets without sending the user through a document-upload flow. We covered what changed at the platform level in digital ID is going mainstream in 2026.
That does not make every identity check automatic, or every digital credential trustworthy. It does give businesses a different, and often better, piece of evidence to work with. Here is what the technology actually proves.
What is a digital credential?
A digital credential is a set of claims signed by its issuer, so a verifier can confirm who made them and that they have not changed since. The claims might include a name, a driving entitlement, a professional qualification, or a simple answer such as is this person over the age of 18?
Three roles are involved:
- The issuer creates and signs the credential. This could be a transport agency, university, employer, or professional body.
- The holder keeps it in a wallet and chooses when to present it.
- The verifier requests particular claims and checks the response.
A photograph of a license is not a digital credential. Neither is a PDF certificate with a QR code that only opens a webpage. Those files may be useful, but the file itself does not let a verifier cryptographically confirm who issued the data, whether it has changed, or whether the response belongs to the current transaction.
There is also an important limit to the definition. A valid signature proves that an issuer made the claims. Whether the issuer's original checks were sound, whether the verifier should trust that issuer for this purpose, and whether the credential is still acceptable under the verifier's policy are separate questions. Cryptography protects the evidence; it does not make the surrounding trust decision.
A credential proves what an issuer says about its subject. A passkey proves the same account holder is back. The two do different jobs, and businesses will need solutions that ensure both.
What a verifier checks
Most high-assurance verification flows answer three questions.
1. Do we trust the issuer?
The verifier checks the issuer's signature against a trusted public key. In mobile driver's license ecosystems, the signing certificate chains back to an issuing authority certificate. Trust services distribute the approved roots: for example, AAMVA's Digital Trust Service publishes a Verified Issuer Certificate Authority List for participating North American issuers.
This lets a verifier authenticate the source without asking the issuing authority to approve every presentation. Some credentials still need a status check, and the usual approach is a published list covering many credentials at once rather than a lookup on a single one. The verifier downloads and caches that list, so no request reveals which credential was presented or when. The signature tells you the data is authentic. The status list tells you it has not been revoked since.
2. Has anything changed?
In an ISO mdoc, which is the format used for mobile driver's licenses and other mobile identity documents, the issuer signs a Mobile Security Object containing hashes of the credential's data elements. The holder can disclose selected elements, and the verifier recomputes their hashes before checking the signature. Each element's hash includes a random salt, so the hashes of the elements a holder held back reveal nothing about what they contain.
Change a disclosed date, name, or entitlement and the check fails. This is fundamentally different from document-image verification, where a model is estimating whether an image looks manipulated.
3. Is this a fresh presentation from the expected holder or device?
Many credential profiles support holder binding. An mdoc can bind the credential to a key controlled by the wallet. During presentation, that key proves the response was produced for the current session, using either a signature or a MAC. Either way, a previously captured response cannot be replayed.
That is sometimes described as "device binding," but the phrase needs care. The ISO/IEC 18013-5 standard defines how an mDL can prove possession and integrity, while leaving private-key storage requirements out of scope. Hardware-backed, non-exportable keys are an implementation and issuer-policy choice, not a property that can be assumed for every digital credential.
Fresh key proof also does not, by itself, tell a remote business which person is holding the phone. Wallets generally require a local unlock or biometric approval before releasing data, but that local check is different from the verifier matching the presenter to the portrait inside the credential. For higher-risk flows, a live face match against the issuer-signed portrait can add that person-level check. It also introduces a biometric process, with its own accuracy, consent, retention, and regulatory requirements.
Selective disclosure: ask for the answer, not the document
One of the most useful parts of digital credentials is the ability to request only the fields a transaction needs.
A physical driver's license exposes a name, full date of birth, document number, portrait, signature, and in most countries a home address, when a cashier only needs to know whether the customer is old enough. An mdoc can contain issuer-calculated age thresholds, allowing the verifier to request age_over_18 or age_over_21 without receiving the date of birth or anything else on the card.
That reduces the amount of personal data a business has to transmit, process, and protect. Anonymity is a different matter. An age-over result attached to an account or transaction can still be personal information, so the verifier should request, log, and retain only what it genuinely needs.
A threshold answer only does the job if the transaction can act on it alone. If you also need to match the presenter to the credential, or attach the result to an account, the request has to include something to bind it to: the issuer-signed portrait for a live face match, or a name or document number for the account record. Ask for the smallest set the check actually needs, not the smallest set the credential can produce.
How a credential reaches a website
On a supported browser, a website can call the W3C Digital Credentials API. The browser asks the operating system for matching credentials, the user chooses a wallet and reviews the requested fields, and the response returns to the requesting site. On desktop the wallet is on a separate device, so the same call routes through a cross-device flow instead of a local one.
There is more than one way to make that request. A site can call the Digital Credentials API directly, or fall back to a redirect-based OpenID4VP flow that hands off to a wallet and returns the response to a callback. The industry is converging on the Digital Credentials API as the primary experience, with OID4VP redirects as the practical fallback until more wallets support it.
Whichever path a wallet supports, the request is built on your server. It carries the nonce that ties the presentation to this session and the public half of an ephemeral key pair whose private half never leaves your backend. The response comes back encrypted to that key, so every check described above happens after it reaches your server. The front-end flow being short is what leads teams to underestimate the verification work.
The browser sits in the middle for a reason. It can provide the wallet with the real website origin and require user mediation, which makes silent credential requests and simple origin-spoofing attacks harder.
Browser support arrived in late 2025. The API is enabled by default from Chrome 141, including same-device presentation on Android and a cross-device flow on desktop. Safari 26 supports the API for ISO mdoc requests using the org-iso-mdoc protocol.
On desktop Chrome's cross-device path, scanning a QR code establishes an encrypted connection and uses the same Bluetooth-based proximity check that passkeys use for cross-device sign-in (FIDO CTAP). That protection belongs to that managed browser flow. A generic QR-based OpenID4VP redirect does not automatically prove that the phone and desktop are close together; the security properties depend on the transport and protocol in use.
mdoc, SD-JWT VC, and OpenID4VP
The terminology gets messy because credential formats, data models, and presentation protocols are often discussed as if they were interchangeable.
Two formats matter most for current implementations:
- ISO mdoc is defined by ISO/IEC 18013-5 and related standards. It uses CBOR and COSE, and is the established format for mobile driver's licenses and other government identity documents.
- SD-JWT VC uses selectively disclosable JSON Web Tokens. It is suited to a broader range of credentials, including identity, employment, membership, and entitlement claims.
The W3C Verifiable Credentials Data Model 2.0 defines a general way to express issuer, subject, claims, and proofs. It is a data model rather than a single on-the-wire format. Meanwhile, OpenID4VP 1.0 is a presentation protocol that can carry multiple credential formats, including mdoc and SD-JWT VC.
For a verifier, the practical lesson is, do not hard-code the whole product around one wallet, browser, or request envelope. Safari and Chrome already take different paths, and version skew between wallets is already real. The OpenID4VP profile in ISO/IEC 18013-7 is pinned to an earlier implementer's draft while newer deployments target OpenID4VP 1.0, so two standards-compliant wallets can legitimately speak different dialects today.
Where digital credentials help
KYC and customer onboarding
A conventional remote identity check captures a document image, assesses its security features, captures a selfie, runs a liveness test, and compares the two faces. A government-issued digital credential can replace the document-capture and document-authenticity stages with issuer and integrity checks.
That removes one large source of image-quality errors and forged-document risk. Sanctions screening, customer due diligence, fraud controls, and any required proof that the person presenting the credential is its subject all stay where they are. If a biometric match is needed, that step remains probabilistic rather than becoming a "definite" cryptographic answer.
Age assurance
Age is a natural selective-disclosure use case because many services need a threshold, not an identity. It is also a reminder that the credential is one method inside a wider compliance design.
Australia's social media minimum-age rules took effect on December 10, 2025. Covered platforms must take reasonable steps to prevent under-16s from holding accounts, but cannot make government-issued ID or an accredited digital ID the only route. They must offer a reasonable alternative.
New Zealand is moving from policy to everyday acceptance. Regulations effective from May 28, 2026 recognize qualifying credentials from accredited digital identity services as approved evidence of age for alcohol purchases, provided the credential meets the specified assurance and data requirements.
Fraud controls, step-up checks, and recovery
A trusted credential makes it much harder to invent or alter the issuer-backed attributes inside it. That can strengthen onboarding against synthetic identity attempts and give a business better evidence during account recovery or a high-risk transaction.
It should not become a universal recovery key. A credential may prove that a trusted issuer made claims about its subject and that the current wallet can present them. The business still needs to bind those claims to the correct customer account and account for a lost device, shared access, expired data, and coercion. Higher-risk flows may combine the credential with a live holder check and existing account signals.
What accepting digital credentials involves
The happy path is short. Production verification is not.
A verifier needs to keep issuer trust material current, validate signatures and disclosed claims, apply expiry and status rules, and support the protocol variants its users' wallets actually speak. It also needs sensible fallbacks for unsupported browsers, missing credentials, cancelled prompts, and people who choose not to use a wallet.
Data handling matters just as much as cryptography. Request the minimum set of claims, define retention before launch, and treat portraits or live face captures as sensitive biometric data where applicable. Do not keep an ID image merely because an older workflow did.
Authsignal Digital Credential Verification handles same-device, cross-device, and browser-mediated presentation behind one integration. It verifies the issuer and the disclosed credential data, keeps a working path to completed verification when a wallet, browser, or protocol version does not cooperate, and can add biometric holder verification when the risk of the transaction calls for it. The wider rollout picture, and what drop-in acceptance looks like, is in digital identity credentials are going global.
Digital credentials will not remove every judgment from identity verification. They do replace one unreliable question, "does this uploaded image look real?", with a stronger one: "did an issuer we trust sign these claims, and is this a valid presentation of them now?"
