.svg)
.svg)
Digital credentials are rapidly transforming how we prove identity and access services—bringing convenience, security, and control to users across industries. As this ecosystem matures, foundational components like interoperable credentials, trusted issuers, and secure wallets are becoming more available and widely adopted. The Digital Credentials (DC) API represents a crucial new layer that ties everything together—enhancing usability, improving security, and enabling a smoother experience for everyone involved.
This API represents the natural next step in the evolution of digital identity infrastructure. By focusing on selecting the credential rather than the wallet, it bridges a key usability gap, streamlining the way users access and share their digital credentials online. Whether you're a user trying to log into a service, a wallet developer aiming for broader reach, or a service provider looking to scale adoption, the DC API helps reduce friction, improve trust, and unlock new value. It’s a win for the entire ecosystem—setting the stage for more seamless, secure, and scalable digital interactions.
The NASCAR problem
Before we dive into the intricacies of the API, it’s crucial to understand the problems it is solving—and why it’s such a big deal.
The ‘NASCAR problem’ in digital authentication is a well-known issue where users are forced to choose from a long list of authentication options—much like the sponsors on NASCAR cars and drivers’ suits. This leads to a poor user experience (UX), where users must sift through multiple options to find the one that will enable them to authenticate with a particular service
Now, imagine a user is trying to use a digital credential (such as a Mobile driver’s License or mDL) to access a service, but their device has multiple wallet apps where the required credential might reside. Without a centralized way to manage this, they are faced with an overwhelming screen full of buttons that are hard to distinguish and easily lead them to dead ends.
This situation is not just frustrating; it’s limiting. Users find themselves in a sea of choices, struggling to remember if they hold the relevant credential and, equally important, where they hold it. This leads to wasted time, poor user experiences, and increased dropout rates.
Furthermore, the ‘dead-end problem’ occurs when users select an app that isn’t installed, or doesn’t actually contain the credential they need. This results in confusion, frustration, and potential security risks.
To limit the impact of these UX issues, most relying parties are forced to limit the number of wallets they support. This consolidation leads to fewer choices for users, strengthens the dominance of large players in the digital wallet space and stifles innovation.
OID4VP and redirects: Robust web to native app Experience
The core issue lies in navigating between web applications (where users are attempting to access a service) and native apps (where users hold the credentials required to access these services). One of the common current approaches is based on OpenID for Verifiable Presentations (OID4VP) and uses redirects to transfer authentication requests from web apps to native wallets. While this works, it is not without issues—especially when supporting multiple wallets or authentication methods.
One possible solution, which was the starting point for trying to solve this problem in industry, is to use a single custom URL scheme (such as OID4VP’s default mdoc-openid4vp://) to invoke different wallet applications. However, this becomes problematic when a user has multiple compatible apps installed. On Android, users will see a selection screen when multiple apps are available (if they haven’t already set a long term preference), but on iOS the system does not currently offer the same flexibility, leading to a fragmented experience across platforms.
Another possible solution based on OpenID4VP is to use targeted URLs (deep links) for each app, so that each application is invoked by a unique URL linked to a different UI element. But with the rise of multiple applications that can hold digital credentials, this leads to the NASCAR problem discussed above. Relying party experiences become encumbered with an overwhelming number of options, making the selection process confusing. With multiple buttons, users don’t know which wallet application holds the required credential. This also means relying parties are burdened with maintaining a list of supported digital wallet apps, requiring new deployments to add new wallet integrations.
An ideal solution would allow a seamless transition from a web app to a native app and back again, without an overwhelming experience that could leave the user in a dead-end. This is where the DC API comes in—by enabling a more intuitive way to select the right credentials without navigating a fragmented set of choices.
Moving beyond the wallet selection problem
The most significant breakthrough the DC API brings to the table is its shift from selecting a wallet to selecting the right credential. Instead of forcing users to choose between multiple wallets, this API helps users select the credential they need. This simplification eliminates the need for relying parties to support multiple wallets and reduces friction for users.
At a high level, the DC API allows apps to register as wallets capable of storing and presenting digital credentials. Once registered, the API acts as an intermediary in any credential request, talking to the wallets and running a “matcher” that determines which credentials are available. The user is then presented with a list of matching credentials to choose from.
As a result, relying parties no longer need to integrate with individual wallet applications. They simply send their credential request to the API, which aggregates a list of credentials from all registered wallet apps, providing the user with a consistent and intuitive UX.
Tackling security and user privacy
Security is critical in any system that handles sensitive information like digital credentials. One of the key challenges in building the DC API was ensuring that it didn’t introduce new attack vectors for malicious actors.
The DC API offers clear benefits for both credential holders and verifiers:
- It provides a privacy-friendly alternative to invoking wallet apps through URLs, especially when using custom URL schemes. With this approach, the underlying system will only launch a wallet app if the user explicitly agrees, after seeing clear information about who’s making the request and why (the verifier or relying party).
- Once the interaction is done, or if the user decides to cancel it, the session seamlessly continues in the original context, typically right where they started, like in the same browser tab. This creates a smoother, more intuitive user experience.
- Cross-device requests make use of secure communication methods with built-in proximity checks, handled by the operating system itself. While still in an experimental state, in a cross-device scenario the DC API uses the CTAP 2.1 protocol which under the hood uses Bluetooth Low Energy (BLE) to verify that the two devices are in physical proximity before proceeding with the interaction. This helps verify that the devices are physically close to each other, mitigating the risks of replay attacks or session hijacking (e.g., screenshotting a QR code and reusing it).
- During each request, the wallet app receives verified information about who the requestor is (the verifier or relying party), authenticated by the user’s browser. This is a key defense against phishing attacks, helping users trust who they’re sharing their data with.
- The DC API prevents unauthorized access and ensures that malicious apps cannot silently track users’ interactions or access sensitive data.
What it is and what it isn't
While the DC API may seem like app-to-app communication protocols, there’s a crucial difference: this API is specifically designed for web applications, not native apps. It streamlines the user experience for digital credentials accessed via web browsers. Native apps will use separate APIs to interact with digital credentials, and these will vary between platforms (iOS and Android).
The ongoing effort to standardize the DC API across platforms reflects a collaborative approach that ensures broader interoperability and future-proof integration, paving the way for consistent support and implementation across diverse environments.
Conclusion: Why it’s a big deal
The DC API represents a major shift in how we think about authentication, digital wallets, and credential management. By enabling a seamless, credential-centric selection workflow, the API eliminates the friction of navigating a fragmented wallet ecosystem. Users no longer need to guess which app holds their credential, and relying parties are freed from maintaining complex wallet integrations.
This simplified, secure, and intuitive experience isn’t just a UX improvement—it’s an enabler of entirely new possibilities. With smoother interactions, users are more likely to complete transactions, access services, and adopt digital credentials in everyday contexts. For service providers, this translates into lower abandonment rates, improved trust, and the opportunity to scale offerings more broadly. It also opens the door to entirely new types of secure, high-trust interactions—from remote onboarding to multi-device workflows—unlocking revenue streams in sectors like finance, healthcare, travel, and government.
Reducing security risks and providing a consistent experience across devices and platforms lays the foundation for a truly interoperable digital identity ecosystem. The future of digital credentials isn’t just about convenience—it’s about unlocking a smarter, safer, and more empowering digital world where trusted interactions are seamless, scalable, and accessible to all.
