Threat Model for Decentralized Credentials

1. Introduction

1.1. Scope

Digital identity is a broad topic. This threat model starts with a narrower scope: decentralized credentials related to people, especially high-assurance credentials such as government-issued credentials. It focuses on Layer 3: "Credentials", and more specifically on the credential-presentation phase, as described by the SSI Technology Stack from ToITP, the DIF FAQ, and the Identity & the Web Report:

The immediate need arose in W3C discussion of the possible adoption of the Digital Credentials API by the Federated Identity Working Group. That API would allow user agents to mediate communication between a website that requests evidence and the user’s wallet. The discussion also identified the need for a broader model that analyzes security, privacy, and human-rights concerns across the relevant layers.

This threat model is a living document. It can be expanded to include other parts of the architecture or different levels of detail, such as the cryptographic properties of a specific profile or the broader governance context in which credentials are issued and used.

This generic model identifies security, privacy, and harms-related properties that can later be carried into a concrete architecture, profile, or implementation.

The document is intended to support a shared analysis. It starts from the Digital Credentials API at a high level and uses that starting point to discuss how decentralized credentials can be developed in a security- and privacy-preserving way while avoiding harm.

1.1.1. Terminology

This document uses the definition of identity from ISO/IEC 24760-1:2019, "IT Security and Privacy - A framework for identity management".

Identity is "a set of attributes related to an entity". An entity is something "that has recognizably distinct existence", and can be "logical or physical", such as "a person, an organization, a device, a group of such items, a human subscriber to a telecom service, a SIM card, a passport, a network interface card, a software application, a service or a website". Attributes are "characteristics or properties", such as "an entity type, address information, telephone number, a privilege, a MAC address, a domain name".

We present credentials to claim a certain identity, whether in the physical or digital world. Just as we do not have a one-size-fits-all definition of identity, we also do not have a one-size-fits-all definition of credentials in IT, as they vary by context.

The credential definition from the W3C Verifiable Credentials Data Model (VCDM) states: a "set of one or more claims made by an issuer". Its framing is in the decentralized identity model, and this document maps the ISO’s attributes to VCDM claims.

For example, a person’s characteristics can include physical appearance, voice, beliefs, and habits. Identity is distinct from an identifier, such as a username.

Digital credentials are often discussed in relation to people, particularly government-issued credentials or "real-world identities". They can also be used for non-human identities.

For that reason, this threat model also considers privacy as a right and harms as part of the analysis.

1.2. Related Work

• Joint work on rights-respecting digital credentials

• User considerations for credential presentation on the Web

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

1.3. Methodology

Security can be understood as a separation function between an asset and a threat. In this document, a threat may have security, privacy, or harms-related effects.

There are many approaches to threat modeling. This document uses Adam Shostack’s four-question frame as the organizing structure:

• What are we working on? This includes the architecture, actors, assets, flows, and trust boundaries.

• What can go wrong? This includes threats, threat actors, attacks, privacy failures, and harms.

• What are we going to do about it? This includes responses, assumptions, transfers, acceptances, and remaining threats.

• Did we do a good job? This includes checking whether the model is useful enough to guide the next stage of work.

The central phases use prompt lists and analysis frameworks as aids for finding issues, not as exhaustive taxonomies. Useful sources include:

• Solove’s Taxonomy

• Privacy Patterns

• Privacy Principles

• LINDDUN

• RFC 6973

• RFC 3552

• STRIDE

• OSSTMM v3

• Microsoft’s Types of Harm (tailored for Identity)

• RFC 9620

This analysis also uses OSSTMM. OSSTMM controls help identify what can go wrong, such as a missing control or a control that fails in context.

Although OSSTMM is control-oriented and often reads as security-oriented, privacy can be treated as an operational control that connects different parts of the model.

1.4. Channel and Vector

OSSTMM analyses define a channel and a vector.

This model uses the COMSEC Data Networks channel and the Internet/Web vector.

Although different digital credentials may use different channels or vectors (e.g., Wireless), they can still be analyzed similarly.

2. Analysis

2.1. What are we working on?

This threat model first identifies the components of the decentralized identity architecture, which in this context is used as a synonym for self-sovereign identity, as defined in the W3C Verifiable Credentials Data Model, and how they interact.

2.1.1. Architecture and Actors

• A Holder has credentials inside a Wallet.

• An Issuer issues credentials to the Holder and manages revocation.

• A Verifier verifies the Holder’s credentials to give access to a resource or a service.

• A Verifiable Data Registry (VDR) stores identifiers and schemas.

Interactions between actors typically occur through software or other technological components. This document refers to those components as Agents. One agent might be embedded in a Wallet, the component that contains the Holder’s credentials. Another might be a browser, which is a user agent.

2.1.2. Flows

The model considers three general flows, with four "ceremonies" where the actors interact.

• Credential-Issuing

• Credential-Presentation and Credential-Verification

• Credential Revocation

The flow stops here, but deployments can continue it in several ways. For example, the Holder receives credentials from an Issuer and uses them to identify themselves to a Verifier to buy a physical object or a ticket to an event. The Verifier could then become an Issuer to issue a certificate of authenticity for the object, or issue the ticket directly into the Holder’s Wallet.

