Verifiable Credentials That Work: Wallets, Issuers, and Flows You Can Ship

Verifiable credentials sound abstract until you try to solve a simple, sticky problem: “Show me you are over 18 without telling me everything about you.” That is the heart of the idea. An issuer vouches for a claim. A holder keeps it in a wallet. A verifier checks it without calling the issuer on every scan. When done right, it is quick, private, and sturdy. When done wrong, it is a maze of QR codes and consent screens people abandon.

This article shows how to build verifiable credential (VC) flows that are practical today. You will learn the minimal standards that interoperate, wallet choices that do not lock you in, and user experience patterns that win trust. We will not ask you to deploy a blockchain. We will focus on tested specs, short feedback loops, and clear privacy promises you can keep.

What Verifiable Credentials Are (and What They Are Not)

Think of a VC as a digitally signed statement. It might say, “This person is a student,” “This company is a supplier,” or “The holder is over 21.” The issuer signs it. The holder stores it locally. The verifier checks the signature and status. That means the verifier does not need to call the issuer every time, and the holder can share only what is needed.

Issuer: A trusted party that signs claims (a university, a bank, a government office, a company HR system).
Holder: A wallet app that keeps credentials and presents them when asked.
Verifier: A service or device that checks if the presented claim is valid, current, and sufficient for access or a decision.

VCs are not the same as passwords, and they are not the same as passkeys. A passkey proves you can access an account. A VC proves a statement about you from someone else. Also, VCs do not require blockchains. Decentralized identifiers (DIDs) can be anchored on the web with did:web or self-contained keys like did:key. Use a ledger only if a trust registry requires it—and most do not.

Common uses you can ship now include:

Age-bound access: scanning a QR at a kiosk to prove “21+” without a birthdate.
Workforce credentials: contractors present proof of safety training or employment status on entry.
Education badges: students show course completion without exposing grades.
Membership and discounts: subscribers prove status to a partner without logging in.

The Minimal Stack for Real Interop

You do not need every option in the toolbox. You need a minimal set that plays well together. Start with these standards:

Data and Identity

W3C VC Data Model 2.0: The structure for credentials and presentations. It does not dictate one signature method. It defines the claims and the wrappers.
DIDs (W3C DID Core): A way to point at public keys for issuers and sometimes holders. did:web is simple and hostname-bound. did:key is self-contained and great for prototypes. You can add other methods later if a program demands them.

Credential Formats

VC-JOSE-COSE: Encodes VCs using familiar JOSE/COSE signature formats (JWT or CWT). This is good for speed and compatibility with OAuth libraries.
Data Integrity (JSON-LD signatures): Adds semantic clarity and supports advanced schemes like BBS+. Good for richer, linked-data ecosystems.
SD-JWT VC: Selective disclosure in a compact JWT form. Lets the holder reveal only required fields with cryptographic proofs.

You do not need to pick one forever. Many wallets and SDKs now support both JOSE/COSE and Data Integrity. Pick the one your verifier ecosystem favors. If you need selective disclosure quickly, SD-JWT VC is a strong choice.

Status and Revocation

Status List 2021: A compressed bitstring list a verifier can cache. The issuer updates it when credentials are revoked or suspended.
Short expirations: Issue credentials with practical lifetimes. Use status for early invalidations. Your verifier should check expiration and status offline first, then refresh the status list on a schedule.

Issuance and Presentation

OpenID for Verifiable Credential Issuance (OpenID4VCI): The OAuth-like flow to deliver a VC to a holder’s wallet. It adds a credential endpoint and uses access tokens.
OpenID for Verifiable Presentations (OpenID4VP): The verifier asks for claims. The wallet crafts a presentation, signs it, and sends it back with proof it came from the holder’s device.

These two flows keep you in familiar territory if you already run OAuth 2.0 and OIDC. You map “scopes” and “claims” to credential types and attributes. You reuse token security you already trust.

Wallets You Can Integrate (and Avoid Lock‑In)

Your users will bring different wallet apps. Some will be OS-native over time. Others will be independent or enterprise-focused. Aim to interoperate, not to control the wallet.

Open wallets and SDKs: Look for wallets that advertise OpenID4VCI and OpenID4VP support, plus SD-JWT VC or VC-JOSE-COSE. Open source options and SDKs from community groups and vendors can speed development.
OpenWallet Foundation: A coalition focused on interoperable wallets and components. Useful if you want a vendor-neutral starting point.
Regional programs: The EU EUDI Wallet is piloting across member states. Even if you are not in Europe, their specs are a guide to scalable patterns, governance, and user flows.

Plan for a world with more than one wallet. Support QR code handshakes and well-known endpoints for discovery. Do not force an app install from your site unless you have a fallback, such as a one-time link that lets the user choose their wallet.

Design Issuance Like an OAuth Dance

Issuance should be clean, quick, and explicit. Borrow from OAuth patterns that users already understand. Here are three workable models:

Link-Based Issuance

Send a signed, single-use link by email or an authenticated web portal. The link opens the wallet, requests authorization, and grants the credential. Use PAR (Pushed Authorization Requests) to avoid leaking parameters in the link. Show the user what they are getting and why.

