Welcome to part 4 of our blog series on verifiable digital credentials (VDCs)! In previous blog posts, we set the stage for why VDCs matter, unpacked what VDCs are, and explored practical use cases where VDCs add value.
In this post, we’ll take a deeper look at the VDC ecosystem, including:
- Key terminology
- How VDCs compare to federation and passkeys
- Standards and protocols
- How credentials are issued and trusted
- Where Okta and Auth0 fit in
Let’s dive in!
Terminology
To make the technical details easier to digest, let’s revisit the fireworks store scenario from our earlier blog. Imagine you’re trying to buy sparklers and spinners online, and the store needs to verify that you’re over 18. Here’s how the main players and concepts in the verifiable digital credentials (VDC) world map to that experience:
The actors
You are the holder: You’re the person in possession of the credential. (In some cases, a parent might hold a child’s credentials on their behalf.
The fireworks store is the verifier: It requests and validates the credential to confirm your age.
Your state DMV is the issuer: It asserts claims about you — in this case, that you’re 18 or older — by issuing a mobile driver’s license (mDL).
The tools
Your wallet is the app on your phone that stores and presents the credentials (a type of credential manager, which more broadly includes software for managing passwords, passkeys, and digital IDs).
The mDL itself is the verifiable digital credential (VDC) — a digital credential that’s cryptographically verifiable.
Trust and control
When you check out, you can use selective disclosure to share only the fact that you’re 18, without revealing your full birthdate or home address.
The fireworks store knows it can trust the DMV because the DMV is part of a trust list — a registry of trusted issuers and their cryptographic anchors..
Behind that trust list is a trust framework — the business and policy rules that determine how issuers get on the list and what standards they must follow.
How are VDCs different from federation and passkeys?
VDCs don’t replace federation or passkeys. Think of them as complementary tools: federation connects identities across systems, passkeys secure authentication, and VDCs bring portable, verifiable information into the mix. Together, they create a stronger, more user-friendly identity ecosystem.
Federation
Federated sign-in (aka social sign-in) has been a staple of consumer and enterprise authentication for years. Here’s how it works:
- The user signs in via an identity provider (IdP) such as Google.
- The IdP authenticates the user and issues a token (with claims like name, email, phone).
- The token is sent back to the service, which sets up an account for the user.
The upside: Users don’t need to remember another password.
The downside: Each time you use a federated IdP, you signal what service you’re trying to access, along with metadata like your approximate location. While federated IdP is useful in workforce contexts, this creates significant privacy risks for consumers.
VDCs
- You can think of VDCs as an evolved form of federation.
- An issuer (similar to an IdP in federation) asserts claims about you.
- You, the holder, present those claims to a verifier (similar to a service provider in federation).
- The verifier checks validity using one or more trust lists.
Key difference: You get to hold and control what is shared in VDC. You don’t need to have your personal data stored in your federated (or social login) account. And the company that owns your federated account doesn’t have to hold your personal information, and they don’t see when or how you are using it. In this way, VDCs boost privacy by giving you more control over your identity data.
Passkeys
Passkeys have emerged as a phishing-resistant alternative to passwords, OTPs, and magic links. At first glance, they might look similar to VDCs (both involve cryptography and may live inside a wallet or credential manager), but they solve a different problem:
Passkeys = for authentication (proving “it’s me” to a service).
VDCs = for presenting claims (proving something about you).
It’s worth noting that passkeys are unique to each website or app, like having a different key for every lock, which makes them privacy-preserving by default. No service can link your passkey use across different sites. By contrast, VDCs require extra safeguards (like advanced cryptography and bulk issuance) to help ensure they don’t become tracking vectors when presented online.
How they work together
Passkeys, federation, and VDCs address different layers of the identity stack, and they’re complementary rather than competitive. In practice, these often work together:
A mortgage application might begin with a government-issued VDC to prove identity. Once the identity is verified and an account is created, a passkey is created for the user for future logins.
An alcohol delivery service might allow sign-up via a federated IdP (e.g. Sign in with Google), authenticate with a passkey at that IdP (so you’re not relying on a password), and then request a government-issued VDC during checkout to verify age.
For a deeper dive, check out my Identiverse 2025 session: Passkeys and Verifiable Digital Credentials: Friends or Foes?
SD-JWT VC, Digital Credentials API, OpenID for Verifiable Presentations, Oh My
The verifiable digital credentials ecosystem is quite expansive and involves many different technical standards developed across many standards development organizations. The standards cover all corners of the ecosystem to support interoperability: identifiers, key management, schemas, credential formats, presentation protocols, issuance protocols, web APIs, and more. Here are a few core standards.
Credential formats
SD-JWT VC is a VDC credential format that supports selective disclosure and is based on the familiar, developer friendly JSON Web Token. SD-JWT VC is developed in the IETF.
The mdoc format, defined in the ISO 18013-5 specification, is primarily used for mDLs and other government-issued identity documents. While the mdoc defines the structure of the credential, ISO 18013-5 also specifies rules for issuance and physical, in-person usage. ISO 18013-7 extends this to remote (online) presentation scenarios, profiling existing specifications like OpenID4VP and the Digital Credentials API to support secure verification over the web.
*Note: ISO specifications are not freely available and must be purchased by all readers.
Protocols
OpenID for Verifiable Credential Issuance (OpenID4VCI) defines how an issuer and a credential manager (wallet) exchange information to issue a VDC. It supports multiple credential formats and can be used on its own or via the Digital Credentials API.
OpenID for Verifiable Presentations (OpenID4VP) defines how a credential manager (wallet) presents a VDC to a verifier. The protocol is credential format agnostic and can be supported by any wallet. OpenID4VP can be used with traditional redirect-based flows or via the Digital Credentials API.
Together, OpenID4VCI and OpenID4VP form the OpenID for Verifiable Credentials family, developed at the OpenID Foundation.
APIs
The W3C Digital Credentials API, an effort driven by Okta in collaboration with some industry partners, is a crucial piece of the VDC ecosystem. It enables secure and user-friendly issuance and presentation of VDCs on the web and in apps. If you’re familiar with the WebAuthn API for passkeys, the Digital Credentials API plays a similar role for VDCs.
Here’s why that matters:
Left visual: VDC presentation flow with “custom scheme” — a user sees a vague prompt to select a wallet and lacks any context about the request.
- Right visual: VDC presentation flow with the Digital Credentials API — the user sees who is requesting the credential and a clear carousel of options to fulfill it—no need for the user to remember where they stored each credential.
To bring some of the pieces together (acronyms and all), we can issue a SD-JWT VC using OID4VCI via the Digital Credentials API, and then request a presentation of the SD-JWT VC using OID4VP via the Digital Credentials API!
How Do I Get a Verifiable Digital Credential?
Before you can present a VDC, you first need to be issued one. There are two common ways this happens:
1. Website or app-initiated issuance
Think of it like saving a boarding pass or concert ticket to your phone. On a website or app, a button prompts you to “Add to Wallet.” For VDCs, clicking this invokes the Digital Credentials API and asks which credential manager (wallet) you’d like to save the credential to. The wallet may then display additional UI to complete the process.
2. Credential manager or wallet-initiated issuance
Sometimes the process starts directly in your credential manager or wallet. This is typical for mDLs in the U.S. or derived credentials like Google ID Pass. The wallet guides you through requesting and saving credentials without needing a separate website or app. Below are examples of the “Add to Wallet” screens in Apple Wallet, Google Wallet, and Samsung Wallet.
Both flows are designed to be simple, secure, and familiar — leveraging the same patterns users already know from digital tickets, loyalty cards, or boarding passes.
How do I trust a VDC?
Trust in VDCs starts with cryptography. When a verifier receives a credential, the first check is its digital signature — confirming it was issued by a trusted authority.
To make that possible, ecosystems rely on trust lists and trust frameworks. A trust list is essentially a curated set of trusted entities and their signing keys — think of it like the root CAs (certificate authorities) in your browser’s trust store. A trust framework defines the rules and policies for how issuers get onto the list, combining both business and technical requirements.
Take mDLs as an example: in the U.S. and Canada, state and provincial DMVs publish their signing keys through the American Association of Motor Vehicle Administrators (AAMVA) Digital Trust Service. These keys — called Issuing Authority Certification Authorities (IACAs) — act as trust anchors. Platforms like Okta and Auth0 can regularly sync with AAMVA to ensure new issuers are recognized automatically.
This model isn’t limited to government IDs. In education, federations already broker trust across universities and countries; in healthcare, finance, and other sectors, industry associations play a similar role. These trust lists and frameworks will be what keeps VDCs interoperable and reliable across domains and borders.
Where do Okta and Auth0 fit in the VDC ecosystem?
Imagine you’re building a new app that needs to verify users’ age, employment, or certification status. On paper, it sounds simple—but in reality, navigating fragmented standards, multiple credential formats, and both digital and physical IDs can be overwhelming.
This is where Okta and Auth0 provide real value. Our platforms already handle key identity functions: minting assertions, consuming them from other identity providers, and providing SDKs and libraries to integrate identity into almost any application.
By offering VDC verification and issuance capabilities, we simplify implementation for developers, abstracting the complexity of a tangled standards stack. This lays a foundation for VDCs to become a seamless, reusable building block for digital identity in the future.
We're building a foundation that makes this new core capability a seamless building block for the future. For more complex or long-term use cases — like professional certifications or Smart Health Cards — our tools help developers, admins, and consumers safely and securely build and support their communities.
To learn more and see VDCs in action, visit oktacredentials.dev.
