Verifiable digital credentials: privacy, interoperability, and trust frameworks

A verifiable digital credential is a structured statement about a subject that an issuer protects cryptographically so another party can check its origin and integrity. A university can attest that a person earned a degree. A licensing authority can attest that a driver may operate particular vehicles. An employer can attest to a role or training record. The important change from a database lookup is that the holder can carry an assertion and present it without asking the issuer to answer every verifier in real time.

That portability is useful, but it does not make identity automatic or trustless. A signature can show that a key signed data. It cannot, by itself, show that the key belongs to a legitimate university, that the claim was based on a sound process, that the credential is still valid, or that a verifier was entitled to request it. Those questions belong to the surrounding trust framework and operating model.

This article describes the standards landscape and the engineering decisions around it as of 20 October 2026. It uses “verifiable credential” for the broad model, while noting where a particular format or profile is still a draft, a recommendation, or a deployment choice. The practical aim is not to select a fashionable protocol. It is to help a technical decision-maker design a system whose claims, privacy properties, interoperability boundaries, and governance can be tested.

The three roles and the credential lifecycle

The W3C Verifiable Credentials Data Model 2.0 describes a three-party ecosystem. The issuer makes claims and creates a credential. The holder receives and controls it, commonly in a wallet. The verifier requests a presentation and checks whether what was presented satisfies its policy. One organisation can occupy more than one role, but the responsibilities should remain distinct in the design.

The issuer is accountable for the claim. It needs an authoritative source or a defined evidence process, a credential schema, signing keys, issuance policy, and a way to change or withdraw status. “Issued by” is not the same as “true in every context”: a credential may attest to a qualification at a date, while the verifier still decides whether that qualification meets its current hiring or licensing rule.

The holder is the party that receives and presents a credential. For a person, the holder may be the subject, but those concepts are not identical. A company could hold a credential about a machine. A guardian or agent could present on behalf of another person under an application-specific policy. The wallet is the holder’s software or device boundary; a wallet is not itself a credential, an issuer, or a universal identity provider.

The verifier is the relying party that makes a decision from a presentation. It should define the smallest claim set needed for that decision, identify acceptable credential types and issuers, check proof and freshness, and record only what its legal and operational purpose requires. A verifier that simply accepts a signed JSON object without checking issuer authority, subject binding, expiry, status, audience, and replay protections has not completed verification.

A typical lifecycle has four phases:

1. Issuance. The issuer authenticates or identifies the subject, evaluates evidence, constructs claims, and signs a credential. The holder’s wallet may supply a public key so that later presentations can prove control of the credential or a device-bound key.
2. Storage and management. The wallet stores the credential and its private keys, presents understandable consent information, and supports deletion, backup, recovery, rotation, and migration. These are product and security functions, not defined by the W3C data model alone.
3. Presentation. The verifier sends a request. The holder and wallet select an appropriate credential and disclose the permitted claims. The wallet produces a presentation bound to the verifier’s transaction, often with a nonce, audience, and proof of possession.
4. Verification and decision. The verifier checks cryptographic validity, credential type and schema, issuer trust, subject or holder binding, time validity, status, request binding, and policy. It then makes a business decision and retains an evidence record proportionate to that decision.

The result is not necessarily a permanent digital identity. It is a portable, verifiable assertion with a defined issuer, subject, scope, lifetime, and policy context.

Open the full-size diagram

Decentralised identifiers: control, resolution, and limits

A decentralised identifier, or DID, is a URI designed to identify a subject and support verification without requiring a single central identifier registry. DID Core defines the common data model for DIDs, DID documents, verification methods, and resolution metadata. A DID method then defines how DIDs are created, resolved, updated, and deactivated in a particular verifiable data registry or other system.

A DID document can publish public keys and service endpoints, subject to the rules of the chosen method. This can be valuable for key discovery and rotation, especially where an issuer wants a stable identifier but does not want every verifier to hard-code a certificate chain. It can also support a holder-controlled identifier for key binding. However, the DID specification intentionally allows different methods with different dependencies, governance, costs, availability, and privacy behavior.

A DID is therefore not a trust decision. Resolving did:example:123 can reveal a key, but not whether the controller is a licensed authority, whether its issuance process is reliable, or whether a presentation is acceptable for a particular transaction. Those answers require a trust registry, a certificate hierarchy, an accreditation rule, a contractual relationship, a government list, a community governance process, or another explicit source of authority.

