Verifiable Credentials Data Model Threat Model

Abstract

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.

Target Threats

Credential Content Tampering security
Identity Proofing Failure at Issuance security

Implementation Threats

Code Injection via Credential Content security
Signature-Based Correlation privacy
Correlation via Status and Revocation Lookup privacy
Signing Key Compromise and Mismanagement security
Tampering with Unprotected External Resources security
Presentation Exchange Attacks (MITM, Replay, and Spoofing) security
Inappropriate or Out-of-Context Credential Use security

Deployment Threats

Identifier-Based Correlation privacy
Untrustworthy User-Agent Software privacy
Excessive Data Disclosure privacy
Metadata-Based Correlation privacy
Bearer Credential Reuse and Correlation privacy
Correlation via Patterns of Use privacy
Disclosure to a Malicious or Deceptive Verifier privacy
Data Theft and Credential Honeypots security
Issuer-Side Correlation and Privacy Subversion privacy
Inappropriate Validity Periods security
Device Theft and Impersonation security

External Threats

Storage Provider Data Mining and Compelled Disclosure privacy
Device Tracking and Fingerprinting privacy
Credential and Data Aggregation privacy
Unauthorized Post-Presentation Use of Data privacy

Dependency Threats

Cryptographic Suite Obsolescence security

Target Threats

[Threat List]

An attacker with access to a verifiable credential after it is issued modifies its contents to alter the claims it expresses. The attacker can act while the credential is being delivered to the holder, while it is at rest in holder storage, or while it is being exchanged with a verifier inside a verifiable presentation. For example, an attacker might change the subject of a degree credential, alter a date of birth used for age verification, or add statements the issuer did not make. In a related variant, the attacker removes the securing mechanism from the credential in hopes that a downstream verify process will consume it without detecting that its integrity protection is absent. Allowing a verifier to detect modification of credential content is a capability the Verifiable Credentials Data Model is designed to provide.

R1. Securing Mechanism Verification (Reduce)

The Verify Presentation process cryptographically verifies a securing mechanism (such as Verifiable Credential Data Integrity 1.0 or Securing Verifiable Credentials using JOSE and COSE) protecting each verifiable credential against the issuer's public verification material. Any modification of the protected claims causes verification to fail. Verification detects tampering; it does not prevent it. A verifier that does not verify the securing mechanism, or that acts on credentials whose proofs it has not checked, gains no protection from this response.

R2. Reject Credentials Lacking Required Proofs (Reduce)

Proof stripping cannot be detected by cryptographic means, because a credential with no proof contains nothing to verify. Verifiers address this through policy. They reject any verifiable credential that does not carry the securing mechanism their policy requires, and they treat unsecured credentials as unauthenticated statements made by the presenting holder, rather than as authenticated statements made by the issuer. The specification allows credentials to be created without proofs, which are useful for intermediate storage or self-asserted information; such credentials are not verifiable because their authorship is unknown or cannot be trusted, and a verifier does not rely on them as though an issuer had authored them.

Affected Components: P3: Issue Verifiable Credential, F2: Deliver Verifiable Credential, S2: Holder Storage, F3: Exchange Presentation, P10: Verify Presentation, C2: Holder System

Threat Taxonomy: STRIDE (Tampering)

[Threat List]

Before issuing a verifiable credential, an issuer carries out a establish confidence process to gain confidence in the identity or attributes of a subject. When that process fails, the issuer can identify the individual incorrectly and issue a credential to the wrong person. An attacker who presents another person's information during establish confidence in subject, or who otherwise defeats weak proofing, receives an authentic credential that names the victim as its subject. Because the credential is genuinely issued and correctly secured, every downstream verification succeeds, and the attacker can use it to impersonate the victim, effectively enlisting the issuer as an unwitting participant in identity theft. The strength of the proofing process is a choice the issuer makes and is not something the data model can enforce on its own.

R1. Rigorous Identity Proofing (Reduce)

Issuers establish confidence in a subject using an identity-proofing process whose rigor matches the risk of the credential being issued, following an established framework such as the Identity Assurance Levels (IAL) defined in [NIST-SP-800-63A]. Higher assurance levels call for stronger evidence and verification of the claimed identity, reducing the chance that a credential is issued to someone other than the person it names.

R2. Match Assurance Level to Credential Risk (Reduce)

Issuers select the identity assurance level appropriate to how a credential will be relied upon, and verifiers take the assurance level of the establish confidence process into account when they validate a credential, rather than treating a successful cryptographic verification as evidence that the subject was correctly identified at issuance.

Affected Components: E1: Issuer, E2: Holder, P1: Establish Confidence, F1: Establish Confidence in Subject, P2: Assemble Verifiable Credential, P3: Issue Verifiable Credential

Threat Taxonomy: STRIDE (Spoofing)

Implementation Threats

[Threat List]

A verifiable credential can carry values that contain injectable code, such as markup in an rdf:HTML value or content in a scripting language, added during the data production process. A consumer that processes such content without adequate handling can be made to execute the injected code. For example, a script tag can run when the credential is displayed. The consumer is most often a verifier rendering a credential during Verify Presentation or Validate Credential(s). It can also be a holder's wallet displaying a credential retrieved from holder storage. A valid securing mechanism protects the integrity of the embedded content but does not indicate whether the content is safe, so malicious code can arrive inside a well-formed, verified credential. The specification leaves the choice of mitigation to implementers.