QR at a Kiosk

The verifier or issuer displays a QR with the offer. The wallet scans it, then establishes a backchannel to receive the credential. This works well for in-person enrollment such as conference badges or employee onboarding. Keep the QR action-agnostic so you can reuse it for both issuance and presentation in different contexts.

In-App Issuance

If you own a mobile app and also issue credentials (for example, a bank or school), integrate a wallet SDK or deep link to a wallet. Bind issuance to a device key so credentials cannot be exported without consent. Keep UI steps under five taps.

Privacy Notes for Issuance

Do not include cross-site tracking IDs in issuance metadata.
Use pairwise subject identifiers so the same holder appears differently to different verifiers.
Rotate keys and avoid static correlation handles in URLs.

Verification That Does Not Leak Data

Verification should ask for the least information needed and no more. You can achieve this with selective disclosure. Two practical choices today are SD-JWT VC and BBS+ (Data Integrity). Both let a wallet reveal specific claims without exposing unrelated fields.

Selective Disclosure Patterns

Attribute proofs: Prove “over 21” from a date of birth without sending the date.
Membership status: Prove “current member” without sharing an email or member ID.
Role-based access: Prove “contractor for Acme Corp” without revealing department or manager.

On the verifier side, always include a nonce and audience in the request. This stops replay attacks and binds the proof to your service. Store the presentation’s metadata only as long as needed. Prefer ephemeral session IDs over user identifiers.

Build a Trust Model You Can Explain

Users and partners will ask: “Why do you trust this issuer?” Have a clear answer that is more than “because we said so.” Rely on one or more of these approaches:

Domain-anchored trust: For business-to-business cases, publishing an issuer’s DID with did:web and a policy page may be enough. Verifiers whitelist known domains.
Federated trust: Use OpenID Federation or program registries to list valid issuers and their metadata. This scales better across many partners.
Public sector registries: Follow regional trust lists (for example, EUDI) where applicable. Align with their conformance profiles so you do not lock yourself out later.

Whichever route you choose, publish a trust policy in plain language. State the criteria for issuers, your revocation process, and how you handle disputes. This is not only good governance; it reduces sales friction.

Design a Wallet UX People Will Actually Use

The best crypto does not matter if people do not get through the flow. Lean into familiar patterns and clear choices:

Friction budget: Keep issuance under one minute. Keep verifications under five seconds.
Readable claims: Show “Over 21 for Acme Bar” instead of JSON fields. Use icons and large text.
Consent screens: Show exactly what will be shared. Allow users to tap “Why is this needed?” for each field.
Fallbacks: If the user has no wallet, offer a temporary QR or a one-time web proof with higher friction and lower trust.
Recovery and multi-device: Support secure backup and restore. Use platform key stores and optional cloud backups with clear warnings.
Guardianship: For minors or dependent users, allow a guardian to co-sign issuance and set limits on sharing.

Security Checklist for Verifiable Credential Systems

The cryptography in the specs is strong. The weak points are often integrations and defaults. Here is a concise checklist:

Key storage: Use platform secure elements (Secure Enclave, StrongBox, or equivalent). Gate presentations behind biometrics or a device PIN.
Holder binding: Bind credentials to a device key. Use proof-of-possession for presentations, not just bearer tokens.
Replay defense: Require nonces and audience values in verify requests.
Status hygiene: Publish status lists with caching headers. Update promptly on revoke and suspend events.
Scope minimization: Ask for the least set of claims. Avoid “give me everything” requests.
Anti-tracking: Rotate identifiers, avoid long-lived correlation IDs, and do not log raw VC payloads unless strictly necessary.
Operational security: Protect issuance endpoints with rate limits, bot checks, and anomaly detection. Separate signing keys in HSMs where possible.

Costs, Operations, and Rollout

You can start small and grow. You need three core services: an issuance API, a verifier endpoint, and a public status list host.

Issuance server: Acts like an OAuth authorization server with extra credential endpoints. Needs database storage for issuance records and key rotation scheduling.
Verifier service: Receives presentations, checks signatures and status, and enforces your policy. Cache metadata and status lists to reduce latency.
Status list hosting: A static resource served from a CDN. Keep it small and compressible for fast updates.

Operationally, expect most support tickets to be about wallet UX, not cryptography. Track time to issue, scan success rates, and drop-offs between screens. Use privacy-preserving analytics—aggregate and strip IP addresses. Avoid session recording on verification screens.

On compliance, design for data minimization. You do not need to store full credential payloads in most cases. Keep hashes and audit records that do not identify people. Publish your retention policies. If you operate in the EU, map your flows to GDPR’s “legal basis” and conduct a DPIA if you scale to sensitive claims.

Case Patterns You Can Launch

Age-Gated Purchase at a Kiosk

A convenience store wants faster age checks. They deploy a verifier app that asks for an “over 21” claim. The wallet responds with a selective disclosure proof from a government-issued ID credential. The verifier never sees a birthdate or address. The check completes in under three seconds. The store keeps a simple log that a valid “over 21” was shown, with a timestamp and a non-linkable token. This reduces queue time and reduces personal data exposure.

