Threat Model for Decentralized Credentials

1. Introduction

This threat model covers decentralized credentials for people, especially high-assurance credentials issued by governments. It starts from credential flows, with particular attention to credential presentation.

Note: Identity & the Web uses Verifiable Digital Credentials as a broader term for credential ecosystems whose credentials can be digitally verified [IDENTITY-WEB-IMPACT]. This threat model uses decentralized credentials and verifiable digital credentials as synonyms for the scoped model.

Those credentials are part of the identity ecosystem described in the W3C Team report Identity & the Web [IDENTITY-WEB-IMPACT]. That report identifies five layers: Layer 5, Trust Frameworks and Ecosystems; Layer 4, Applications, Wallets, Products; Layer 3, Credential Layer; Layer 2, Agent Frameworks and Infrastructure; and Layer 1, Identifiers and Namespaces. The current threat model focuses on Layer 3, the Credential Layer. The other layers remain in scope when they affect threats, responses, assumptions, or remaining threats.

Government-issued verifiable credentials sit inside a socio-technical system: technical components, people, organizations, processes, incentives, and rules all interact. A credential flow can satisfy a security or privacy property in a specific interaction, while still causing broader harms when the system is used, misused, abused, deployed, or governed in harmful ways. For that reason, this threat model includes socio-technical threats in addition to the usual security and privacy threats. This aligns with the need identified in the joint work on rights-respecting digital credentials: to assess societal and human-rights impacts, develop threat and harms models, and identify mitigations for high-assurance credential systems.

The immediate trigger was W3C discussion about adding the Digital Credentials API [DIGITAL-CREDENTIALS] to the Federated Identity Working Group. Digital Credentials defines an API enabling user agents to mediate communication between a website that requests evidence and holder software, such as a wallet, which holds the evidence. The credential-flow model used here also applies to verifiable credentials across architectures, profiles, deployment patterns, and governance contexts. It is broader than wallet-specific work such as Protecting Digital Identity Wallet: A Threat Model in the Age of eIDAS 2.0 [PROTECTING-DIGITAL-IDENTITY-WALLET], which focuses on the European Digital Identity Wallet context.

The result is intended as input for later architecture, profile, implementation, and deployment work.

1.1. Terminology

Terminology comes from Identity & the Web [IDENTITY-WEB-IMPACT] and Verifiable Credentials Data Model v2.0 [VC-DATA-MODEL-2.0]. The short definitions below are included for readability. The cited documents remain the source definitions.

identity

The characteristics by which a person, organization, device, service, website, or other entity can be recognized in a given context. Identity is broader than a login name, account, credential, or identifier.

identifier

A specific piece of information used to recognize or refer to an entity. An identifier can refer to an identity, but it is not the identity itself.

claim

An assertion made about a subject. Claims can describe attributes, properties, qualifications, status, or other facts asserted by an issuer.

credential

A set of one or more claims made by an issuer. A credential can include metadata, such as the issuer, validity period, verification material, or status information.

verifiable credential

A tamper-evident credential whose authorship can be cryptographically verified. Verifiability does not mean that the underlying claims are true.

presentation

Data derived from one or more verifiable credentials and shared with a specific verifier.

verifiable presentation

A tamper-evident presentation whose authorship can be checked through cryptographic verification. A verifiable presentation can include credentials, selected claims, or data synthesized from credentials, depending on the credential format and protocol.

subject

The person, organization, device, service, or other thing about which claims are made.

holder

The role that possesses one or more verifiable credentials and can generate verifiable presentations from them. A holder is often, but not always, the subject of the credentials they hold.

issuer

The role that asserts claims about one or more subjects, creates a verifiable credential from those claims, and transmits it to a holder.

verifier

The role that receives one or more verifiable credentials, optionally inside a verifiable presentation, for processing before relying on the claims.

verifiable data registry

A role a system can perform by mediating identifiers, verification material, schemas, status information, revocation registries, or other data needed to verify credentials.

credential repository

In this threat model, the credential repository is modeled as DS-01, Wallet Storage. The broader VCDM definition also includes storage vaults, file systems, wallets, and other software that stores credentials or protects access to them.

verification

The evaluation of whether a verifiable credential or verifiable presentation is authentic and current, including checks on conformance, securing mechanisms, and status information where present.