R1. Avoid Embedding Executable Markup (Eliminate)

Authors of verifiable credentials avoid including HTML or other markup languages that can carry executable scripts unless a specific use case requires it. Language and base direction are expressed through the data model's own mechanisms rather than through embedded markup. When no executable content is present, the injection vector is removed at the source.

R2. Sandboxed Rendering and Output Encoding (Reduce)

When markup that can contain executable content must be processed, implementers analyze how an attacker could use it to mount an injection attack against the consumer, and deploy mitigations before processing the content. Examples include rendering untrusted content in a sandbox with no network access, applying context-appropriate output encoding, and treating all credential-delivered content as untrusted whether or not its securing mechanism was successfully verified.

Affected Components: F2: Deliver Verifiable Credential, S2: Holder Storage, P10: Verify Presentation, P12: Validate Credential(s), C3: Verifier System

Threat Taxonomy: STRIDE (Elevation of Privilege)

[Threat List]

The values that make up a securing mechanism on a verifiable credential can themselves be correlating, independent of the claims they protect. When the binary value of a digital signature, the timestamp associated with its creation, or cryptographic material such as a public key identifier remains the same across multiple sessions or domains, a verifier that receives the credential more than once, or two verifiers acting in collusion, can link those presentations to the same holder even when no correlating identifier appears in the payload. This threat depends on the securing mechanism an issuer chooses when it generates and secures a credential.

R1. Unlinkable Disclosure (Reduce)

When strong anti-correlation properties are required, issuers produce verifiable credentials whose signature values and metadata are regenerated for each verifiable presentation, using a securing mechanism that supports unlinkable disclosure such as Data Integrity BBS Cryptosuites v1.0. Verifiers prefer verifiable presentations that use such technology to enhance privacy for holders and subjects. Unlinkable signatures do not remove correlation that comes from other information in the credential, which is addressed by 3.2.10 T3. Identifier-Based Correlation and 3.2.12 T7. Excessive Data Disclosure.

Affected Components: E1: Issuer, E3: Verifier, P8: Generate Presentation, F3: Exchange Presentation, P10: Verify Presentation

Threat Taxonomy: STRIDE (Information Disclosure)

[Threat List]

When a verifier checks the status of a verifiable credential, the act of looking up status information can leak that an interaction is taking place. A revocation or status mechanism that is unique per credential, or that requires submitting a credential's identifier to a centralized query interface, tells the issuer operating status list storage which credential is being checked and, by inference, that a specific verifier is likely interacting with the holder. This enables an issuer to learn everywhere a credential is presented and enables issuers and verifiers to collude to correlate the holder. Even a bulk, privacy-preserving status list leaks information when the issuer updates the status list frequently: a verifier refetches it often to stay current, and that pattern of retrieval reveals the verifier's interest in that particular status list and, by extension, in the population of subjects the list covers. Whether this threat is present depends on the status mechanism an issuer deploys and how often it is updated.

R1. Privacy-Preserving Status Mechanisms (Reduce)

Issuers avoid status mechanisms, such as per-credential revocation lists, that reveal which credential is being checked during verification. Status mechanisms that do not depend on submitting a unique credential identifier to a query interface, such as a privacy-preserving status list retrieved in bulk, avoid signaling individual lookups. Serving status information from a globally distributed service further reduces the ability to correlate lookups.

R2. Warn and Reject on Privacy-Harming Status Checks (Reduce)

Software for holders warns when a credential carries status information that could lead to a privacy violation during verification. Verifiers consider rejecting credentials whose status checks produce privacy violations or enable substandard privacy practices.

Affected Components: E1: Issuer, E3: Verifier, P5: Update Status List, P11: Verify Credential Status, F4: Check Credential Status, S1: Status List Storage

Threat Taxonomy: STRIDE (Information Disclosure)

[Threat List]

The authenticity and integrity guarantees of a verifiable credential depend on the quality and protection of the private signing keys used to secure it. A compromised private signing key lets an attacker forge credentials that a verify process reports as authentic. Poor key management makes compromise more likely: reusing a private signing key for more than one purpose, such as for both encryption and signing; keeping a key in service for an over-long cryptoperiod; and using verification material without first confirming its validity. This threat concerns how keys are handled rather than whether the underlying algorithm is sound, which is addressed by 3.2.25 T5. Cryptographic Suite Obsolescence.

R1. Key Separation and Bounded Cryptoperiods (Reduce)

Operators follow established key-management guidance such as [NIST-SP-800-57-Part-1]: a private signing key is used for a single purpose and not, for example, for both signing and encryption, and private signing keys and public verification keys are given limited cryptoperiods. Bounding the cryptoperiod limits the window in which a compromised key can be exploited.

R2. Compromise Response and Material Validation (Reduce)

Operators put protective measures, harm-reduction steps, and revocation procedures in place to deal with potential private key compromise, as described in [NIST-SP-800-57-Part-1]. Before relying on any verification material, a verify process confirms its validity.

Affected Components: E1: Issuer, P3: Issue Verifiable Credential, P10: Verify Presentation, S1: Status List Storage, C1: Issuer System

