This document describes a threat model for the Verifiable Credentials Data Model specification. It identifies and analyzes security and privacy threats specific to ecosystems in which [=issuers=] issue [=verifiable credentials=] to [=holders=], who in turn present [=verifiable presentations=] to [=verifiers=].

This threat model is a work in progress. It is published alongside the Verifiable Credentials Data Model specification to inform implementers and ecosystem designers of the security and privacy considerations relevant to deployments of the specification. Feedback and proposed additions are welcome via the issue tracker.

Introduction

Threat modeling is a vital part of specification development. This document provides a threat model for the Verifiable Credentials Data Model specification, which defines a data model for expressing cryptographically verifiable claims made by an [=issuer=] about one or more [=subjects=].

This threat model follows the methodology described in the W3C Threat Modeling Guide and classifies threats using the STRIDE taxonomy. Threats are grouped into five categories:

Each threat in this model is examined in isolation. However, good, scalable solutions always require balance, and almost any decision comes with trade offs. Readers are expected to take all relevant threats, advice, and mitigations into consideration to balance them appropriately to optimize for their solution's widest target audience.

Description

The Verifiable Credentials Data Model defines how an [=issuer=] makes cryptographically verifiable claims about one or more [=subjects=]. For this threat model, we consider a minimal instantiation of a verifiable credentials ecosystem consisting of three roles: the [=E1|Issuer=] (E1), who establishes confidence in a [=subject=] and issues a [=verifiable credential=]; the [=E2|Holder=] (E2), who stores [=verifiable credentials=] and generates [=verifiable presentations=] from them; and the [=E3|Verifier=] (E3), who receives a [=verifiable presentation=], verifies it, checks the status of any [=verifiable credentials=] it contains, and validates the result against its own policy.

The core property the specification provides is that a [=E3|verifier=] receiving a [=verifiable presentation=] can determine, in an automated and cryptographically verifiable way, whether the [=verifiable credentials=] it contains are authentic, unrevoked, and fit for the verifier's purpose. This holds even when a credential arrives long after it was issued, over untrusted networks, and through the [=holder=], and it requires no direct contact between the [=verifier=] and the [=issuer=] beyond retrieving public status information.

Note: We do NOT model potential attackers as first-class elements, as over-characterizing attackers can lead to analysis bias that is better avoided.

Data Flow Diagram for the Verifiable Credentials Ecosystem

The data flow diagram below illustrates the key elements and data flows in a minimal verifiable credentials ecosystem. It shows the [=E1|Issuer=] (E1) establishing confidence in the [=E2|Holder=] (E2) as a [=subject=] ([=F1|F1=]), assembling and issuing a [=verifiable credential=] that is delivered to the holder ([=F2|F2=]) and placed in [=S2|Holder Storage=] (S2). The holder later generates a [=verifiable presentation=] and exchanges it with the [=E3|Verifier=] (E3) ([=F3|F3=]), whose verification pipeline verifies the presentation, checks credential status against the issuer's [=S1|Status List Storage=] (S1) ([=F4|F4=]), and validates the result.

Data flow diagram showing three dashed system boundaries: the Issuer System (C1) containing the Establish Confidence (P1), Assemble Verifiable Credential (P2), Issue Verifiable Credential (P3), Publish Status List (P4), and Update Status List (P5) processes and Status List Storage (S1); the Holder System (C2) containing the Store Verifiable Credential (P6), Engage in Workflow (P7), and Generate Presentation (P8) processes and Holder Storage (S2); and the Verifier System (C3) containing the Engage in Workflow (P9), Verify Presentation (P10), Verify Credential Status (P11), and Validate Credentials (P12) processes. Confidence is established from the Holder System to the Issuer System via flow F1, a verifiable credential is delivered from the Issuer System to the Holder System via flow F2, a verifiable presentation is exchanged from the Holder System to the Verifier System via flow F3, and the Verifier System checks credential status against the Issuer System's Status List Storage via flow F4.

The following notation is used in the diagram description and dictionary:

Dictionary

The dictionary entries below are starting-point definitions to be reviewed and expanded. Each entry should describe the element in enough detail to support the threat analysis that references it.