• Credential-Issuing (CI):

  1. The Issuer requests a certain authentication mechanism from the Holder.

  2. After authentication, the Holder asks the Issuer for the credential, or the Issuer submits it.

  3. If both parties agree, the Issuer sends the credential to the Holder in a specific format.

  4. The Holder enters their credential into the Wallet.

• Credential-Presentation (CP)

  1. The Holder requests access to a specific resource or service from the Verifier.

  2. The Verifier then requests Proof from the Holder. This can be done actively (e.g., the Verifier presents a QR code for the Holder to scan) or passively (e.g., the Holder accesses a web page and is prompted to provide a credential).

  3. Through the Wallet, the Holder’s user agent determines whether credentials exist to generate the required Proof.

  4. The Holder may use the Proof explicitly if they possess it.

  5. The Holder’s user agent then prepares the Presentation, which can contain the full credential or part of it, and sends it to the Verifier.

• Credential-Verification (CV)

  1. The user agent of the Verifier verifies the Presentation (e.g., if the Presentation and the contained Credentials are signed correctly, issued by an Issuer they trust, compliant with their policy, the Holder is entitled to hold it, and that it has not been revoked or expired). The revocation check can be done using the methods defined by the specific credential.

  2. If the verification is successful, the Verifier gives the Holder access.

• Credential-Revocation (CR)

  1. The Issuer can revoke a credential in various ways.

2.1.3. Trust and Trust Boundaries

Trust is a key element in threat modeling. In fact, in OSSTMM, it is an element of privileged access to the asset, which, when trusted, lowers various operational controls.

At the Process level, trust relationships are:

• The Holder trusts the Issuer during issuance.

• The Holder always trusts its agents and wallet.

• The Holder trusts the Verifier during the Presentation.

• The Verifier relies on trust in the Issuer during Verification.

• All actors trust the record of verifiable data.

• Both the Holder and Verifier rely on the Issuer to revoke VCs that have been compromised or are no longer true.

At the Software level, Trust boundaries are documented in the Data Model in section 8.2:

• An issuer’s user agent (issuer software), such as an online education platform, is expected to issue only verifiable credentials to individuals that the Issuer asserts have completed their educational program.

• A verifier’s user agent (verification software), such as a hiring website, is expected to only allow access to individuals with a valid verification status for verifiable credentials and verifiable presentations provided to the platform by such individuals.

• A holder’s user agent (holder software), such as a digital wallet, is expected to divulge information to a verifier only after the Holder has consented to its release.

However, from a threat modeling perspective, the Issuer, Verifier, and Holder are external entities, so there are trust boundaries between them. This makes sense and is also why we have the concept of (crypto) verification.

2.1.4. Data Model, Formats, Protocols

To model Decentralized Identities and Credentials, it is possible to use them as a high-level meta-model using Verifiable Credentials documentation (the list of technologies is partial; feel free to extend):

• Data Models: abstract models for Credentials and Presentation (e.g., the Verifiable Credentials Data Model, mDL in ISO/IEC 18013-5:2021).

• Identifiers: DIDs and the DID methods, or WebID.

• Encoding Schemas: JSON, JSON-LD, CBOR, CBOR-LD.

• Securing Mechanisms: Each mechanism may or may not support different privacy features or be quantum-resistant:

  • Enveloped Formats (Credential Formats): The Proof wraps around the serialization of the credential. JSON credentials can be enveloped using JSON Object Signing and Encryption (JOSE); relevant formats include JWT, JWS, and JWK. JOSE is "cryptographically agile" because it can fit different cryptographic primitives, and can also support Selective Disclosure (SD) with SD-JWT, which uses HMAC. New security mechanisms are emerging, such as SD-BLS, which uses BLS, and ongoing efforts to implement BBS#. CBORs are enveloped using CBOR Object Signing and Encryption (COSE). Other formats include mdoc and SPICE. The mechanism to use VCDM with JOSE/COSE is described in Securing Verifiable Credentials using JOSE and COSE.

  • Embedded Formats (Signature Algorithms): The Proof is included in the serialization alongside the credentials (e.g., BBS, ECDSA, EdDSA). The mechanism is described in Verifiable Credential Data Integrity 1.0.

• Status Information (Revocation Algorithms): Issuers can implement several ways to keep up to date the status of the credential, such as Revocation List, Status List (e.g., Bitstring Status List v1.0), Cryptographic Accumulators, etc.

• Communication Protocols: for the different phases of Issuance and Presentation (e.g., OID4VCI, OID4VP, SIOPv2).

2.1.5. Assets

Assuming that the main asset is the credential and information derived during its life cycle, this model uses the three privacy properties defined by Ben Laurie as a starting point:

• Verifiable

• Minimal

• Unlinkable

These properties were defined in a very specific case of Decentralized Identities. Those related to people, and, more specifically, those issued by governments, are based on the concept of Privacy for the protection of the Holder.

The Minimal and Unlinkable properties primarily protect the Holder. The Verifiable property is relevant to all actors. Verifiable means that the Verifier can confirm who issued the credential, that it has not been tampered with, has not expired or been revoked, contains the required data, and may be associated with the Holder.

This threat model starts with government-issued credentials for people because that use case exposes many of the relevant security, privacy, and harms-related tensions.