Threat Taxonomy: STRIDE (Spoofing)

[Threat List]

A verifiable credential often contains URLs to data that resides outside the credential, such as images, JSON-LD extension contexts, JSON Schemas, and other machine-readable data. Because this linked content lives outside the protection of the securing mechanism, it is not protected against tampering. An attacker who modifies an external resource whose content affects how a credential is processed can introduce vulnerabilities into a consumer's application, even though the credential's own verification still succeeds. The specification leaves the choice of whether and how to protect external resources to implementers.

R1. Related Resource Integrity Protection (Reduce)

For external resources whose content changes could introduce security vulnerabilities, implementers use the integrity-protection mechanism for related resources defined by this specification, which binds a digest of each external resource into the protected credential so that tampering is detected. The mechanism is not needed for external resources that do not affect the credential's security.

R2. Use Known-Good Cached Values (Reduce)

For external references whose content is fixed and permanently cacheable, such as JSON-LD context files and JSON Schemas, consumers resolve them from a local store of known-good values rather than fetching them from the network at processing time. Pinning these resources to vetted, immutable copies removes the opportunity for an attacker to alter them and also avoids the network request that would otherwise leak activity, complementing the protections in 3.2.22 T10. Device Tracking and Fingerprinting.

Affected Components: P2: Assemble Verifiable Credential, P10: Verify Presentation, P12: Validate Credential(s), F2: Deliver Verifiable Credential, C3: Verifier System

Threat Taxonomy: STRIDE (Tampering)

[Threat List]

The data model does not by itself prevent man-in-the-middle, replay, and spoofing attacks on the exchange of a presentation. In a man-in-the-middle attack, a verifier cannot be sure it is the intended recipient of a verifiable presentation rather than the target of an adversary relaying it. In a replay attack, the same verifiable presentation is reused, for example when multiple individuals present the same credential representing an event ticket, undermining the ticket's purpose. In a spoofing attack, the verifier has no built-in way to confirm that the holder presenting the claims is authorized to do so. Both online and offline exchanges can be susceptible, and an unsecured protocol is susceptible to all three.

R1. Bind the Presentation to Its Audience (Reduce)

To counter man-in-the-middle attacks, verifiers use a securing mechanism that lets a verifiable presentation specify its intended audience or domain, as Verifiable Credential Data Integrity 1.0 does, so a presentation relayed to an unintended recipient is not accepted. Approaches that tie the request for a presentation to the response further secure the protocol.

R2. Enforce Freshness to Prevent Replay (Reduce)

To counter replay attacks, verifiers require holders to include additional measures in a verifiable presentation, such as a challenge supplied by the verifier whose uniqueness the verifier enforces, or a validity period that limits the window during which the presentation is accepted.

R3. Bind the Presentation to the Holder (Reduce)

To counter spoofing, implementers explore methods that establish the holder's authority to present the claims, such as binding verifiable credentials to strong authentication mechanisms or using additional properties in verifiable presentations that enable proof of control.

Affected Components: E2: Holder, E3: Verifier, P8: Generate Presentation, F3: Exchange Presentation, P10: Verify Presentation, P12: Validate Credential(s)

Threat Taxonomy: STRIDE (Spoofing)

[Threat List]

A valid cryptographic signature and a successful status check show that a verifiable credential is authentic and unrevoked, but they do not show that the credential is appropriate for the context in which it is being used. A verifier that treats verification as sufficient can accept a credential whose source and nature do not fit the purpose at hand. For example, a self-asserted credential carrying medical data can verify correctly yet lack the authority required where a certified medical diagnosis is needed. Not all credentials are interchangeable across contexts, and relying on one outside its appropriate context is a validation failure.

R1. Validate Fitness for Purpose (Reduce)

Beyond verifying a credential, verifiers validate the relevant claims, weighing the source and nature of each claim against the purpose for which the holder presents the credential. Verifiers assess whether the credential's authority is adequate for the specific context of their intended application before relying on it.

Affected Components: E3: Verifier, P10: Verify Presentation, P12: Validate Credential(s)

Threat Taxonomy: STRIDE (Tampering)

Deployment Threats

[Threat List]

A verifiable credential can contain long-lived identifiers that can be used to correlate a subject across contexts. These include subject identifiers in credentialSubject.id, credential identifiers, email addresses, government-issued identifiers, and organization-issued identifiers. When a holder generates a presentation and exchanges it, any such identifier that is disclosed to a verifier can be linked to identifiers disclosed elsewhere. Two verifiers, or an issuer and a verifier, can then collude to track the holder across domains and build a profile. Whether this threat is present depends on deployment choices: which identifiers an issuer places in a credential; whether they can be selectively disclosed; and whether a holder's software warns before sharing them; among other choices.

R1. Selectively Disclosable and/or Single-Use Identifiers (Reduce)

Deployments requiring anti-correlation properties can use identifiers that are selectively disclosable, bound to a single origin, single-use, or replaced by short-lived single-use bearer tokens. Selective disclosure is available across both families of securing mechanism: Verifiable Credential Data Integrity 1.0 defines selective disclosure cryptosuites, and Securing Verifiable Credentials using JOSE and COSE can carry selective disclosure formats such as SD-JWT. A holder therefore does not have to choose a particular securing mechanism to obtain selective disclosure of correlating identifiers. Holders prefer verifiable credentials from issuers that support selective disclosure of correlating identifiers, and securing-mechanism authors avoid designs that require correlating identifiers that cannot be selectively disclosed or the use of verifiable credentials that do not support selective disclosure.