validation

The verifier’s evaluation of whether claims from a specific issuer satisfy the verifier’s policy or business requirements for a particular use.

1.2. Related Work

• Preventing Abuse of Digital Credentials

• User considerations for credential presentation on the Web

• Building Consensus on the Role of Real World Identities on the Web

• Protecting Digital Identity Wallet: A Threat Model in the Age of eIDAS 2.0

• Secure and Reliable Digital Wallets: A Threat Model for Secure Storage in eIDAS 2.0 [THREAT-MODEL-SECURE-STORAGE]

• A Threat Model for the W3C Digital Credentials API: An Initial Analysis [DC-API-THREAT-MODEL]

1.3. Methodology

The method is Shostack’s Four Question Frame for Threat Modeling [SHOSTACK-FOUR-QUESTION-FRAME]. The frame keeps the work tied to the system under analysis instead of starting from a fixed checklist of attacks. The work also follows the Threat Modeling Manifesto [THREAT-MODELING-MANIFESTO] as a set of values and principles: collaborative, iterative, practical, and focused on finding and fixing design issues rather than treating threat modeling as a compliance checkbox.

The first question, What are we working on?, anchors the analysis in the credential architecture: actors, credentials, data flows, stores, trust boundaries, and assumptions.

The second question, What can go wrong?, uses those flows and boundaries to find threats, threat actors, attacks, security and privacy failures, and pathways that can lead to socio-technical harms.

The third question, What are we going to do about it?, records mitigations, responsibility boundaries, assumptions, transfers, acceptances, and remaining threats.

The final question, Did we do a good enough job?, checks whether the model is specific, traceable, and ready to guide the next round of design, review, or implementation work.

The external frameworks and prompt sets listed below are prompts, not completeness criteria.

• Ben Laurie’s privacy properties from Selective Disclosure [BEN-LAURIE-SELECTIVE-DISCLOSURE]

• LINDDUN

• RFC 6973

• RFC 3552

• STRIDE

• OSSTMM v3

• Microsoft’s Types of Harm, and the NDIS Harms framework adapted from it in Enhancing National Digital Identity Systems [NDIS-HARMS]

OSSTMM is used here as a control-oriented key for the "what can go wrong?" question in the four-question framework. For that check, the channel is COMSEC Data Networks and the vector is Internet/Web; other credential systems may need a different channel or vector, such as Wireless.

Here, OSSTMM asks whether a control is absent, fails in this context, or moves responsibility to another actor. Privacy is included in that check when it changes actors, flows, or trust boundaries.

2. What are we working on?

This model starts from the credential layer described in the introduction and uses the ecosystem overview in Verifiable Credentials Data Model v2.0 [VC-DATA-MODEL-2.0] as its baseline. The system under analysis is defined without assuming a single credential format, wallet architecture, transport protocol, governance model, or presentation ceremony.

2.1. Scenario

The scenario modeled here is the baseline credential-layer flow. The baseline ecosystem roles come from Verifiable Credentials Data Model v2.0 [VC-DATA-MODEL-2.0]:

• Subject: the person, organization, device, service, or other thing described by the claims.

• Holder: possesses credentials and can generate presentations. A Holder is often, but not always, the Subject of the credential.

• Issuer: asserts claims, creates a credential from those claims, and transmits the credential to a Holder.

• Verifier: receives credentials, optionally inside a presentation, and processes them before relying on the claims.

• Verifiable Data Registry (VDR): provides identifiers, verification material, schemas, revocation registries, or other data needed to verify credentials.

The scenario uses the common case in which the Holder is also the Subject. This is a baseline modeling assumption. For this DFD, the scenario also assumes that the person acting as the Holder interacts with their Wallet / Credential App through the browser or user agent. If the Holder and Subject are different, if the Holder interacts with wallet software outside browser mediation, or if a credential can be delegated, the deployment model should add the Subject, delegated Holder, direct wallet interaction, and any authority-granting or revocation process as separate ecosystem roles when those roles affect issuance, presentation, recovery, revocation, or reliance decisions.