E1 Issuer An entity that establishes confidence in a [=subject=], assembles a [=verifiable credential=] expressing claims about that subject, issues it, and publishes and maintains the status information used to determine whether the credential remains valid.
E2 Holder A person or organization that receives [=verifiable credentials=], stores them, and generates [=verifiable presentations=] to share selected claims with [=verifiers=]. The holder is typically, though not always, the [=subject=] of the credentials it holds.
E3 Verifier An entity that receives a [=verifiable presentation=] and must determine whether to rely on the [=verifiable credentials=] it contains, by verifying the presentation, checking credential status, and validating the result against its own policy.
P1 Establish Confidence The process by which an issuer gains sufficient confidence in the identity or attributes of a [=subject=] before issuing a [=verifiable credential=].
P2 Assemble Verifiable Credential The process by which an issuer composes the claims, metadata, and status information of a [=verifiable credential=] prior to securing it.
P3 Issue Verifiable Credential The process by which an issuer secures the assembled credential and delivers it to the holder.
P4 Publish Status List The process by which an issuer publishes the status information used by verifiers to determine whether a credential has been revoked or suspended.
P5 Update Status List The process by which an issuer updates the published status information, for example to revoke or suspend a previously issued credential.
P6 Store Verifiable Credential The process by which a holder places a received [=verifiable credential=] into [=S2|Holder Storage=] and retrieves it later.
P7 Engage in Workflow (Holder) The process by which a holder participates in an interaction workflow, including responding to requests and consenting to share credentials.
P8 Generate Presentation The process by which a holder produces a [=verifiable presentation=] from one or more stored [=verifiable credentials=].
P9 Engage in Workflow (Verifier) The process by which a verifier participates in an interaction workflow, including requesting and receiving a [=verifiable presentation=].
P10 Verify Presentation The process by which a verifier cryptographically checks a received [=verifiable presentation=] and the [=verifiable credentials=] it contains.
P11 Verify Credential Status The process by which a verifier checks the status of a [=verifiable credential=] against the issuer's published status information in [=S1|Status List Storage=].
P12 Validate Credential(s) The process by which a verifier evaluates the verified, unrevoked credential(s) against its own business policy to decide whether to accept them.
F1 Establish Confidence in Subject The data flow by which the holder (as [=subject=]) provides the issuer with the information it needs to establish confidence prior to issuance. This flow crosses the trust boundary between the holder's authority and the issuer's authority.
F2 Deliver Verifiable Credential The data flow by which a [=verifiable credential=] travels from the [=C1|issuer system=] to the [=C2|holder system=].
F3 Exchange Presentation The data flow by which a holder delivers a [=verifiable presentation=] to the [=C3|verifier system=]. This flow crosses the trust boundary between the holder's authority and the verifier's authority.
F4 Check Credential Status The data flow by which the verifier retrieves published status information from the issuer's [=S1|Status List Storage=]. This flow crosses the trust boundary between the verifier's authority and the issuer's authority.
S1 Status List Storage The storage within the [=C1|issuer system=] holding the published status information for issued credentials, retrievable by verifiers.
S2 Holder Storage The persistent storage within the [=C2|holder system=] where [=verifiable credentials=] are kept, typically the storage of a digital wallet application.
C1 Issuer System The system boundary, typically a server or service operated by or for the issuer, within which the issuer's processes run and [=S1|Status List Storage=] resides.
C2 Holder System The system boundary, typically a mobile or desktop digital wallet application, within which the holder's processes run and [=S2|Holder Storage=] resides.
C3 Verifier System The system boundary, typically an automated verification service, within which the verifier's processes run and its trust and policy decisions are configured.

Stakeholders

E1 Issuer

An issuer is an entity that makes cryptographically verifiable claims about one or more [=subjects=] by issuing [=verifiable credentials=]. Issuers range from universities, government agencies, and employers to automated services.

The issuer's primary goals are that only credentials it intends to issue carry its authority, that it can revoke or suspend credentials it has issued, and that the credentials it issues remain verifiable by the parties intended to rely on them.

E2 Holder

A holder is a person or organization that receives [=verifiable credentials=] and presents them to verifiers. The holder is typically the [=subject=] of the credentials it holds and stores them in a digital wallet.

The holder's primary goal is that the presentations they make are accepted by verifiers. Holders also have a strong interest in privacy: they do not want the act of presenting credentials to enable issuers, verifiers, or third parties to track their activities across contexts, and they want to disclose no more information than each interaction requires.

E3 Verifier

A verifier is an entity that receives [=verifiable presentations=] and must decide whether to rely on them. Verifiers range from automated services processing high volumes of presentations to individuals checking a single credential.

The verifier's primary goal is to accept only credentials that are authentic, unrevoked, and used for the purpose and in the context the issuer intended. Verifiers also have a strong interest in availability: verification must complete within their operational time budgets even when processing untrusted, and potentially malicious, input.

Threats

Contributing

This threat model is maintained alongside the Verifiable Credentials Data Model specification. Feedback, bug reports, and proposed additions are welcome via the issue tracker.

Adding a Threat

To add a new threat to the model, provide the following components:

  1. A short, descriptive name
  2. A unique ID (letter T followed by an integer, e.g., T1)
  3. A description of the threat with enough detail for readers to understand its scope
  4. One or more responses, each with a name, unique ID (letter R followed by an integer), response type (Eliminate, Reduce, Transfer, or Accept), and description
  5. A list of affected DFD elements drawn from the dictionary above
  6. The threat taxonomy used (e.g., STRIDE) and the threat class within that taxonomy

Create a YAML file following the pattern of the Data Integrity threat model's threat files, then register it in threats/outline.yaml by adding its filename to the files list and its threat ID to the appropriate category in the categories list. No changes to index.html are required.