Minimization and Unlinkability are generally interrelated: the less data a Holder discloses, the less data can be linked. They need to coexist with Verifiability. For example, checking whether a credential has been revoked may require contacting the Issuer or a service that maintains revocation information, but that approach can also make the credential linkable.

2.1.5.1. Minimization Scale

The following scale helps qualify Minimization:

• Full Disclosure (e.g., showing the whole passport).

• Selective Disclosure (e.g., showing only the date of birth).

• Predicate Disclosure (e.g., proving only the age).

• Range Disclosure (e.g., proving only that a person is an adult).

2.1.5.2. Unlinkability Scale

The Nymity Slider helps qualify Unlinkability by classifying credentials as:

• Verinymity (e.g., Legal name or Government Identifier).

• Persistent Pseudonymity (e.g., Nickname).

• Linkable Anonymity (e.g., Bitcoin/Ethereum Address).

• Unlinkable Anonymity (e.g., Anonymous Remailers).

One possible response is to move the design toward Unlinkable Anonymity where the credential properties and use case allow it.

2.2. What can go wrong?

After identifying the assets and properties, the model identifies who can affect them.

2.2.1. Threat Actors

Protecting the Holder is a central concern. A conservative model treats each actor as a possible threat actor to the others:

Holder, Issuer, Verifier, and their agents/software components (e.g., Browser, Wallet, Websites). Each actor can threaten the others, and an actor can also create threats for itself (e.g., Alert fatigue).

In addition, although there are trust relationships between the various actors and their software (which hold across the various steps), such software can also be malicious. It can track Holders, the type of credential they have, and how and where they use it through telemetry and statistical collection, and it can influence user choices.

The analysis also needs to consider a possible external threat actor, who could also be an observer or use active techniques, and who wants to track the three main actors or their agents, such as Marketers, Data brokers, Stalkers, Identity thieves, intelligence and law enforcement agencies (laws often constrain them), and OSINT investigators.

The model also considers combinations of actors, such as multiple Verifiers acting together or an Issuer and Verifier collaborating to track the Holder.

2.2.2. Evil user stories

Using this model, the following Evil User Stories can be used as starting points:

• A malicious Verifier who wants to collect too much data from the Holder.

• A malicious Holder who wants to get something they are not entitled to from the verifier.

• A malicious Issuer that wants to track its holders.

• A malicious Agent who wants to track its holder.

• An external Adversary who wants to track the Issuer, how a Verifier works, or a specific Holder.

2.2.3. Finding the Threats

One effective, though inefficient, approach to threat modeling is to cycle through the lists of threats and attacks, controls, and objectives in a brainstorming session to assess how they may affect architecture components, actors, assets, and the overall flow. Using multiple frameworks may result in some elements being repeated.

2.2.3.1. Ben’s Privacy Properties (Objectives)

• Verifiable:

  • Description: A statement is more useful when the relying party has a way to check whether it is true. This is not always required: a person may not need to prove that an address is theirs to receive a delivery, but may need to prove that they are over 18 to receive alcohol.

  • Analysis: This brings us to the concept of integrity (via cryptographic means), which is authenticated and trusted at the level of the issuer and from what exists.

• Minimal:

  • Description: This is the privacy-preserving property: the relying party receives only the information needed for the transaction. A person should not have to reveal their date of birth when the verifier only needs to know whether they are over 18.

  • Analysis: The interaction should release only what is strictly necessary. Since this is an interaction, we consider Subjugation an interactive OSSTMM control. For example, age verification can be handled by showing the whole document, showing only the date of birth (Selective Disclosure), or answering a specific true/false query (Predicate Proofs). This property also helps Unlinkability: the less data is disclosed, the less data can be correlated.

• Unlinkable:

  • Description: If the relying party, multiple relying parties, or other actors in the system can link a person’s assertions, then minimal disclosure no longer provides the expected privacy protection.

  • Analysis: The interaction should remain minimal. Ideally, it should not be possible to map the signer (Signature Blinding), contact them to know if the credential has been revoked (e.g., Revocation via Cryptographic Accumulation), or use revocation lists that expose the list of credentials. Generally, if an identifier can be used to link identities, it should be rotated (Rotational Identifiers), as with PAN numbers used with Apple Pay.

2.2.3.2. LINDDUN (Threats)

• Linking:

  • Description: Learning more about an individual or a group by associating data items or user actions. Linking may lead to unwanted privacy implications, even if it does not reveal one’s identity.

  • Threat: This is primarily a threat to the Holder and to the unlinkability of their attributes, but an Issuer can also track its users. The same concern applies to a Verifier, a group of Verifiers, or an external third party observing exchanges or the Revocation list.

  • Responses:

    • Use Signature Blinding.

    • The Verifier should request the following: Range Proof, Predicate Proof, Selective Disclosure, and the credential.

    • The Issuer should use an anonymous revocation method such as Cryptographic Accumulators.

    • The Issuer should use random identifiers when generating the credential.

    • When interacting with the Verifier, the Holder should always use rotational and random identifiers specific to that interaction session.

    • The Issuer should use privacy-preserving identifiers (e.g., DID). Once resolved, they do not establish a connection to a system controlled, directly or indirectly, by the Issuer.