R2. Warn Holders Before Sharing Correlatable Identifiers (Reduce)

Software for holders detects identifiers in a verifiable credential that could be used to correlate the subject, and warns the holder before they share this information. This lets the holder decide whether the disclosure is acceptable for the interaction. It reduces unintended correlation but does not prevent a holder from choosing to disclose a correlatable identifier.

Affected Components: E2: Holder, P8: Generate Presentation, F3: Exchange Presentation, E3: Verifier

Threat Taxonomy: STRIDE (Information Disclosure)

[Threat List]

Each role in the ecosystem relies on software acting as its user agent: an issuer's issuance software, a verifier's verification software, and above all a holder's digital wallet. A holder trusts their wallet to disclose information only when they consent to releasing it. When that software operates against the user's interest, it betrays this trust, for example by uploading a holder's personal information to a data broker, or by disclosing more than the holder authorized while it generates a presentation or engages in a workflow. A related case arises when a single piece of software acts as a user agent to more than one role at once, such as a website serving one verifier and many holders; it cannot always act in the best interest of every party simultaneously, and acts against some holders without their awareness. Whether this threat is present depends on which software an entity chooses to operate on its behalf, so it arises from deployment rather than from the data model itself.

R1. Trustworthy Software and Clear Consent (Reduce)

Implementers create software that operates in the user's best interests and obtains the user's consent before disclosing information. When a piece of software acts on behalf of more than one role, it makes clear in whose interest it is operating, for example through a published use policy, so the holder understands the trust boundary they are relying on.

R2. Auditing and User Oversight (Reduce)

Implementers include auditing features that let users, or trusted third parties acting for them, verify that the software is operating in alignment with their interests. Software that violates this expectation loses user trust and is replaced with a more trustworthy alternative.

Affected Components: E1: Issuer, E2: Holder, E3: Verifier, P7: Engage in Workflow (Holder), P8: Generate Presentation, P9: Engage in Workflow (Verifier), C2: Holder System

Threat Taxonomy: STRIDE (Information Disclosure)

[Threat List]

A verifiable credential can carry more personally identifiable information than an interaction requires. An issuer that assembles a credential containing specific data, such as a full date of birth, a home address, or a driver's identification number, exposes the subject to disclosure of that data whenever the credential is used, even when the verifier needs only a narrow fact such as whether the subject is over a certain age. A verifier that requests more than the minimum necessary compounds the exposure and takes on liability for handling sensitive data it does not need. Even data that appears innocuous, such as a birthdate combined with a postal code, has strong de-anonymization power once disclosed. This threat arises from choices made when credentials are designed and when verifiers frame their requests, rather than from the data model itself.

R1. Abstract Claims and Selective Disclosure (Reduce)

Issuers limit the information in a verifiable credential to the smallest set required for its intended purposes. One approach expresses an abstract property, such as ageOver, that answers a verifier's question without revealing the underlying sensitive value such as a birthdate. Another approach atomizes the information or uses a securing mechanism that supports selective disclosure, so the holder discloses only the individual properties an interaction requires.

R2. Verifier Data Minimization (Reduce)

Verifiers request only the information strictly necessary for a specific transaction. This reduces the verifier's liability for handling sensitive data and enhances the subject's and holder's privacy. Software for holders discloses what a verifier is requesting so the holder can decline to share information that is unnecessary, and gives the holder access to a log of what was shared.

Affected Components: E1: Issuer, E2: Holder, E3: Verifier, P2: Assemble Verifiable Credential, P8: Generate Presentation, P9: Engage in Workflow (Verifier), F3: Exchange Presentation

Threat Taxonomy: STRIDE (Information Disclosure)

[Threat List]

The choice of extensions, types, and technology profiles used in a verifiable credential can act as a correlating fingerprint when relatively few issuers use a specific combination. Cryptographic methods unique to a particular nation-state, revocation formats specific to a jurisdiction, or credential types employed only by a locality narrow the set of people a given holder could be, reducing the pseudonymity the holder expects when selectively disclosing information to a verifier. This threat arises from choices an issuer makes when it assembles a credential intended for pseudonymous use.

R1. Prefer Widely Adopted Profiles (Reduce)

Issuers issuing verifiable credentials intended for pseudonymous use limit the extension types, credential types, and technology profiles that could reduce a holder's pseudonymity. Choices with global adoption are the most privacy-preserving, followed by those in national use; choices with only local use offer the least pseudonymity because they narrow the holder's anonymity set the most.

Affected Components: E1: Issuer, E2: Holder, E3: Verifier, P2: Assemble Verifiable Credential, F3: Exchange Presentation

Threat Taxonomy: STRIDE (Information Disclosure)

[Threat List]

A bearer credential entitles whoever holds it to a resource without requiring the holder to identify themselves, by omitting the subject identifier normally expressed with the id property. This privacy-enhancing design can still enable correlation. Repeated use of the same bearer credential across multiple sites lets those sites collude to track the holder, and information that appears non-identifying on its own, such as a birthdate and a postal code carried in the same bearer credential, can statistically identify an individual. Whether this threat is present depends on how an issuer designs the bearer credential and how the holder uses it.