DIDs can also create correlation. A single public identifier reused across every presentation becomes a tracking handle even if the claims are selective. Holder designs should prefer pairwise or transaction-specific identifiers where the ecosystem permits them, and should document when a stable identifier is necessary. A method that writes every update to a public ledger may expose more operational metadata than a method resolved through an ordinary, access-controlled service. “Decentralised” does not mean “private.”

A useful design question is not “Should we use DIDs?” but “Which parties need to discover which verification keys, through which governance and availability model, with what observer and correlation risks?” For some deployments, a DID method is appropriate. For others, ordinary HTTPS identifiers, X.509 certificates, or a registry-managed key directory can meet the requirement more simply. The W3C model does not require one universal identifier technology.

Credential status is part of the privacy design

A credential can be correctly signed and still be unsuitable to accept. It may have expired, been suspended, been replaced, or been revoked after an error or compromise. Status must therefore be checked according to the issuer’s policy and the verifier’s risk tolerance.

The W3C Bitstring Status List 1.0 defines a compact mechanism for publishing status such as suspension or revocation. The credential points to an entry in a list, and the verifier fetches the signed list to interpret the bit. The mechanism is deliberately more than a storage optimisation. The specification explains that a one-to-one status URL can let a status service correlate a holder, time, and verifier. A shared list can reduce that signal by hiding one credential among many.

Status privacy does not come for free. A verifier that fetches a list directly from the issuer may reveal its network address and the time of use. A holder wallet that prefetches lists may improve availability but needs a safe freshness policy. A privacy proxy or cache can separate the verifier from the issuer, but introduces another service, trust boundary, and outage mode. A deployment should state whether status is checked online, cached for a defined period, stapled into a presentation, or handled through a short credential lifetime. Each option changes the revocation window and the information disclosed.

Status semantics also matter. “Revoked” can mean a credential should never be accepted again. “Suspended” can mean acceptance is temporarily forbidden and later restoration is possible. An issuer may need separate purposes for revocation, suspension, replacement, or refresh. A verifier must not treat an unavailable status endpoint as proof that a credential is valid unless its policy explicitly defines that fail-open behavior and accepts the risk.

Status lists should not be treated as an all-purpose incident-response system. Issuers need key compromise procedures, emergency trust-list updates, credential reissuance, and customer support. Verifiers need monitoring for stale lists, malformed responses, unexpected issuer changes, and status-check abuse. The privacy advantage of a group list is lost if the surrounding logs store a unique credential ID and every lookup event anyway.

Selective disclosure: less data, not automatic anonymity

Selective disclosure lets a holder reveal only some claims from a credential. If a verifier only needs to know that a person is over a threshold age, it should not require a full birth date and address. This is a data-minimisation benefit, but the mechanism and assurance depend on the credential format.

The IETF Selective Disclosure JWT specification defines SD-JWT as a signed JWT containing digests for selectively disclosable claims. The holder sends the signed object plus the disclosures it chooses to reveal. A disclosure contains a random salt and the claim data; the verifier recomputes the digest and checks that it matches the issuer’s signature. The salt makes it harder to guess a hidden value from a public digest. The same specification defines optional key binding: the holder proves control of a private key by signing transaction-specific data in a key-binding JWT.

SD-JWT is not the only approach. Other credential formats can use different proof systems and disclosure mechanisms, including formats designed for mobile documents. The OpenID for Verifiable Credential Issuance 1.0 specification deliberately supports multiple credential formats, including SD-JWT VC, ISO mdoc, and W3C VCDM profiles. Therefore, “we support verifiable credentials” is not enough information for interoperability. An implementer must name the format, proof suite, algorithms, claim vocabulary, transport, and profile.

Selective disclosure has several limits:

• A disclosed combination can identify a person. A rare job title, small town, exact qualification date, and employer may be unique even without a name.
• Stable identifiers, issuer-specific serials, status URLs, or repeated public keys can link presentations.
• A verifier can ask for more than it needs, or infer hidden facts from what the holder chooses not to show.
• A holder can disclose a genuine claim in a misleading context. Presentation binding and verifier policy must establish who requested it, for what transaction, and when.
• A credential can be copied unless it is bound to a key or another possession mechanism. Key binding makes theft harder, but creates key lifecycle and recovery obligations.