• Identifying:

  • Description: Identifying threats arises when the identity of individuals can be revealed through leaks, deduction, or inference in cases where this is not desired.

  • Threat: The threat is the ability to identify an individual using their credentials.

  • Responses: The Verifier should request the following: Range Proof, Predicate Proof, Selective Disclosure, and the credential.

    • The Issuer and the Holder should avoid writing personally identifiable information (PII) or linkable identifiers in the VDR.

    • The Issuer should use an anonymous revocation method.

• Non-Repudiation:

  • Description: Non-repudiation threats pertain to situations where an individual can no longer deny specific claims.

  • Threat: The inability of an actor to deny the issuance or presentation of a credential; an example is a DHS use case.

  • Responses:

    • Depending on the Levels of Assurance (LOAs), the issuer is expected to use appropriate authentication during the issuing process.

    • Appropriate logging is expected for the issuer, the Verifier, and the Holder (and their agents), e.g., following the OWASP. ASVS 7.1 e.g., each log should contain enough metadata for an investigation, time with timezone reference, without PII but with session identifiers, but in a hashed format, in a common machine-readable format, and possibly signed.

• Detecting:

  • Description: Detecting threats pertains to situations where an individual’s involvement, participation, or membership can be deduced through observation.

  • Threat: In this case, the threat can happen in several stages: when a credential is required to be presented, the credential is verified.

  • Responses:

    • When proof or a credential is requested, the Holder agent is expected to return the same message and behavior (including timing, to avoid side-channel attacks) whether or not a wallet is present, whether the wallet has a credential or not, whether it has a valid credential, or whether the user does not accept. It is the same whether or not the user gives the browser access to the wallet.

      • When a credential’s validity is verified, there should be no direct connections or systems controlled by the Issuer (e.g., when a DID is resolved) to avoid back-channel connections.

• Data Disclosure:

  • Description: Data disclosure threats represent cases in which disclosures of personal data to, within, and from the system are considered problematic.

  • Threat: The threat will be disclosed during presentation and verification.

  • Responses:

    • The Verifier should request the following: Range Proof, Predicate Proof, Selective Disclosure, and the credential.

    • The Issuer and the Holder should avoid writing personally identifiable information (PII) or linkable identifiers in the VDR.

    • The Issuer should use an anonymous revocation method.

• Unawareness & Unintervenability:

  • Description: Unawareness and Unintervenability threats occur when individuals are insufficiently informed, involved, or empowered concerning the processing of their data.

  • Threat: For the Holder, unaware of how their credentials are used or shared.

  • Responses:

    • The Holder should be informed when a Verifier asks for the credential’s Full Disclosure or Selected Disclosure.

    • The Holder should be informed when their credentials is Phoning Home or possible back-channel connections.

    • The Holder should consent to each use of their credential and be able to identify the Verifier, the Proof Requested (at the moment of request), and which credentials and information are shared with the Verifier after the selection.

• Non-Compliance:

  • Description: Non-compliance threats arise when the system deviates from legislation, regulation, standards, and best practices, leading to incomplete risk management.

  • Threat: The risk of credentials not complying with legal, regulatory, or policy requirements. It is also possible to translate this element about minimal training for the Holder, particularly if they are in a protected or at-risk category, so they can be aware of what they are doing and the risks associated with Social Engineering.

  • Responses:

    • Provide Security Awareness Training to the Holder

    • Verifiers and Issuers should be subject to regular audit.

    • The standards and their implementation should include responses to harms such as Surveillance, Discrimination, Dehumanization, Loss of Autonomy, and Exclusion.

2.2.3.3. RFC 6973 (Threats)

• Surveillance:

  • Description: Surveillance observes or monitors an individual’s communications or activities.

  • Threat: Surveillance can involve governments tracking the Holder or an adversary, but it also includes profiling for targeted advertising, tracking by software agents that the Holder is expected to trust, or tracking by threat actors such as stalkers.

  • Responses:

    • Refer to LINDDUN’s Linking, Identifying, and Data Disclosure

• Stored Data Compromise:

  • Description: End systems that do not take adequate measures to secure stored data from unauthorized or inappropriate access expose individuals to potential financial, reputational, or physical harm.

  • Threat: All actors can be compromised. This matters especially for wallets and agents used by the Holder, the end-user device, and the Issuer's signature keys.

  • Responses:

    • Keys are expected to be stored securely and protected from compromise of the device or location where they are contained (e.g., Secure Enclave, Keystore, HSMs).

      • At the Issuer’s organizational level, the Incident Response Plan should include what to do in case of compromise of private keys or underlying device technology.

• Intrusion:

  • Description: Intrusion consists of invasive acts that disturb or interrupt one’s life or activities. Intrusion can thwart individuals' desires to be left alone, sap their time or attention, or interrupt their activities. This threat focuses on intrusions into one’s life rather than direct intrusions into one’s communications.

  • Threat: Intrusive and multiple data requests by Verifier

  • Responses:

    • Refer to LINDDUN’s Linking, Identifying, and Data Disclosure

    • Implement time-based throttling for requests