R1. Single-Use, Non-Identifying Bearer Credentials (Reduce)

Issuers of bearer credentials design them to be single-use where possible, to avoid carrying personally identifying information, and to avoid being unduly correlatable. Verifiers avoid requesting bearer credentials known to carry information that can be used to illicitly correlate the holder.

R2. Warn Holders of Correlation Risk (Reduce)

Software for holders warns the holder when it detects that a bearer credential containing sensitive information has been issued or requested, or that a correlation risk is posed by the combination of two or more bearer credentials across one or more sessions. Detecting every correlation risk is not possible, but many are detectable.

Affected Components: E1: Issuer, E2: Holder, E3: Verifier, P2: Assemble Verifiable Credential, F3: Exchange Presentation

Threat Taxonomy: STRIDE (Information Disclosure)

[Threat List]

Even when individual disclosures are minimized, the pattern in which verifiable credentials are presented can lead to de-anonymization. When the same verifiable credential is presented to the same verifier more than once, the verifier can infer it is dealing with the same individual. When the same credential is presented to different verifiers who collude, or a third party has access to transaction records from both, an observer can infer the same person controls both accounts. A subject identifier that is stable across presentations links them even when the credentials differ, and underlying information such as a postal code, age, and gender can be matched against an existing profile. In some settings correlation is a deliberate requirement, such as prescription monitoring, and in others it is intended, such as logging in with a common persona; the threat is the unintended or unexpected correlation that arises from presentation. Whether it is present depends on how holders and issuers design and use credentials.

R1. Single-Use Credentials and Fresh Identifiers (Reduce)

Software for holders provides a globally unique subject identifier for a given verifiable credential and does not reuse that credential, so a credential itself cannot be used to track the holder. Preferring single-use verifiable credentials wherever possible also assures verifiers that the data is fresh and leaves attackers nothing to steal.

R2. Avoid Long-Lived Correlating Identifiers (Reduce)

Issuers avoid associating personally identifiable information with any long-lived subject identifier, and avoid issuing credentials whose reuse enables them to correlate patterns of use. These techniques are not always practical or compatible with a required use, so some correlation remains unavoidable.

Affected Components: E2: Holder, E3: Verifier, P8: Generate Presentation, F3: Exchange Presentation, P9: Engage in Workflow (Verifier)

Threat Taxonomy: STRIDE (Information Disclosure)

[Threat List]

When a holder chooses to share information with a verifier, the verifier can be acting in bad faith and request information that could harm the holder. For example, a verifier might ask for a bank account number, which could then be combined with other information to defraud the holder or their bank. The data model describes the structure of a verifiable presentation but does not by itself prevent a holder from disclosing sensitive values to the wrong party, so this threat arises from the interaction rather than from the specification.

R1. Tokenize Sensitive Values (Reduce)

Issuers tokenize as much information as possible so that accidentally transmitting a credential to the wrong verifier is not catastrophic. For example, instead of a bank account number, a bank issues a verifiable credential containing a balance-checking token that lets a verifier confirm a balance is above a threshold without learning the account number or the exact balance, and the value of the token is bounded by a short validity period. Even if the holder shares the token with the wrong party, the attacker cannot recover the underlying sensitive value.

Affected Components: E2: Holder, E3: Verifier, P8: Generate Presentation, F3: Exchange Presentation

Threat Taxonomy: STRIDE (Spoofing)

[Threat List]

The data expressed in verifiable credentials and verifiable presentations is valuable because it contains authentic statements made by trusted third parties or individuals. Storing and making this data accessible can create honeypots of sensitive data that attract malicious actors seeking to acquire and trade it for financial gain. An issuer that retains more data than necessary, a holder that stores credentials on a poorly protected device, or a verifier that retains data beyond a transaction's needs each increases the value and likelihood of a large-scale theft. Whether this threat materializes depends on retention and protection choices made across the ecosystem.

R1. Minimize Retention (Reduce)

Issuers retain the minimum data necessary to issue credentials and to manage their status and revocation, and avoid creating publicly accessible credentials that include personally identifiable information. Verifiers ask only for data necessary for a particular transaction and retain no data beyond its needs. Regulators reconsider audit requirements that insist on long-term retention of personally identifiable information, favoring privacy-preserving alternatives such as logging that information was checked.

R2. Encrypt and Control Access to Stored Data (Reduce)

Software implementers safeguard verifiable credentials with robust consent and access-control measures so they remain inaccessible to unauthorized entities. Holders use implementations that encrypt data in transit and at rest, protect cryptographic secrets so they cannot be easily extracted from hardware, store and manipulate data on devices they control, and grant access only to explicitly authorized parties.

Affected Components: E1: Issuer, E2: Holder, E3: Verifier, S1: Status List Storage, S2: Holder Storage, C1: Issuer System, C2: Holder System, C3: Verifier System

Threat Taxonomy: STRIDE (Information Disclosure)

[Threat List]