The right user experience is a meaningful, transaction-specific consent screen: who is requesting the data, which claims are requested, why they are needed, where they will be sent, and whether the request is optional. “Share all” as the default undermines the technical privacy model.

Privacy and correlation risks in the whole system

The cryptographic envelope is only one part of privacy. A system can use strong signatures and still create a detailed movement log through network requests, QR-code flows, wallet telemetry, issuer callbacks, device identifiers, and verifier databases.

Issuer-to-verifier correlation occurs when the issuer learns where a credential is used. Online status checks, issuer-hosted presentation endpoints, or opaque refresh calls can disclose the verifier and time. The status-list design should be evaluated alongside DNS, TLS termination, CDN, proxy, and application logs. If the issuer does not need to know a presentation occurred, the protocol should not silently send that event back.

Verifier-to-verifier correlation occurs when multiple relying parties can recognise the same holder or credential. A stable subject identifier is the obvious cause, but it is not the only one. The same credential identifier, key, signed timestamp, disclosure digest, or unusual claim set can act as a fingerprint. The IETF privacy discussion distinguishes presentation unlinkability, verifier/verifier unlinkability, and issuer/verifier unlinkability; a design should say which of those it provides and under what assumptions.

Inference and function creep remain possible after minimisation. An age-over-threshold proof avoids sharing a birth date, but a bar, employer, and insurer could still record the fact that the proof was used. A verifier should define retention, access, deletion, onward sharing, and redress before deployment. It should not collect the full credential when a boolean or bounded attribute answers the decision.

A privacy review should map what the issuer, verifier, wallet provider, and network observer can link across transactions, including issuance and status-checking metadata. Test the design with synthetic users whose attributes are common, rare, and deliberately ambiguous.

Interoperability is a stack, not a checkbox

Interoperability fails when teams call different layers “the credential standard.” Separate the stack into five layers:

1. Data model. The W3C VCDM defines concepts such as issuer, credential subject, verifiable credential, and presentation. It is extensible and does not prescribe one universal schema for every domain.
2. Credential format and proof. JSON-LD with a Data Integrity proof, a JWT-based VC, SD-JWT VC, and ISO mdoc have different encoding, cryptographic, and processing rules. They are not interchangeable merely because each can express claims.
3. Transport and exchange protocol. OpenID4VCI defines an OAuth-protected issuance API. OpenID4VP defines a request and response framework for presentations. Neither automatically makes every format, algorithm, or optional parameter interoperable.
4. Query and profile. A verifier needs a machine-readable way to request a type and claims. OpenID4VP 1.0 includes DCQL, the Digital Credentials Query Language, for describing credential and claim requirements. A profile still has to constrain formats, algorithms, response modes, encryption, proof-of-possession, and error handling.
5. Trust and governance. A verifier needs to know which issuers and wallet environments are acceptable, how keys are discovered, how schemas are versioned, and who can suspend an organisation. These are ecosystem rules, not solved by serialisation.

OpenID4VP 1.0 explicitly notes that profiling is required for interoperability. A deployment should publish a conformance profile rather than a vague list of supported standards. It should say, for example, which credential formats are accepted, which cryptographic algorithms are mandatory, which DCQL constraints are supported, which response modes are allowed, how a cross-device flow is initiated, and whether a presentation must contain key binding.

Wallet interoperability also includes user-facing behavior. A verifier may accept two formats but present an unusable request to one wallet. QR codes, deep links, browser hand-off, NFC, Bluetooth, and remote HTTP flows have different phishing and relay risks. Cross-device flows need request-response binding; same-device flows need protection against malicious link interception.

The practical consequence is to test a matrix, not a single happy path: multiple issuers, wallets, and verifiers for every selected profile; issuance, presentation, expiry, status, key rotation, malformed input, and declined consent; and same-device and cross-device flows where both are in scope. Report failures by layer so a schema problem is not misdiagnosed as a wallet problem.

As of the date of this article, the IETF SD-JWT VC document is an Internet-Draft with an expiry shown in the retrieved document, not a final RFC. An implementation may use it, but should pin the draft version, track changes, and avoid presenting draft behavior as a settled internet standard. The same discipline applies to vendor extensions and national profiles.

Trust registries and governance do the work signatures cannot

A trust registry is a governed source that tells participants which entities, keys, roles, or credential types are recognised for a purpose. It can be a signed list, certificate hierarchy, API, DNS-based mechanism, or a combination. Its technical shape matters less than its authority, update rules, availability, and auditability.