• Misattribution:

  • Description: Misattribution occurs when data or communications related to one individual are attributed to another.

  • Threat: Incorrect issuance or verification of credentials.

  • Responses:

    • Refer to LINDDUN’s Non-Repudiation

• Correlation:

  • Description: Correlation is the combination of various information related to an individual, or that obtains that characteristic when combined.

  • Threats: Linking multiple credentials or interactions to profile or track a Holder. We are linking individuals to the same Issuer.

  • Responses:

    • Refer to LINDDUN’s Linking, Identifying, and Data Disclosure

• Identification:

  • Description: Identification is linking information to a particular individual to infer an individual’s identity or to allow the inference of an individual’s identity.

  • Threats: Verifiers asking more information than necessary during credential verification.

  • Responses:

    • Refer to LINDDUN’s Unawareness & Unintervenability and Identifying.

• Secondary Use :

  • Description: Secondary use is the use of collected information about an individual without the individual’s consent for a purpose different from that for which the information was collected.

  • Threat: Unauthorized use of collected information, e.g., for targeted advertising or creating profiles, and Abuse of Functionality on collected data

  • Responses:

    • Refer to LINDDUN’s Non-Compliance.

• Disclosure:

  • Description: Disclosure is the revelation of information about an individual that affects how others judge the individual. Disclosure can violate individuals' expectations of data confidentiality.

  • Threat: A Verifier asks for more data than needed.

  • Responses:

    • Refer to LINDDUN’s Data Disclosure.

• Exclusion:

  • Description: Exclusion is the failure to let individuals know about the data that others have about them and participate in its handling and use. Exclusion reduces accountability on the part of entities that maintain information about people and creates a sense of vulnerability about individuals' ability to control how their information is collected and used.

  • Threats: Lack of transparency in using the data provided.

  • Responses:

    • Refer to LINDDUN’s Unawareness & Unintervenability.

2.2.3.4. RFC 3552 (Attacks)

• Passive Attacks:

  • Description: In a passive attack, the attacker reads packets off the network but does not write them, which can bring Confidentiality Violations, Password Sniffing, and Offline Cryptographic Attacks.

  • Responses:

    • Encrypt Traffic.

    • Use Quantum-Resistant Algorithms.

    • Use Key Management practices to rotate keys.

• Active Attacks:

  • Description: When an attack involves writing data to the network. This can bring Replay Attacks (e.g., recording the message and resending it), Message Insertion (e.g., forging a message and injecting it into the network), Message Deletion (e.g., removing a legit message from the network), Message Modification (e.g., copying the message, deleting the original one, modifying the copied message re-injecting it into the flow), Man-In-The-Middle (e.g., combination of all the previous attacks).

  • Responses:

    • Use a nonce to prevent replay attacks

    • Use Message Authentication Codes/Digital Signatures for message integrity and authenticity

    • Use a specific field to bind the request to a specific interaction between the Issuer, Verifier, and Issuer to Holder.

    • Encrypt Traffic.

    • Use Quantum-Resistant Algorithms.

2.2.3.5. STRIDE (Threats)

• Spoofing (Threats to Authentication):

  • Description: Pretending to be something or someone other than yourself.

  • Responses:

    • Implement Digital Signatures

    • During the presentation, indicate proper messages for identifying the Verifier to limit Phishing Attacks.

    • During issuing, use proper LOAs depending on the issued credentials.

• Tampering (Threats to Integrity):

  • Description: Modifying something on disk, network, memory, or elsewhere.

  • Responses:

    • Implement Digital Signatures in transit and at rest.

• Repudiation (Threats to Non-Repudiation):

  • Description: Claiming that you didn’t do something or were not responsible can be honest or false

  • Responses:

    • Refer to LINDDUN’s Non-Repudiation.

• Information disclosure (Threat to Confidentiality and Privacy):

  • Description: Confidentiality Someone obtaining information they are not authorized to access

  • Responses:

    • Refer to LINDDUN Data Disclosure.

• Denial of service (Threats to Availability and Continuity):

  • Description: Exhausting resources needed to provide service

  • Responses:

    • Use a decentralized VDR for verification

  • Elevation of privilege (Threats to Authorization):

    • Description: Allowing someone to do something they are not authorized to do

    • Responses:

      • During issuing, use proper LOAs depending on the issued credentials.

2.2.3.6. OSSTMM (Controls)

• Visibility:

  • Description: Police science places “opportunity” as one of the three elements that encourage theft, along with “benefit” and “diminished risk.” Visibility is a means of calculating opportunity. Each target’s asset is known to exist within the scope. Unknown assets are only at risk of being discovered, not of being targeted.

  • Analysis: In the specific case of (request for) submission, the visibility of a specific wallet credential or assertion wallet will be limited as much as possible when the website requests it. This is best handled at the user-agent level, or, where possible, hidden from it and routed directly to the Wallet.

• Access

  • Description: Access in OSSTMM is precisely when you allow interaction.

  • Analysis: In this case, the only way to do this is with the available API subset, which is expected to be a specific request.

• Trust:

  • Description: Trust in OSSTMM is when we leverage an existing trust relationship to interact with the asset. Normally, this involves a "relaxation" of the security controls that otherwise manage the interaction.

  • Analysis: This specific case should have no trusted access. However, the interaction could be triggered when asking permission for powerful features. Consider avoiding or limiting this over time, balancing Trust with Subjugation.