Many privacy protections depend on active support from the issuer, and on the issuer not deliberately subverting them. An issuer that makes its verifiable credentials short-lived with automatic renewal can correlate a holder's behavior by learning each time a credential is renewed, even when the holder uses the credential without the issuer's direct knowledge. An issuer can also undermine a protection it appears to offer; for example, signing with a scheme that protects against signature-based correlation while minting a unique key for each issued credential, which lets the issuer track presentations even though a verifier cannot. Finally, the identifiers and claim types an issuer chooses can leak data, such as a driver's license revealing the issuer's jurisdiction and the subject's residence. This threat depends on issuer behavior and is not something the data model can prevent on its own.

R1. Avoid Correlating Issuance Practices (Reduce)

Issuers avoid issuance practices that let them correlate patterns of use, such as very short validity periods combined with automatic renewal, and avoid minting a unique key per credential when using a signature scheme intended to prevent signature-based correlation. Software for holders warns the holder when it repeatedly uses credentials with short lifespans that could enable behavior correlation.

R2. Mask Leaky Metadata (Reduce)

Issuers limit the data they leak through identifiers and claim types, for example by using a shared issuer identifier at a state or national level rather than one that reveals a smaller municipality. Verifiers use holder attestation mechanisms that prove an issuer belongs to a trusted set without disclosing the exact issuer.

Affected Components: E1: Issuer, E2: Holder, P2: Assemble Verifiable Credential, P3: Issue Verifiable Credential, P4: Publish Status List, F2: Deliver Verifiable Credential

Threat Taxonomy: STRIDE (Information Disclosure)

[Threat List]

When a verifiable credential carries highly dynamic information, the choice of validity period affects security. A validity period that extends beyond the time the information is intended to be used leaves a window in which a malicious actor can rely on stale information that no longer reflects reality. A validity period shorter than the information's useful lifetime places a burden on holders and verifiers through frequent reissuance and checking. Setting a validity period that does not match the volatility of the underlying information is therefore a source of risk. This threat depends on choices an issuer makes when it assembles a credential.

R1. Match Validity Period to Information Lifetime (Reduce)

Issuers set the validity period of a verifiable credential to match the use case and the expected lifetime of the information it contains, so that highly dynamic information is not treated as current for longer than it remains accurate, while stable information does not impose unnecessary reissuance on holders and verifiers.

Affected Components: E1: Issuer, P2: Assemble Verifiable Credential, P3: Issue Verifiable Credential, P10: Verify Presentation, P12: Validate Credential(s)

Threat Taxonomy: STRIDE (Tampering)

[Threat List]

Storing verifiable credentials on a device poses a risk if the device is lost or stolen. An attacker who gains possession of the device can gain unauthorized access to systems that rely on the victim's verifiable credentials, impersonating the holder. Impersonation also takes other forms, including an entity attempting to disavow its own actions. This threat arises from physical control of the holder system rather than from the data model itself.

R1. Authentication and Hardware Protection (Reduce)

Holders mitigate device theft by enabling screen-unlock protection on the device such as a password, PIN, pattern, or biometric; by requiring password, biometric, or multi-factor authentication for the credential repository and when accessing cryptographic keys; and by using a separate hardware-based signature device. These measures are combined for stronger protection.

R2. Non-Repudiation Mechanisms (Reduce)

Beyond preventing impersonation, implementers deploy non-repudiation mechanisms that tie an entity to its actions, reinforcing accountability and deterring an entity from disavowing them. These include securing mechanisms, proofs of possession, and authentication schemes built into the surrounding protocols.

Affected Components: E2: Holder, P6: Store Verifiable Credential, S2: Holder Storage, P8: Generate Presentation, C2: Holder System

Threat Taxonomy: STRIDE (Spoofing)

External Threats

[Threat List]

When a holder uses a third-party service to store verifiable credentials, the contents of holder storage are exposed to the service operator. The information in a verifiable credential can be sensitive and highly individualized, which makes it a target for data mining. A service offered at no charge can mine this personal data and sell it to organizations that build profiles of people and organizations. The same stored data can also be disclosed to authorities through legal processes that compel issuers, holders, or verifiers, or through a software bug or security failure. These are real-world risks that arise from the operating environment and the choice of service provider, and they are outside the scope of what the data model itself can control.

R1. Local or Encrypted Storage (Reduce)

Holders reduce exposure by using software that stores verifiable credentials locally on a device they control, or that encrypts credentials so the storage provider cannot read their contents. This limits both data mining by the provider and the information available for compelled disclosure. It does not address disclosure compelled directly from the holder.

R2. Provider Selection and External Oversight (Transfer)

Holders review the terms of service of a credential repository for its correlation and data-mining protections, and choose providers that do not sell information to third parties. Civil society and regulatory participation in vendor analysis and auditing, together with transparency and subject-notification requirements in legal and compliance regimes, place responsibility for these risks on the parties that operate the services and the processes.

R3. Accept Residual Environmental Risk (Accept)

Compelled disclosure through lawful legal process, and the residual risk that a provider or process behaves contrary to a holder's interests, cannot be removed by the data model. This portion of the threat is acknowledged and accepted as outside the scope of the specification.

Affected Components: E2: Holder, P6: Store Verifiable Credential, S2: Holder Storage

Threat Taxonomy: STRIDE (Information Disclosure)

[Threat List]