Contractor Access at a Job Site

A construction site manages hundreds of contractors. The general contractor issues “employer” and “safety training” credentials through a portal. At the gate, a verifier requests both. If either is revoked (for example, the safety credential expires), the status list shows it. The verifier denies access with a clear message. No one calls HR to check a spreadsheet.

Student Discounts for Partners

A university wants to offer discounts at local stores. It issues a “current student” credential each semester with a short expiry. The student presents it at checkout. The store’s POS asks only for “current student: yes/no” with a signature. The wallet reveals nothing else. The POS never stores student IDs.

Hybrid Offline Events

A conference issues digital badges as VCs with QR codes bound to device keys. Doors have offline verifiers with a cached status list. The scanners work even if the venue Wi-Fi goes down. When the network returns, scanners sync logs and refresh status.

Common Pitfalls (and How to Avoid Them)

Over-engineering with a blockchain: Start with did:web and web trust if you do not need a ledger. Many programs achieve strong trust without one.
One-wallet dependency: Users will show up with different wallets. Support standard protocols so you are not stuck if a vendor changes policy.
Bare bearer tokens: Do not use long-lived bearer tokens for issuance or presentation. Use proof-of-possession and short lifetimes.
No revocation plan: Decide early how you will suspend, revoke, or expire credentials. Publish a status list. Test the path before launch.
Leaky analytics: Do not log full credential payloads or stable identifiers in analytics. Sample flow metrics only.

Your 30‑Day Plan

Week 1: Decide and Design

Pick your first use case. Keep it narrow (for example, “over 21” or “current member”).
Choose formats: SD-JWT VC or VC-JOSE-COSE for speed; add Data Integrity later if needed.
Write your trust policy. Who can issue? How long do credentials last? How do you revoke?

Week 2: Prototype Flows

Stand up an OpenID4VCI-compatible issuance endpoint. Use pushed authorization requests.
Stand up an OpenID4VP verifier endpoint. Implement nonce, audience, and proof-of-possession checks.
Publish a first Status List 2021 file on a CDN. Wire your issuer to update it.

Week 3: Wallet Interop and UX

Test with two different wallets. Run through link-based issuance and QR-based issuance.
Design consent screens with clear, plain text. Add a help link for each claim.
Measure time to issue and time to verify. Fix the slowest step.

Week 4: Security and Pilot

Move signing keys into an HSM or hardware-backed store. Rotate test keys.
Run a limited pilot with real users. Instrument drop-offs and support tickets.
Document your support and recovery flows. Publish your privacy and retention notes.

Answers to Tough Questions You Will Get

How do we avoid tracking people across verifiers?

Use pairwise identifiers, short-lived presentations, and selective disclosure. Ensure each verifier sees a different subject ID for the same person. Limit logs to time and outcome, not identity.

What happens when a phone is lost?

Bind the credential to a device key and allow revocation or re-issuance after re-authenticating the holder through your normal channels. Offer secure backup with clear warnings or a recovery code guarded like a bank token.

Can we go offline?

Yes, for short periods. Cache trust metadata and status lists. Verify signatures locally. Sync status and logs later. Plan for the edge case where you must deny if status is too old.

Do we need selective disclosure from day one?

No. If your first use case only needs a simple “is member” boolean, start there. Add selective disclosure as soon as you ask for sensitive attributes like age or address.

How This Differs from Passkeys and Digital Product Passports

Passkeys help a user log into an account with phishing-resistant cryptography. They do not express claims from a third party. Digital Product Passports track product attributes across supply chains. They are about items, not people. Verifiable credentials can complement both, but they are a distinct tool. Use the right one for each job.

Momentum and What to Watch Next

The VC ecosystem is converging on a short list of practical choices. OpenID4VCI and OpenID4VP are maturing fast. SD-JWT VC and BBS+ are making selective disclosure realistic for mainstream apps. Regional programs like the EUDI Wallet are pushing vendors to interoperate. The next steps to watch are wallet UX refinements, better recovery flows, and clearer governance for issuer lists.

If you make one promise to your users, make it this: We will only ask for what is needed, and we will prove it. The stack above gives you the tools to keep that promise.

Summary:

Use W3C VC Data Model and DIDs to structure and sign claims without calling issuers on every scan.
Pick practical formats: VC-JOSE-COSE or SD-JWT VC now; add Data Integrity and BBS+ as needs grow.
Adopt OpenID4VCI for issuance and OpenID4VP for verification to reuse OAuth skill and tooling.
Publish Status List 2021 for revocation and keep credential lifetimes short.
Support multiple wallets, QR and link flows, and device-bound keys to prevent export and replay.
Design consent and disclosure screens in plain language with minimal data sharing by default.
Build a clear trust policy and align with federations or registries where relevant.
Harden key storage, require nonces and audience binding, and keep analytics privacy-safe.
Start with a narrow use case, ship in 30 days, measure, and iterate.

Verifiable Credentials That Work: Wallets, Issuers, and Flows You Can Ship

What Verifiable Credentials Are (and What They Are Not)