• Authentication:

  • Description: is control through the challenge of credentials based on identification and authorization.

  • Analysis: This can be considered the Trust of the issuers and the signatures (in the OSSTMM definition, Identity, Authentication, and Authorization are collapsed in the Authentication).

• Indemnification:

  • Description: is a control through a contract between the asset owner and the interacting party. This contract may serve as a visible warning, a precursor to legal action if posted rules are not followed, specific, public legislative protection, or a third-party assurance provider in case of damages, such as an insurance company.

  • Analysis: This is the agreement between the interacting parties, such as contracts. In this case, Notifications can describe what happens in a "secure" context (e.g., Payments API); all operations should be specifically authorized with Informed Consent. Holder should be notified if the Verifier asks for Full Disclosure, if the Issued Credentials do not support Selective Disclosure, or if it is phoning home.

    *Note: this can be used as a nudge, as used in behavioural economics, to guide Verifiers, Holders, and Issuers toward the intended behaviour.*

• Resilience:

  • Description: Control all interactions to protect assets in the event of corruption or failure.

  • Analysis: In this context, it means failing securely, which can be considered a failure in the case of cryptographic problems.

• Subjugation:

  • Description: It is a control that assures that interactions occur only according to defined processes. The asset owner defines how the interaction occurs, thereby removing the interacting party’s freedom of choice and liability for any losses.

  • Analysis: This control is especially relevant to credential presentation. The analysis should check that the interaction asks for the minimum information, if and when available (e.g., prioritize Predicates Proof, then Selective Disclosure, and, if none, the whole credential), similar to negotiation in SSL/TLS cipher selection.

• Continuity:

  • Description: controls all interactions to maintain interactivity with assets in the event of corruption or failure.

  • Analysis: This covers continuity when an interaction fails. In some cases, the safer response is to terminate the interaction. The Holder may also need a secure backup.

• Non-Repudiation:

  • Description: is a control that prevents the interacting party from denying its role in any interactivity.

  • Analysis: Non-repudiation raises logging questions: where logs are kept, who keeps them, and how they are protected. The Holder and Verifier may both need records of what happened, for example to show that access to a service was granted after a credential presentation. Those records also need privacy constraints.

• Confidentiality:

  • Description: is a control for assuring that an asset displayed or exchanged between interacting parties cannot be known outside of those parties.

  • Analysis: Cryptography can help provide confidentiality. Post-quantum cryptography (PQC) readiness is one consideration. One response is to limit a credential’s lifetime and reissue it with a more secure cryptographic suite.

• Privacy:

  • Description: is a control for assuring that the means of how an asset is accessed, displayed, or exchanged between parties cannot be known outside of those parties.

  • Analysis: This mainly concerns Unlinkability and minimization, as described before. In the Digital Credentials API context, this also includes preventing third parties from unnecessarily learning about the end-user’s environment (e.g., which wallets are available, their brand, and their capabilities).

• Integrity:

  • Description: It is a control to ensure that interacting parties know when assets and processes have changed.

  • Analysis: The credential and its presentation to be verified are expected to be cryptographically signed.

• Alarm:

  • Description: is a control to notify that an interaction is occurring or has occurred.

  • Analysis: Users need notification and control when an interaction happens, particularly when it scores poorly on the Unlinkability Scale or Minimization Scale. For example, the Issuer might use a technology that "calls home," or the Verifier might ask for data that could be minimized.

2.2.3.7. Responsible Innovation (Harms)

• Opportunity loss (Discrimination): Discrimination spans multiple areas. If digital identities are required for access to public services, no alternatives are present, and access depends on specific hardware, software, or stable connectivity, people without those resources can be excluded. Interoperability gaps between national technologies and implementations can create additional discrimination.

• Economic loss (Discrimination): Digital identities and related credentials can contain information about wealth status and can be used to discriminate in access to credit. A W3C breakout session also identified concerns related to the Jevons paradox: the more information is available in this mode, the more likely it is that collection, particularly in greedy data-driven contexts, is abused.

• Dignity loss (Dehumanization): If the vocabulary does not correctly describe people’s characteristics, this can reduce or obscure their humanity and characteristics.

• Privacy Loss (Surveillance): if this technology is not designed and implemented properly, it may enable Surveillance by state and non-state actors such as government and private Surveillance providers. For example, centralized or federated models are more prone to these threats, while decentralized models are less so; however, this depends on how they are implemented. Privacy-preserving technologies need to be available and implemented properly.

2.2.4. Other Threats and Harms

2.2.4.1. Government-issued credentials

For government credentials issued to people, the following use cases illustrate additional threats:

• In some countries, at-risk workers who are taken abroad have their passports seized by those who exploit them so that they can be controlled. Digital Credentials can reduce this threat because they are intangible and can be regenerated after theft. The remaining question is how the threat agent would adapt and what responses, often process responses rather than technical measures, governments can implement.

• Normally, we assume that the Holder of the credential is also the Subject to whom the credential refers. This is not necessarily the case.

  • Delegation of a credential is one relevant case, although this document uses the term delegation loosely because questions such as Guardianship have a precise legal meaning. Delegation can help prevent abuse and identity theft, and should be modeled as Issuer rules at the upper layers of the architecture.

  • Delegation can also matter when a government generates a credential at the organizational level and legal representatives use it on behalf of the organization.