Mechanisms external to verifiable credentials track and correlate individuals on the Internet, including Internet protocol address tracking, web browser fingerprinting, evercookies, advertising network trackers, mobile network position information, and Global Positioning System interfaces. Using verifiable credentials alongside these technologies can reveal new correlatable information; for example, a birthdate combined with a device's location can strongly correlate an individual across multiple websites. Fetching an external resource associated with a credential, such as a linked image or a revocation list, also signals activity to the server hosting it. A holder's wallet fetching such a resource reveals the holder's activity, and a verifier fetching a status list signals to the issuer that it has received a specific credential. These tracking technologies exist outside the data model, so this risk arises from the operating environment rather than from the specification.

R1. Oblivious Retrieval of External Resources (Reduce)

Implementers fetch external resources associated with a verifiable credential or verifiable presentation using a privacy-preserving transport such as Oblivious HTTP [RFC9458], which lets a client make requests to an origin server without that server being able to link the requests to the client or identify them as coming from a single client. This reduces the chance that a holder is tracked when a wallet fetches linked content, and the chance that a verifier signals to an issuer that it has received a specific credential.

R2. Prevent Combination with Tracking Technologies (Reduce)

Privacy-respecting systems aim to prevent the combination of other tracking technologies with verifiable credentials. In some cases, tracking technologies are disabled on devices that transmit verifiable credentials on behalf of a holder.

Affected Components: E2: Holder, E3: Verifier, P8: Generate Presentation, P11: Verify Credential Status, F4: Check Credential Status, C2: Holder System

Threat Taxonomy: STRIDE (Information Disclosure)

[Threat List]

Holding two pieces of information about the same subject often reveals more than the two pieces considered separately, even when they arrive through different channels or sessions. When a verifier receives, for example, a bearer credential carrying an email address and another stating the holder is over a certain age, it gains a unique identifier joined to an attribute and can begin building a profile that grows as more information leaks over time. Aggregation is also performed by multiple sites acting in collusion. Preventing aggregation is a difficult problem: long-lived identifiers and browser-tracking techniques defeat even modern cryptographic protections, so the effective mitigations are largely policy-driven. This risk arises from the broader operating environment rather than from the data model itself.

R1. Express and Honor Anti-Aggregation Intent (Reduce)

A holder who wishes to avoid the aggregation of their information expresses this in the verifiable presentations they transmit, and relies on the holders and verifiers to whom they transmit those presentations to honor it. Because the effective controls are largely policy-driven rather than technological, all participants in the ecosystem remain aware of the risks of data aggregation.

R2. Accept Residual Aggregation Risk (Accept)

The existence of long-lived identifiers and external tracking techniques means aggregation cannot be fully prevented by technological means. This residual risk is acknowledged and accepted as outside the scope of the data model.

Affected Components: E2: Holder, E3: Verifier, F3: Exchange Presentation, P9: Engage in Workflow (Verifier)

Threat Taxonomy: STRIDE (Information Disclosure)

[Threat List]

After a holder shares a verifiable presentation with a verifier for a stated purpose, the verifier can use that data beyond the purpose the holder consented to. Consider a holder who shares a presentation to establish age and residency; if the verifier then uses the data without proper consent, such as selling it to a data broker, that is an unauthorized use that violates the holder's expectation of privacy. A issuer can express, through a termsOfUse property, how and when a credential is permitted to be used, and use outside that scope is unauthorized. The data model does not currently provide a way for a holder to enforce authorized use after presentation, so this threat is acknowledged as an area for further study.

R1. Express Terms of Use (Reduce)

Issuers use a termsOfUse property to state the scopes and purposes for which a credential is permitted to be used, giving verifiers and downstream parties a clear signal of what constitutes authorized use and a basis on which unauthorized use can be identified.

R2. Accept Residual Enforcement Gap (Accept)

How a holder can assert and enforce authorized use of their data after presentation requires further study. Until such mechanisms exist, the residual risk that a verifier uses disclosed data contrary to the holder's consent is acknowledged and accepted as outside what the data model controls.

Affected Components: E2: Holder, E3: Verifier, F3: Exchange Presentation, P12: Validate Credential(s)

Threat Taxonomy: STRIDE (Repudiation)

Dependency Threats

[Threat List]

The authenticity and integrity guarantees of a verifiable credential depend on the cryptography suites and libraries used to issue and verify it. Cryptography suites and libraries have a shelf life and eventually succumb to new attacks and advances in technology, including the future arrival of cryptographically relevant quantum computers. When a suite that secures issued credentials is broken, an attacker can forge or modify a verifiable credential while it is delivered to the holder or exchanged with a verifier, and the verify process still reports it as authentic. This risk is inherited from the cryptographic dependencies of the data model rather than from the data model itself.

R1. Cryptographic Agility and Credential Replacement (Reduce)

Production systems provide mechanisms to upgrade expired or broken cryptography suites and libraries, and to invalidate and replace existing credentials that were secured with them. Supporting more than one securing mechanism, and being able to reissue affected credentials, allows a deployment to migrate away from a suite once it is weakened.

R2. Monitoring and Bounded Cryptoperiods (Reduce)

Operators monitor the state of the cryptography suites and libraries they depend on so that weaknesses are detected and acted on. Bounding key cryptoperiods and credential validity periods limits the window in which a broken or compromised suite can be exploited before affected credentials expire.