A registry should answer concrete questions: who may issue this type, who supervises that issuer, which keys are current, how aliases are handled, how suspensions are published, and which schema versions require a policy review.

The European Digital Identity Wallet Architecture and Reference Framework models governance as lifecycle trust. It describes registries and trusted lists for wallet providers, identity or attestation providers, and relying parties, while noting that trust also rests on authority, policies, oversight, and audits. It is not a universal template or a requirement that every VC ecosystem use X.509; it illustrates the institutional work behind a cross-border system.

Governance should cover at least six policies:

• Admission: evidence and review required before an issuer, verifier, wallet, or trust-list operator participates.
• Scope: the credential types, jurisdictions, populations, and decisions for which an actor is trusted.
• Key lifecycle: generation, custody, rotation, delegation, emergency revocation, and recovery.
• Schema lifecycle: ownership, versioning, localisation, backward compatibility, and deprecation.
• Incident response: who can suspend an issuer, replace compromised keys, notify affected holders, and restore service.
• Accountability: audit evidence, complaint handling, privacy obligations, accessibility, and change control.

A practical implementation and decision framework

A team can reduce avoidable complexity by making the following decisions in order.

1. Start with the decision, not the credential

Write the verifier’s decision in plain language. “Permit entry to a restricted event if the person is at least 18” is different from “record the person’s date of birth and identity document number.” Identify the minimum evidence, the consequence of a false accept, the consequence of a false reject, and the required audit trail.

If a boolean or range proof is sufficient, do not design a credential that forces a full identity profile. If the verifier must contact a current authoritative system for every decision, a signed portable credential may add little value. If the decision can tolerate a bounded freshness window, offline verification or cached status may be viable.

2. Define the subject, holder, and relying party

Decide who the credential is about, who controls it, and who makes the decision. Model delegation, minors, employees acting for companies, shared devices, and lost-device recovery. Decide whether proof of possession is required and what a replacement key means. Do not assume that a wallet account, a device, a DID, and a person are the same entity.

3. Choose a format for the environment

For web-heavy, extensible claim sets, a W3C VCDM profile may fit. For ecosystems already using OAuth and JWT libraries, SD-JWT or SD-JWT VC may fit, subject to the status of the relevant specification and its privacy trade-offs. For mobile identity documents and proximity use cases, ISO mdoc may fit. The choice should follow required disclosure, offline behavior, device binding, canonicalisation, schema control, and verifier tooling—not brand recognition.

4. Choose issuance and presentation protocols separately

Use a defined issuance protocol and a defined presentation protocol. OpenID4VCI can protect issuance with OAuth and carry multiple credential formats, while OpenID4VP handles presentation requests and responses. Record the exact profile and versions. A protocol’s existence does not mean a wallet supports every extension.

5. Specify trust before integration

Publish the registry source, trust anchors, accepted issuer roles, key-discovery method, and failure behavior. Decide whether the verifier can operate when a registry or status service is unavailable. Define cache lifetimes and clock-skew rules. Require an auditable explanation for every accepted issuer and credential type.

6. Design the privacy budget

List every stable or potentially stable value: credential ID, subject ID, issuer ID, public key, status-list index, request ID, transaction ID, device identifier, and network event. Decide which must be stable and which can be pairwise, ephemeral, or omitted. Use selective disclosure, verifier-bound presentations, short lifetimes, and privacy-preserving status retrieval where they reduce the risk. Treat logs and analytics as part of the credential system.

7. Build operations before launch

Prepare key custody, rotation, backup, recovery, status publication, schema migration, support for rejected or expired credentials, and incident response. A wallet that cannot recover safely is a usability risk; a wallet that recovers by copying private keys to an untrusted service is a security risk. Test clock errors, duplicate presentations, replay, rollback, malformed disclosures, compromised issuer keys, and partial network failure.

8. Prove interoperability and user understanding

Run conformance tests and independent cross-implementation tests. Measure not only cryptographic success but understandable consent, accessibility, response time, offline behavior, and failure recovery. A user who cannot tell whether an employer requested an address or a full credential will make a poor privacy decision even if every signature verifies.

Operational and security considerations