The trust relationships among these ecosystem roles are part of the source specification. Verifiable Credentials Data Model v2.0 [VC-DATA-MODEL-2.0] includes a Software Trust Boundaries section, which describes trust relationships among ecosystem roles and the software that operates on their behalf. For that reason, this scenario shows trust boundaries and treats Holder, Issuer, Verifier, and VDR as separate control points unless a deployment explicitly combines them.

Because one organization can play several roles, the scenario keeps the roles separate when that separation helps expose data flows, trust boundaries, or responsibility boundaries.

This model treats ecosystem roles separately from the software that acts on their behalf. Software often exercises the authority of a role: wallets and browsers can act for Holders, issuer systems can act for Issuers, verifier websites can act for Verifiers, and status or registry services can act for a VDR. This document uses agent for software that acts on behalf of a role. The role whose authority the agent exercises is the principal. When an agent accepts input or direction from one actor while exercising another actor’s authority, confused-deputy threats should be considered.

In the data-flow diagram, an agent is modeled as a process because it performs work on credential-layer data under a principal’s authority. External entities remain outside the software trust boundaries. Processes and data stores that exercise or hold delegated authority are inside those boundaries. The Holder-side boundary separates browser or user-agent mediation from Wallet / Credential App behavior because the Digital Credentials API treats those as distinct parts of a browser-mediated flow [DIGITAL-CREDENTIALS].

This model stops at the credential and presentation layer. A Verifier may use a presentation result to grant service access, sell a ticket, issue a follow-on credential, or make another decision. Those downstream decisions are deployment context unless later analysis brings a specific decision path into scope.

2.2. Diagram

The diagram shows the baseline credential-layer flow and the trust boundaries used by this threat model.

These boundaries model software, storage, or service control points that operate for ecosystem roles. They do not assert that each boundary corresponds to a separate deployed component in every implementation.

Note: The DFD uses square nodes for external entities, rounded rectangles for processes, drum shapes for data stores, and arrows for data flows. Dotted boundaries mark changes in control, trust, authority, privilege, responsibility, or assumptions.

2.3. Dictionary

The dictionary assigns each diagram item a stable identifier.

2.4. Assets

The main assets are credentials and lifecycle data: claims, presentations, proofs, identifiers, keys, verification material, status information, verifier policy decisions, and metadata.

The main properties are Verifiability, Minimization, and Unlinkability. Ben Laurie’s Selective Disclosure [BEN-LAURIE-SELECTIVE-DISCLOSURE] uses those properties to describe privacy-preserving assertions. Verifiability matters to every role that relies on a credential or presentation. Minimization and Unlinkability primarily protect the Holder and other affected people, especially when credentials concern government-issued identity or high-assurance attributes.

3. What can go wrong?

With the assets and properties in view, the next step is to ask who can affect them, what those actors may try to do, and which security, privacy, and socio-technical concerns need testing.

3.1. Threat Actors and Deputies

Protecting the Holder is a central concern. Each role, each software deputy that acts for a role, and external observers are possible sources of threats. A role can threaten another role, itself, or the people represented by credentials.

Software deputies in this model include wallets, browsers, issuer software, verifier websites, Wallet Storage, status services, and systems that operate or access registry / status data. The role behind the deputy does not need to be malicious for something to go wrong. The deputy might leak data, change a presentation, collect excess telemetry, hide relevant choices from a Holder, or use more authority than the role intended.

External observers and active adversaries can include marketers, data brokers, stalkers, identity thieves, OSINT investigators, and government or law-enforcement actors, depending on the deployment. The model also treats collusion as in scope, including Verifiers that share presentation records or an Issuer and Verifier that link Holder activity.

3.2. Abuse Stories

These abuse stories are starting points for threat elicitation, not a complete set of findings:

• A Verifier asks for, stores, or reuses more credential data than the transaction needs.

• A Holder presents a credential or discloses a claim outside their authority.

• An Issuer or issuer deputy uses issuance or status checking to track Holders.

• A browser, Wallet / Credential App, or another component acting for the Holder leaks credential data, narrows Holder choice, or steers which credential is presented.

• An external observer correlates issuance, presentation, verification, or status-checking activity.

• Verifiers share presentation records, or an Issuer and Verifier link Holder activity.

3.3. Threats

