#W3C Digital Credentials API (DC-API): A Developer's Guide to Browser-Based Digital Credentials

In the evolving landscape of digital identity, one of the biggest gaps has been a native, browser-based way for users to present and receive digital credentials – without QR codes, custom URL schemes, or hard-to-debug cross-device hacks.

Protocols like OpenID for Verifiable Credential Issuance (OpenID4VCI) and OpenID for Verifiable Presentations (OpenID4VP) standardize the issuance and presentation of verifiable credentials across wallets and services. But until recently, these flows have largely lived outside the browser (mobile apps, deep links, QR flows).

The W3C Digital Credentials API (often called “DC-API” or “DC API”) changes that. It is a web platform API that lets websites request and receive digital credentials directly in the browser, with the user agent mediating the interaction between the website and the user’s wallet or credential store.

In essence, DC-API is the bridge between web apps and digital wallets: it brings verifiable credentials into everyday web experiences while preserving cryptographic security and user privacy.

#What is DC-API, Exactly?

#In Simple Terms: A Browser-Based “Show Your ID” Button

Imagine you’re on an e-commerce site and want to buy age-restricted goods. Today you might:

• Upload a photo of your ID,
• Or switch to a mobile app,
• Or scan a QR code with another device.

With DC-API, the website can instead ask:

“Please prove you’re over 21.”

Your browser:

1. Shows you a system UI explaining what’s being requested and by which site.
2. Talks to your wallet (on the same device or another device).
3. Lets you pick a credential that satisfies the request.
4. Returns a cryptographically verifiable presentation back to the website.

You stay in the browser. You see clearly what’s being shared. The site gets a verifiable proof instead of a blurry JPG.

#The Official Definition (De-Jargonized)

Formally, the W3C Digital Credentials API is a JavaScript API that enables user agents (browsers) to mediate presentation and issuance of digital credentials (such as mobile IDs, mDLs, or verifiable credentials). It:

• Builds on Credential Management Level 1, extending the navigator.credentials surface with a digital member.
• Is protocol-agnostic, but defines a registry of supported protocols (e.g., OpenID4VP over DC-API).
• Treats the browser as a trusted mediator: it can inspect requests, enforce permissions, and show UX that keeps users in control.

Key idea: DC-API is not itself a “credential protocol”. It’s a browser API that carries credential protocols between the website and the wallet.

#Key Actors: Website, User, User Agent (Browser) … and Wallet

A typical DC-API interaction involves:

#Website (Verifier or Issuer)

The web app calling navigator.credentials.get() (for presentation) or navigator.credentials.create() (for issuance). It knows what claims it needs (e.g. age_over_21, full_name).

#User (Holder)

The person who owns the credentials. They see the browser’s consent UI and decide whether to share or accept a credential.

#User Agent (Browser)

The gatekeeper. It:

• Validates the origin.
• Mediates access to the wallet(s) and identity APIs on the platform.
• Presents a credential chooser / consent UI.

#Wallet / Credential Store

A platform wallet (e.g. Apple Wallet, Google Wallet) or another app registered as a wallet. It holds the actual credentials and builds the cryptographic presentation or issuance response.

This is a shift from “mobile-app + QR codes” flows to browser-native credential flows, but the underlying issuer-holder-verifier model stays the same.

#How DC-API Works (A Step-by-Step Flow)

The DC-API protocol defines a clear sequence of interactions between the website, the browser, and the user's credential store. While the underlying implementation may vary depending on the browser and wallet integration, the developer-facing API remains consistent and straightforward.

#Step 1: The Website Requests a Credential

The process begins when a website needs to request a credential from the user. The website's JavaScript code calls the DC-API, typically using a method like navigator.credentials.get() with a credential request object. This request specifies:

• The type of credential needed (e.g., a government-issued ID, a university diploma)
• The specific claims required (e.g., age_over_21, full_name)
• The expected origin(s) for security validation
• Any protocol-specific parameters (if using OpenID4VCI or OpenID4VP under the hood)

The browser receives this request and validates that it comes from an authorized origin, preventing malicious websites from requesting credentials without user consent.

#Step 2: The Browser Presents the Request to the User

The browser acts as the user's agent, presenting the credential request in a secure, user-friendly interface. This interface shows:

• Which website is requesting the credential
• What specific information is being requested
• What credential will be used to satisfy the request
• Clear options to approve or deny the request

This step is crucial for user privacy and security. The browser ensures that users have full visibility into what is being requested and who is requesting it, preventing phishing attacks and ensuring informed consent.

#Step 3: The User Approves and the Browser Retrieves the Credential

If the user approves the request, the browser securely communicates with the user's credential store (which may be built into the browser, a browser extension, or a connected mobile wallet). The credential store:

1. Locates the appropriate credential(s) that satisfy the request
2. Constructs the necessary presentation or issuance response (depending on whether this is a presentation or issuance flow)
3. Applies selective disclosure if only specific claims are needed
4. Signs the response with the user's private key (for holder binding)
5. Returns the credential data to the browser