2.2.4.2. Credentials used for authentication

Another scenario is the use of a credential for authentication:

• In contrast to what can happen with credentials in other identity models, where credentials are used primarily for authentication, it can be risky to use a credential issued by an issuer to authenticate to a service that is not under the control of the Issuer, as a malicious issuer could generate a parallel ad-hoc credential to authenticate. For example, it may not be a good idea to log in to your personal e-mail account with a government-issued credential, such as a passport.

Other threats to consider:

• Identity leakage

• Identity impersonation

2.2.4.3. Societal Threats

Other threats to consider as specified in the Team report on Federated Identity Working Group Charter Formal Objection - Adding Digital Credentials API:

• Perpetuates sharing of personal data by making it more available via a browser API.

• Increased centralization through subtle tradeoffs.

• Content will be moved from the deep web to the “attributed deep web”.

• Exchanges user agency for greater compliance and convenience.

2.2.4.4. Socio-technical Threats

This section records results from a threat modeling activity that combined cards derived from A Framework for Institutional and Technical Harm Prevention Inspired by Microsoft’s Harms Modeling with LEGO SERIOUS PLAY. The activity was applied in a series of workshops analyzing decentralized identity in the context of national digital identity systems.

A key finding is that the analysis should not just look at individual threats. It needs to consider their context and how they connect. For example, constraining how a person can present identity, making enrolment effectively compulsory, or tying access to a single official wallet path can create conditions for additional downstream threats.

This section captures those relations as connected threats. While not every deployment follows the same pattern, these threats should not be viewed as isolated events. In government-issued digital credential systems, it is more useful to view them as part of a propagation path, similar to a "kill-chain" model. Different patterns were identified:

• Restriction of identity multiplicity, profiling, and censorship. Participants repeatedly returned to the idea that forcing a person into one stable identity, or one acceptable proof path, makes profiling easier. Once behaviour can be linked back to the same holder over time, the profile becomes actionable. Censorship is then no longer a separate problem; persistent visibility can enable later intervention. This is why the connection between multiplicity and profiling was treated as strong. Limiting a holder to one identity cannot be treated only as a usability or policy choice. It can function as a profiling infrastructure. For example, if the issuer generates or signs a special anonymous credential to express a single claim or attribute (e.g., in the case of Age Verification), even where the issuer does not observe each use directly, repeated requests for additional capacity, combined with the metadata, can still support inference. In this case, an issuer may have enough information to correlate user behaviour, in particular in the case of collusion with a verifier.

• Forced association, overreach, and surveillance. Where enrolment is not realistically optional, the identity system stops being a neutral mechanism for facilitating presentation and becomes a gate through which access is forced to pass. This was represented in different connected landscapes of threats. Forced association was treated as an entry condition because it exposes the person to the rest of the system, whether or not that person would otherwise choose to participate. Once that condition holds, surveillance is no longer only an implementation defect or abuse case. It becomes structurally easier.

• Exclusion from the official wallet or application path. Several workshop models did not view exclusion as just non-participation. It has two effects: excluded people may lose access to official services, be drawn to unofficial or harmful apps, disclose more data than necessary, and be more vulnerable to fraud or exploitation. Meanwhile, those who can access the official path gain relative privilege. This is not just a technical interoperability issue; it is a stratification problem within the identity ecosystem.

• Connection between classification, discrimination, denial of identity, and loss of participation. An identity system may begin by managing claims needed for a narrow transaction and then expand into a classifier of persons. Once that happens, the system can support discriminatory vetting, exclusion from services, denial of access to the system itself, and, in the more severe cases discussed in the workshops, practical denial of political or civic participation. Here again, the issue is not one isolated failure. The problem is that a classification function, once operationalised, can be transferred.

• Identity theft. This threat appeared differently. In one workshop landscape, it was intentionally left less connected because participants did not identify a strong direct dependency between identity theft and the other threats in that specific model. That distinction should be preserved. The purpose of connected threats is not to force links where the model does not support them. At the same time, other workshop scenarios did show a meaningful chain from identity theft to profiling, suspicion, discriminatory targeting, and effective exclusion from the system. In this case, identity theft, as a fraudulent event, was the starting point for persecution directed at the wrong person.

A system may look secure and privacy-preserving at one interface and still produce an adverse social impact if it normalizes forced enrolment, persistent correlation, discriminatory classification, or exclusion from the channels through which social, civic, or economic life is conducted.

For that reason, connected threats are an additional analytical layer. They do not replace security or privacy analysis. They make visible how local design choices accumulate.

These workshop outputs suggest that threat modeling for decentralized credentials should account for propagation across layers: from credential design, to wallet and issuer behaviour, to governance choices, to participation conditions.

Single threats are:

• Loss of representation: A person is excluded from the identity system and can no longer access services or participate in society because their existence is not recognized by the digital infrastructure.

• Discrimination: A user is denied access to a service because automated policies classify them negatively based on characteristics contained in the digital credential.

• Profiling and “identity stacking”: Continuous profiling and aggregation of identity data can create a system where users cannot escape.