R3. Audit and Red Teaming of Cryptographic Implementations (Reduce)

Implementing and auditing cryptography systems requires substantial experience. Deployments reduce the chance of a latent weakness by having experienced reviewers audit the suites and libraries they use, and by using red teaming to remove bias from those security reviews.

R4. Issuer-Deployed Forgery Defense (Reduce)

Issuers can deploy the mechanisms described in Verifiable Credential Forgery Defense v1.0, which layer additional, independent defenses onto issued verifiable credentials so that a credential's authenticity does not rest on a single securing mechanism alone. When an issuer applies these defenses at issuance, a verifier can rely on them at verification to detect forged or modified credentials even if one cryptography suite is later weakened or broken. This raises the cost of a successful forgery and narrows the window in which an obsolete suite can be exploited.

R5. Use Reputable Cryptographic Libraries and Specialized Building Blocks (Reduce)

Secure cryptography is difficult and demands specialized skills; implementers should not re-implement complex cryptographic algorithms themselves. Wherever possible, deployments use well-established, reputable cryptographic libraries that are actively maintained and widely reviewed, and accept that a correct and secure implementation requires expertise most application developers do not have. This concern is not limited to cryptography: the other constituents of a verifiable credential implementation, such as canonicalization, securing-mechanism processing, and status checking, likewise call for specialized care. Efforts such as VCALM v1.0 aim to make it easier to assemble implementations from vetted, specialized building blocks rather than re-implementing sensitive components from scratch.

Affected Components: P3: Issue Verifiable Credential, P10: Verify Presentation, F2: Deliver Verifiable Credential, F3: Exchange Presentation

Threat Taxonomy: STRIDE (Tampering)

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 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 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 issuer system to the holder system.
F3 Exchange Presentation	The data flow by which a holder delivers a verifiable presentation to the 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 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 issuer system holding the published status information for issued credentials, retrievable by verifiers.
S2 Holder Storage	The persistent storage within the 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 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 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.

Verifiable Credentials Data Model Threat Model

Abstract

Status of This Document

1. Introduction

1.1 Description

1.2 Data Flow Diagram for the Verifiable Credentials Ecosystem

1.3 Dictionary

2. Stakeholders

2.1 E1 Issuer

2.2 E2 Holder

2.3 E3 Verifier

3. Threats

3.1 Threat List

3.2 Threat Details

3.2.1 T1. Credential Content Tampering

T1. Credential Content Tampering security

3.2.2 T25. Identity Proofing Failure at Issuance

T25. Identity Proofing Failure at Issuance security

3.2.3 T2. Code Injection via Credential Content

T2. Code Injection via Credential Content security

3.2.4 T8. Signature-Based Correlation

T8. Signature-Based Correlation privacy

3.2.5 T12. Correlation via Status and Revocation Lookup

T12. Correlation via Status and Revocation Lookup privacy

3.2.6 T18. Signing Key Compromise and Mismanagement

T18. Signing Key Compromise and Mismanagement security

3.2.7 T19. Tampering with Unprotected External Resources

T19. Tampering with Unprotected External Resources security

3.2.8 T20. Presentation Exchange Attacks (MITM, Replay, and Spoofing)

T20. Presentation Exchange Attacks (MITM, Replay, and Spoofing) security

3.2.9 T24. Inappropriate or Out-of-Context Credential Use

T24. Inappropriate or Out-of-Context Credential Use security

3.2.10 T3. Identifier-Based Correlation

T3. Identifier-Based Correlation privacy

3.2.11 T6. Untrustworthy User-Agent Software

T6. Untrustworthy User-Agent Software privacy

3.2.12 T7. Excessive Data Disclosure

T7. Excessive Data Disclosure privacy

3.2.13 T9. Metadata-Based Correlation

T9. Metadata-Based Correlation privacy

3.2.14 T11. Bearer Credential Reuse and Correlation

T11. Bearer Credential Reuse and Correlation privacy

3.2.15 T14. Correlation via Patterns of Use

T14. Correlation via Patterns of Use privacy

3.2.16 T15. Disclosure to a Malicious or Deceptive Verifier

T15. Disclosure to a Malicious or Deceptive Verifier privacy

3.2.17 T16. Data Theft and Credential Honeypots

T16. Data Theft and Credential Honeypots security

3.2.18 T17. Issuer-Side Correlation and Privacy Subversion

T17. Issuer-Side Correlation and Privacy Subversion privacy

3.2.19 T21. Inappropriate Validity Periods

T21. Inappropriate Validity Periods security

3.2.20 T22. Device Theft and Impersonation

T22. Device Theft and Impersonation security

3.2.21 T4. Storage Provider Data Mining and Compelled Disclosure

T4. Storage Provider Data Mining and Compelled Disclosure privacy

3.2.22 T10. Device Tracking and Fingerprinting

T10. Device Tracking and Fingerprinting privacy

3.2.23 T13. Credential and Data Aggregation

T13. Credential and Data Aggregation privacy

3.2.24 T23. Unauthorized Post-Presentation Use of Data

T23. Unauthorized Post-Presentation Use of Data privacy

3.2.25 T5. Cryptographic Suite Obsolescence

T5. Cryptographic Suite Obsolescence security

4. Contributing

4.1 Adding a Threat

A. References

A.1 Informative references