#Step 4: The Browser Returns the Credential to the Website

The browser receives the credential from the credential store and returns it to the website's JavaScript code via the DC-API response. The website can then:

• Validate the cryptographic signatures
• Extract the claims it needs
• Proceed with the business logic (e.g., granting access, completing a purchase)

The entire flow happens within the browser, creating a seamless user experience while maintaining the security and privacy guarantees of verifiable credentials.

#DC-API vs. OpenID4VCI/VP: Understanding the Relationship

A common point of confusion for developers is understanding how DC-API relates to OpenID4VCI and OpenID4VP. The relationship is complementary rather than competitive:

#OpenID4VCI/VP: The Protocol Layer

OpenID4VCI and OpenID4VP are protocol specifications that define the exact messages, endpoints, and cryptographic mechanisms for credential issuance and presentation. They specify:

• How authorization requests are structured
• What endpoints wallets and issuers/verifiers must implement
• How cryptographic proofs are created and validated
• The exact format of credential offers, presentation requests, and responses

These protocols are transport-agnostic—they can work over HTTP, mobile deep links, QR codes, or any other communication channel.

#DC-API: The Browser API Layer

DC-API is a browser API that provides a JavaScript interface for web developers. It abstracts away the underlying protocol details, allowing developers to request credentials without needing to understand the intricacies of OpenID4VCI or OpenID4VP.

DC-API can use OpenID4VCI or OpenID4VP as its underlying protocol, but it could also work with other protocols. The browser implementation handles the protocol-specific details, translating between the simple JavaScript API calls and the complex protocol messages.

#How They Work Together

Consider a website that needs to verify a user's age:

1. Website calls DC-API: The website's JavaScript calls navigator.credentials.get() with a request for an age verification credential.
2. Browser uses OpenID4VP: Under the hood, the browser (or its connected wallet) constructs an OpenID4VP authorization request, including a DCQL query specifying the required credential and claims.
3. Wallet processes OpenID4VP: The user's wallet receives the OpenID4VP request, matches it against stored credentials, and creates a verifiable presentation.
4. Browser returns via DC-API: The browser receives the OpenID4VP response and translates it back into a simple JavaScript object that the website can use.

This layered architecture provides the best of both worlds: the standardization and interoperability of OpenID4VCI/VP at the protocol level, combined with the developer-friendly simplicity of DC-API at the application level.

#Real-World DC-API Use Cases

The true value of DC-API lies in its ability to solve real-world problems with a seamless user experience. Here are some practical examples:

#Use Case 1: Age Verification for E-Commerce

The Problem: Online retailers selling age-restricted products (alcohol, tobacco, adult content) need to verify customer age, but traditional methods are either insecure (self-reported age) or intrusive (uploading full ID documents).

The DC-API Solution: An e-commerce website can use DC-API to request a single claim: age_over_21: true. The user's browser presents a clear consent prompt, and if approved, the website receives cryptographically verified proof of age without learning the user's name, address, or exact date of birth. This enables compliance with age restrictions while maximizing user privacy.

#Use Case 2: Digital Credential Issuance for Online Learning

The Problem: Educational platforms want to issue digital certificates and diplomas, but the current process often requires manual verification, email delivery, and separate credential management systems.

The DC-API Solution: After a student completes a course, the learning platform can use DC-API to issue a verifiable credential directly to the student's browser-based wallet. The student receives their credential instantly, and it's cryptographically signed and tamper-evident. The student can then use DC-API to present this credential to employers or other educational institutions, all within their browser.

#Use Case 3: Streamlined KYC for Financial Services

The Problem: Financial institutions must perform Know Your Customer (KYC) checks, but traditional processes require customers to upload sensitive documents, wait for manual verification, and often share more information than necessary.

The DC-API Solution: A bank's website can use DC-API to request specific KYC claims from a government-issued digital ID. The user sees exactly what information is being requested, approves the request, and the bank receives cryptographically verified identity data in seconds. This dramatically reduces onboarding time, improves security, and enhances user privacy through selective disclosure.

#Current Status and Browser Support (2025)

Standardization Status • The W3C Digital Credentials API is currently a Working Draft on the W3C Recommendation track. • It is maintained by the Federated Identity Working Group and was first published as a Public Working Draft in July 2025; the latest Working Draft (December 2025) continues to refine the model, security, privacy, and registry of supported protocols.

Browser & Platform Implementations

Support is still emerging, but already quite real:

• Chrome (Android & Desktop)
  • DC-API is available as an origin trial starting in Chrome 128 on Android for same-device presentation flows.
  • From Chrome 136, cross-device support lets desktop Chrome display a QR code that the user scans with an Android phone; credentials are then presented from the phone’s wallet back to the desktop site.
  • Access currently requires enabling a flag and/or participation in the origin trial, but the pattern is clear: DC-API is the primary web surface for Android wallets.