The threat table records findings from the data-flow diagrams, trust boundaries, assets, starter abuse stories, and socio-technical pathway analysis. Elicitation used Ben’s privacy properties, LINDDUN, RFC 6973, RFC 3552, STRIDE, OSSTMM, NDIS Harms, and Microsoft Responsible Innovation harms as prompts, not as separate threat models or completeness criteria. The Elicitation framework column records the framework family used to find the threat. The Prompt column records the specific prompt or subcategory used inside that framework, and includes the closest STRIDE prompt when that mapping clarifies the row.

When multiple prompts expose the same underlying condition, the table consolidates them into one threat row and preserves the prompts in the Elicitation framework and Prompt columns.

3.4. Harms

The threat table above is the main inventory of identified threats. The material in this section was elicited by starting from harm prompts and reasoning backward to what can go wrong. It keeps that material visible without treating each harm prompt as a separate threat, risk, or response.

It records how harm prompts were used to identify affected people, entry conditions, credential capabilities, deployment or governance assumptions, and connected threat pathways. Some pathways have already been normalized into threat IDs. Other material still needs deployment-specific analysis before it becomes a separate threat, response, assumption, transfer, acceptance, or remaining threat.

These results come from threat modeling workshops on decentralized identity in national digital identity systems. The framework used for this section is NDIS Harms, derived from Enhancing National Digital Identity Systems [NDIS-HARMS]. The activity combined NDIS Harms cards with LEGO SERIOUS PLAY.

A threat describes what can go wrong and the pathway through which it can happen. A harm is an adverse impact that may result, including impact on people and society. This section uses harm categories as prompts: it starts from possible impacts, then asks which credential capability, use, misuse, abuse, deployment condition, governance condition, or assumption could create a pathway to that impact. That keeps the output as threat-modeling material rather than a harm taxonomy.

The connected pathways do not replace the individual threats in the previous table. They show how local design choices, software deputies, institutional choices, and participation conditions can connect individual threats and produce broader harms for Holders, Subjects, non-users, and other affected groups. Where the pathway analysis exposed a discrete "what can go wrong" condition, that condition is also normalized into the threat table, mainly in the T-038 through T-049 range. The related threat and response identifiers are initial links; they can be refined as the model becomes more deployment-specific.

The workshop activity also produced harm prompts and individual threat material for later review. Some entries are already represented by the pathway table or by the threat table above. Others need a clearer pathway before they should become separate threat IDs.

4. What are we going to do about it?

The response table maps candidate responses to the threat, pathway, and harm identifiers in the previous section. It is intentionally not deduplicated. Some rows overlap because they came from different prompts or address the same threat or pathway at different layers.

5. Did we do a good enough job?

For this draft, the threat model should let readers:

• understand the scope, actors, assets, flows, and trust boundaries of decentralized credentials;

• reason about threats introduced by trust boundaries, including changes in control, authority, responsibility, privilege, or assumptions, even when the affected elements are recorded as concrete entities, processes, data stores, or flows;

• identify security, privacy, and socio-technical concerns from multiple analysis prompts;

• distinguish threats from harms, vulnerabilities, responses, assumptions, and remaining threats;

• see where candidate responses are technical, human or operational, or governance- and ecosystem-level;

• identify which questions need a more concrete architecture, profile, or implementation before they can be answered;

• identify missing stakeholders or affected groups that should be added before the next review pass.

The next pass should refine the existing threat-response mappings. For each threat, it should make the affected stakeholders, affected DFD elements, responses, response owners, assumptions, transfers, acceptances, and remaining threats explicit enough to review.

The threat model also records how formal review material was handled. Formal Objection Source Mapping records the source concerns from the Federated Identity Working Group charter review and the normalized threat-model treatment.

Appendix: Formal Objection Source Mapping

This appendix records how concerns from the Formal Objection to adding the Digital Credentials API to the Federated Identity Working Group charter [FORMAL-OBJECTION-FEDID-DC] and the related W3C Team report [TEAM-REPORT-FEDID-FO] were treated in this threat model. It also takes into account the W3C Council Report on the Formal Objection Against Federated Identity Working Group Charter — Adding Digital Credentials API [COUNCIL-REPORT-FEDID-DC], which overruled the objection while recommending that the Working Group take the concerns into consideration. The source material is used as elicitation input. The normalized threats, pathways, and responses are the model’s current treatment of that input.