Issuer key security is foundational. Keep signing keys in an appropriately protected key-management environment, separate development and production keys, restrict signing authority, and monitor unusual issuance volume. Plan key rotation before the first credential is issued. If a key is compromised, a trust registry update may stop future acceptance but cannot erase copies already presented; status, reissuance, and user communication must cover that gap.

Verifier validation must be layered. First parse safely and reject unexpected algorithms or critical fields. Then verify the signature or proof against an accepted key. Validate issuer and credential type, schema, time claims, subject and holder binding, audience, nonce, and presentation freshness. Check status according to policy. Finally apply the business rule. Do not let a library’s “signature valid” result stand in for the full decision.

Replay protection is essential for online presentations. A verifier-generated nonce, an audience restriction, a short lifetime, and a proof of possession can bind a presentation to one transaction. The W3C VC model recommends that presentations be extremely short-lived and bound to a verifier challenge. The exact fields depend on the securing mechanism and transport, so the deployment profile must be explicit.

Wallet protection includes local user authentication, secure key storage, application isolation, update integrity, screen and notification privacy, and safe export or backup behavior. Device binding can reduce credential theft, but a device-bound key is not a substitute for a recovery process. Organisations should support accessible alternatives for people without a compatible device, with safeguards against turning the alternative into a weaker fraud path.

Availability and denial of service deserve equal attention. A verifier that requires a live trust registry, schema endpoint, status list, and wallet hand-off has several dependencies. Cache signed, non-sensitive metadata where permitted. Monitor freshness rather than simply HTTP success. Decide which failures should pause a high-risk decision and which can be handled with a defined grace period. Never make a privacy-sensitive fallback silently send the full credential to the issuer.

Data governance continues after verification. Store the minimum result needed—possibly “requirement satisfied,” issuer reference, policy version, and transaction time—rather than an entire credential. Encrypt sensitive records, restrict operator access, set retention periods, and separate fraud telemetry from marketing analytics. A technical architecture that minimises disclosure in transit but retains every claim indefinitely has not achieved data minimisation.

Common failure modes

The first is treating a DID or a signature as proof of institutional legitimacy. The fix is an explicit registry and admission policy.

The second is choosing “W3C VC” or “OpenID4VC” without naming the format, proof suite, version, profile, and algorithms. The fix is a conformance document and a cross-implementation test matrix.

The third is calling selective disclosure anonymous. The fix is a correlation analysis that includes identifiers, keys, metadata, status access, logs, and rare claim combinations.

The fourth is making the issuer a mandatory online intermediary for every presentation. That can defeat portability and expose the holder’s activity. The fix is to separate issuance, presentation, status, and refresh paths and justify each callback.

The fifth is designing revocation as an afterthought. A status mechanism must define freshness, privacy, outage handling, suspension semantics, and emergency response before credentials are deployed.

The sixth is putting consent after the technical flow. If the holder sees a generic “continue” button, the wallet cannot provide meaningful control. The request should be understandable before approval, and the verifier should be accountable for asking only what its policy needs.

The final failure is confusing standards compliance with a finished product. Interoperability includes accessibility, recovery, support, migration, governance, and operational evidence. A standards-conforming credential that nobody can safely obtain, present, or replace is not a successful identity service.

Conclusion

Verifiable credentials are best understood as a disciplined exchange of signed claims, not as a universal replacement for identity providers or databases. The issuer supplies an accountable assertion. The holder controls a presentation. The verifier applies a decision policy. Decentralised identifiers can help discover keys and express control, but trust still comes from governance and evidence.

The strongest deployments keep the layers separate: a credential data model, a concrete format, an issuance and presentation protocol, a trust registry, and operational privacy controls. They minimise claims, bind presentations to transactions, make status checking proportionate and privacy-aware, and test the exact profiles that wallets and verifiers will use. That is the route from a cryptographic demonstration to a system that can earn trust without quietly creating a new tracking infrastructure.

References and further reading

• W3C Verifiable Credentials Data Model v2.0
• W3C Decentralized Identifiers (DIDs) v1.0
• W3C Bitstring Status List v1.0
• OpenID for Verifiable Credential Issuance 1.0
• OpenID for Verifiable Presentations 1.0
• IETF Selective Disclosure for JWTs
• IETF SD-JWT-based Verifiable Digital Credentials
• EUDI Wallet Architecture and Reference Framework 2.4.0
• NIST Subscriber Controlled Wallets
• NIST: Getting to Know Verifiable Digital Credential Formats