• Safari & WebKit (Apple Platforms)
  • Safari 26 on macOS, iOS, and iPadOS introduces web support for the W3C Digital Credentials API.
  • Websites can request mobile IDs (e.g., a state ID in Apple Wallet) and get a signed, encrypted response.
  • Safari also supports cross-device flows where a Mac or iPad uses an iPhone as the wallet device via a QR-based handoff.
• Developer Sandbox & Test Verifier
  • The digitalcredentials.dev site and tools provide cross-browser demos, test verifiers, and documentation for experimenting with DC-API and OpenID4VP.

In practice, DC-API support is good enough for pilots and developer experimentation. For production systems, you should:

• Implement feature detection & graceful fallback.
• Avoid assuming a specific browser or OS.
• Keep up with spec changes (the API is still a Working Draft).

#Security and Privacy Considerations

DC-API is designed with security and privacy as fundamental principles. Key security features include:

#Origin Validation

The browser validates that credential requests come from authorized origins, preventing malicious websites from requesting credentials without user consent. The expectedOrigins parameter allows websites to specify which origins are allowed to receive credential responses, providing an additional layer of protection against cross-origin attacks.

#User Consent and Transparency

Every credential request must be explicitly approved by the user through a browser-mediated consent interface. Users see exactly what information is being requested and which website is making the request, ensuring informed consent and preventing phishing attacks.

#Cryptographic Security

DC-API leverages the same cryptographic security mechanisms as OpenID4VCI and OpenID4VP, including:

• Holder Binding: Credentials are cryptographically bound to keys controlled by the user, preventing credential theft and replay attacks.
• Selective Disclosure: Users can share only the specific claims needed, minimizing data exposure.
• Tamper Evidence: Credentials are cryptographically signed, making any tampering immediately detectable.

#Protocol-Level Security

It's important to note that DC-API does not provide data integrity on credential requests or responses itself—this responsibility lies with the underlying protocol (e.g., OpenID4VCI or OpenID4VP). The API provides a secure transport mechanism, but the cryptographic guarantees come from the credential format and exchange protocol being used.

#Practical Implementation: A Hands-On Walkthrough

For developers building web applications that need to request credentials, implementing DC-API involves calling the browser API and handling the response. For a complete implementation example, check out the walt.id Digital Credential Button project, which provides a reference implementation for invoking the Browser-based DC-API.

#DC-API FAQ

#Is DC-API a W3C standard yet?

Not yet. As of late 2025, the Digital Credentials API is a W3C Working Draft on the Recommendation track. It is stable enough for experimentation, but you should expect some changes in the IDL, registry details, and protocol integration over time.

#What is the relationship between DC-API and Credential Management Level 1?

DC-API builds upon the Credential Management Level 1 specification, which defines a general framework for credential storage and retrieval in browsers. DC-API extends this framework specifically for verifiable credentials, adding support for cryptographic proofs, selective disclosure, and protocol-agnostic credential exchange.

#Can DC-API work with mobile wallets?

Yes, DC-API can work with mobile wallets through browser extensions or connected services. The browser acts as the intermediary, communicating with the mobile wallet to retrieve credentials. This allows web applications to leverage the security and convenience of mobile wallet implementations while providing a seamless browser-based user experience.

#Is DC-API only for credential presentation, or can it also be used for issuance?

DC-API supports both credential issuance and presentation. The same API can be used to request credentials from users (presentation) or to issue new credentials to users (issuance), depending on the underlying protocol being used (OpenID4VP for presentation, OpenID4VCI for issuance).

#How does DC-API compare to WebAuthn?

WebAuthn is a browser API for passwordless authentication using public key cryptography. DC-API is a browser API for exchanging verifiable credentials. While both use similar browser infrastructure (Credential Management), they serve different purposes:

• WebAuthn: Authenticates users ("prove you are who you claim to be")
• DC-API: Exchanges credentials ("share verified attributes about yourself")

They can be used together—for example, a website might use WebAuthn for authentication and DC-API for requesting additional verified attributes.

#What happens if a user doesn't have the required credential?

If the user doesn't have a credential that satisfies the request, the browser will return a NotFoundError. Your application should handle this gracefully, potentially:

• Falling back to an alternative verification method
• Redirecting the user to an issuer where they can obtain the required credential
• Providing clear instructions on how to obtain the credential

#Next Steps

• OpenID4VP - Explore the presentation protocol that DC-API can use under the hood.
• OpenID4VCI - Learn about the issuance protocol for credentials.
• How to verify credentials via DC-API - Check out the walt.id Verifier API docs for DC-API verification flows.

#Additional Resources

• W3C Digital Credentials API Working Draft and its integration with Credential Management and the protocol registry
• W3C blog announcing the Digital Credentials API and noting early implementations from Google and Apple
• Chrome origin trial announcements for the Digital Credentials API on Android and cross-device from desktop Chrome, including usage details and flags
• WebKit blog introducing Digital Credentials API support in Safari 26 across Apple platforms and describing same-device and cross-device flows