• Political chilling effect: People avoid political participation or advocacy because they fear that their digital identity could expose them to retaliation or surveillance.

• Forced association: Individuals are forced to join or identify through a specific organization or identity framework in order to access essential services or prove who they are.

• Denied right to an identity: Existing barriers in authentication and authorization systems are exploited to deny individuals access to a valid digital identity.

• Surveillance and censorship: Constant monitoring and surveillance restrict freedom of expression by making people feel permanently observed and controlled.

• Function creep: Data originally collected for one purpose is gradually reused for additional purposes beyond what the user initially consented to.

• Fear of persecution: As these actions can be tracked by government, fear of being tracked, punished, or persecuted causes individuals to self-censor and limit their freedom of speech and movement.

• Identity theft: A malicious actor uses stolen identities to impersonate other people and gain unauthorized access to systems or services.

• Phishing: An attacker tricks an employee through a fraudulent email into revealing credentials or executing malicious actions, resulting in sensitive data leakage. The impact can be significant if the compromised credentials are high-level credentials.

• Denial of healthcare: Failures or restrictions in digital identity systems prevent individuals from receiving timely medical care, potentially causing serious harm to their health or life.

• Digital censorship: Identity systems can be used to selectively block or allow access, enabling censorship and exclusion based on who the user is, as an abuse case after the technology is deployed for a purpose such as child protection.

• Statelessness: A person’s digital identity is considered invalid or fraudulent, effectively excluding them from social participation and access to essential resources.

2.3. What are we going to do about it?

Potential responses and features:

• Signature Blinding: is a type of digital signature in which the content of the message is concealed before it is signed. With public-key cryptography, the signature can be correlated with the signer’s public key, which is useful when the recipient needs to verify the sender. Zero-knowledge proof (ZKP) methods can instead provide cryptographic proof of signature without giving the Verifier additional information about who signed, protecting the Holder’s public key.

• Selective disclosure: is the ability to show only a part (claim) of the credential and not all of it, or show only possession of that credential, as needed in the context of the transaction. For example, a Holder can show only the date of birth rather than the entire driver’s license number. This further minimizes the data sent to the Verifier.

• Predicate Proofs and Range Proof: is the ability to respond to a Boolean assertion (true/false) to a specific request, which is an additional step for privacy and minimization. For example, if the Holder needs to prove that they are of age, the proof can answer that question without disclosing the date of birth.

• Anonymous Revocation: A credential has its life cycle: it is issued, it is used, and then it can be revoked for various reasons. Therefore, a verifier needs to be able to verify whether the credential has been revoked, without allowing the ability to correlate information about other revoked credentials. There are different techniques:

  • Revocation List: This is the current generally used approach, although it creates privacy issues, as the lists are public and typically contain user information.

  • Status List: revocation document only contains flipped bits at positions that can only be tied to a given credential if you’d been privy to the disclosure of their association.

  • Status Assertions: is a signed object that demonstrates the validity status of a digital credential. These assertions are periodically provided to holders, who can present them to the Verifier with the corresponding digital credentials.

  • Cryptographic accumulators: can generate proof of validity without exposing other information.

• Rotational Identifiers: As indicated by the Security and Privacy Questionnaire, identifiers can be used to correlate, so it is important that they are temporary as much as possible during a session and changed after they are used. In this context, the identifiers that can be exploited to correlate can be present at different levels.

• No Phoning home or back-channel communication: Software often "calls home" for several reasons. They normally do this to collect usage or crash statistics (which could indicate a vulnerability). The problem is that this feature, often critical to software improvement and security, has privacy implications for the user, in this case, the Holder. At the Credentials level, this call can be made at different times and by different agents. For example, the Issuer might be contacted by the Verifier to check the revocation of a credential, or the Wallet might contact its vendor to collect usage statistics. In those cases, two response patterns are relevant:

  • Do not phone home or back-channel communication: This could also be an operational necessity (several use cases require the presentation to be made in offline environments or with limited connection) or a choice of the Holder, who should always consent to telemetry and external connections to third parties.

  • Minimize and Anonymize the Data: Limit the data passed or, even better, cryptographic privacy-preserving techniques like STAR that implement k-anonymity for telemetry.

  • Using Privacy-Preserving DIDs: When resolving a DID, the method may use a connection to a system for resolution. If this system is under the direct or indirect control of the Issuer, it generates potential privacy issues. For example, this typically happens with did:web as mentioned in section 2.5.2 where a GET is generated that retrieves a file, effectively exposing the requesting user agent and allowing the Issuer to make statistics.

• Notification/Alerts: Interactions that require the user to present an Internet credential need communication with the user at the following times:

  • Before the request for the proof: for example, a website requests age verification, permission should first be given to the website to access the functionality, and when the user decides whether or not to give access, the URL and type of credential requested and the level of Minimization (to discourage you know the Verifier and the Holder from using Full Disclosure) should be indicated in a secure context.

  • Before sending the proof, the user selects the Wallet of their choice, the credential or set of credentials from the Wallet, and the specific claims from the credentials. The Holder should be notified and asked for confirmation and consent, particularly when the selected presentation includes phone calling or back-channel communication features (to discourage the Issuer and Verifier from these practices).