Threat Model for Decentralized Credentials

1. Introduction

1.1. Scope

The topic of Digital Identities is vast and intricate. Defining the initial scope of the model, which can be expanded when necessary, if we consider the ecosystem of Digital Identities, we find ourselves in the specific case of Decentralized Identities, those identities related to people and in particular those considered high-assurance (e.g., those issued by governments) and in the Layer 3: "Credentials" and precisely the Credential-Presentation Phase - as defined by the SSI Technology Stack from ToITP and DIF FAQ and as written in the Identity & the Web Report:

On the one hand, the need arose within the W3C about the potential adoption of the Digital Credentials API - which would allow User-Agents to mediate communication between a website requiring the submission of evidence and the user’s Wallet - by the Federated Identity Working Group, on the other hand the lack of a more general model analyzing threats on the various levels related to Security, Privacy, and Human Rights was also identified.

As the Threat Model is a living document, it can be expanded to include other parts of the architecture and to a different level of detail, e.g., going deep into the cryptographic aspects of a specific profile or expanding it into the broader governance context to identify or mitigate threats.

It is also important to note that because it is a generic model, it is useful for understanding the properties and requirements needed for Security, Privacy, and Harm. Therefore, it is important to carry over these properties later into the specific architecture or implementation, which is defined precisely by architectural and technological choices (e.g., a profile).

It is intended to be a choral analysis. It stems from the need to understand a Threat Model to guide the development of Decentralized Identities in a secure/privacy-preserving way and avoid harm. It will start from the Digital Credentials API from a high-level perspective.

1.1.1. Terminology

For Identity, we can refer to the definition in ISO/IEC 24760-1:2019 "IT Security and Privacy - A framework for identity management".

Identity is "a set of attributes related to an entity". Where the entity is something "that has recognizably distinct existence", and that 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" and the 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 we can map the ISO’s attributes to VCDM claims.

For example, a person’s characteristics can include physical appearance, voice, beliefs, habits, and so on. It is important to distinguish identity from an identifier (e.g., a username).

It is usual to think of Digital Credentials as related to humans, particularly those issued by a government, also known as "Real-world Identities", even if we also have Non-Human Identities.

This leads to a broader consideration of the Threat Model, as it also includes Privacy as a right and Harm components.

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

Since security is a _separation function between the asset and the threat_, the threat can have different impacts, such as security, privacy, or harm.

There are many approaches to Threat Modeling. The first approach we will use is based on Adam Shostack’s four-question frame:

• What are we working on? (understanding the architecture, actors involved, etc...)

• What can go wrong? (threats, threat actors, attacks, etc...)

• What are we going to do about it? (countermeasures, residual risk, etc...)

• Did we do a good job? (Reiterating until we are happy with the result)

For the central phases, it is possible to use (as in Risk Management) prompt lists or checklists of either threats, attacks, or controls, for example:

• Solove’s Taxonomy

• Privacy Patterns

• Privacy Principles

• LINDDUN

• RFC 6973

• RFC 3552

• STRIDE

• OSSTMM v3

• Microsoft’s Types of Harm

It is useful to frame the analysis with OSSTMM. OSSTMM controls allow analyses of what can go wrong (e.g., a control not present or a control problem).

Even if it is control-oriented and seems security-oriented, privacy is an operational control that can connect different pieces.

1.4. Channel and Vector

OSSTMM is very precise when used to analyze, so it defines a channel and a vector.

For an accurate analysis, we consider the COMSEC Data Networks Channel in the specific Internet/Web vector for this issue.

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?

To create a good Threat Model, we can first consider the components of the Decentralized Identity architecture (which in this context is synonymous with Self-Sovereign Identity) as defined in W3C’s Verifiable Credentials Data Model and how they interact.

2.1.1. Architecture and Actors

• We have a Holder who, inside a Wallet, has its credentials.

• We have an Issuer who issues the credentials to the Holder and manages the revocation.

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

• We also have a Verifiable Data Registry (VDR) that stores identifiers and schemas.

Interactions between actors occur normatively through software or other technological mediums. We will generically call such components Agents. One agent might be embedded in a Wallet (the component that contains the Holder’s credentials), and another might be a Browser (which, by definition, is a user agent).

2.1.2. Flows

We can consider three general flows, with four "ceremonies" where the various actors interact.

• Credential-Issuing

• Credential-Presentation and Credential-Verification

• Credential Revocation

It is important to note that the flow stops here and can be safely continued 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. So the Verifier could become an Issuer to issue a certificate of authenticity for good 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 must trust the Issuer during Verification.

• All actors trust the record of verifiable data.

• Both the holder and verifier must trust 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. JSONs are enveloped using JSON Object Signing and Encryption (JOSE), and we can find JWT, JWS, and JWK here. JOSE is "cryptographically agile" (as it can fit different cryptographic primitives) and can also have 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, we can consider the protection of its three Privacy Properties, as they were defined by Ben Laurie, as the basis:

• 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.

While we can, therefore, consider the Minimal and Unlinkable properties as elements of the Holder, the Verifiable property is of interest to all. 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.

Therefore, the Threat Model wants to start with this specific use case: government-issued credentials for people, as it is one of the most complex.

Minimization and Unlinkability are generally interrelated (e.g., the less data I provide, the less they can be related). They must coexist with Verifiability (e.g., if I need to know that the credential has been revoked, I usually need to contact the Issuer, which maintains a list of revoked credentials, but this approach allows linking the credential).

2.1.5.1. Minimization Scale

To try to qualify Minimization, we can use a scale defined by the various cryptographic techniques developed for Digital Credentials:

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

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

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

• Range Disclosure (e.g., I show only that I am an adult).

2.1.5.2. Unlinkability Scale

To try to qualify Unlinkability, we can use the Nymity Slider, which classifies credentials by:

• 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).

Therefore, it might be possible to consider "moving" the slider toward Unlinkable Anonymity, as per the properties.

2.2. What can go wrong?

After reasoning about assets, what we can protect and "who" becomes obvious.

2.2.1. Threat Actors

We have mentioned before that one of the key points is protecting the Holder. Still, by simplifying and referring to the well-known practice of "trust no one", we can easily get the list of actors involved:

Holder, Issuer, Verifier, and their agents/software components (e.g., Browser, Wallet, Websites). Which of these can be a Threat Actor? To simplify the question, each actor may be a Threat Actor to the others. So, all against all. Indeed, one is often also a Threat Actor to oneself (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. Specifically, 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 push users toward certain attitudes.

One must also 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.

A further case is the combination of such actors, such as multiple _Verifiers_ in cahoots or a potential collaboration between Issuer and Verifier to track the Holder.

2.2.2. Evil user stories

Using the information we now have, we can create some generic Evil User Stories:

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

• A malicious Holder who wants to get what he is 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: There’s often no point in making a statement unless the relying party has some way of checking whether it is true. Note that this isn’t always required—I don’t have to prove my address is mine to Amazon because it’s up to me where my goods are delivered. But I may have to prove I’m over 18 to get alcohol delivered.

  • 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 bit - I want to tell the relying party the very least he needs to know. I shouldn’t have to reveal my date of birth or prove I’m over 18 somehow.

  • Analysis: We must release only what is strictly necessary. Since this is an interaction, we consider Subjugation an interactive OSSTMM control. For example, if we need to verify age with our credentials, it is one thing to show the whole document or the date of birth (Selective Disclosure) or to answer a specific query with true-false (Predicate Proofs). This property also helps Unlinkability (the less data I have, the less correlation I can do).

• Unlinkable:

  • Description: If the relying party or parties, or other actors in the system, can, either on their own or in collusion, link together my various assertions, then I’ve blown the minimality requirement out of the water.

  • Analysis: It must be minimal. 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: We are generally driven to think of this as a threat to the Holder and linking its attributes, but per se, even an Issuer can have the problem of tracking its users. This applies to a Verifier (or a group of Verifiers) and an external third party observing the various exchanges or the Revocation list.

  • Mitigations:

    • 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.

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

    • The Issuer and the Holder must not write 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.

  • Mitigations

    • Depending on the Levels of Assurance (LOAs), the issuer must use proper authentication during the issuing process.

    • Proper logging must be maintained by the issuer, the Verifier, and the Holder (and their agents), e.g., following the OWASP. ASVS 7.1 e.g., each log must 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.

  • Mitigations:

    • When proof or a credential is requested, the Holder agent must 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.

  • Mitigations:

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

    • The Issuer and the Holder must not write 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.

  • Mitigations:

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

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

    • The Holder must consent to each use of their credential and must 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.

  • Mitigations:

    • Provide Security Awareness Training to the Holder

    • Verifier and Issuers must be subjected to regular audit

    • The standards and their implementation must contain mitigations for 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: Although we can semantically link this threat to surveillance of governments (precisely of the Holder or an adversary), we can actually consider surveillance also related to profiling for targeted advertising (and thus from software agents also used to trust the Holder) or even of threat actors such as stalkers or similar.

  • Mitigations

    • 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. Therefore, they must be considered, especially when implementing wallets and agents (for the Holder), compromising the end-user device and the Issuer's signature keys.

  • Mitigations:

    • Keys must 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 must 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

  • Mitigations:

    • 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.

  • Mitigations:

    • Refer to LINDDUN’s Non-Reputiation

• 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.

  • Mitigations:

    • 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.

  • Mitigations:

    • 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

  • Mitigations:

    • 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 that asks for more data than needed.

  • Mitigations:

    • 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.

  • Mitigations:

    • Refer to LINDUNN’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.

  • Mitigations:

    • 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).

  • Mitigations:

    • 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.

  • Mitigations:

    • 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.

  • Mitigations:

    • 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

  • Mitigations:

    • Refer to LINDDUN’s Non-Repudiation.

• Information disclosure (Threat to Confidentiality and Privacy):

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

  • Mitigations:

    • Refer to LINDDUN Data Disclosure.

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

  • Description: Exhausting resources needed to provide service

  • Mitigations:

    • Use a decentralized VDR for verification

  • Elevation of privilege (Threats to Authorization):

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

    • Mitigations:

      • 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. The whole thing must be handled at the user-agent level—or even better. It has to be hidden from it and go 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 must 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 whole thing 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 must be specifically authorized with Informed Consent. Holder must 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 (used in Behavioural Economics) and then can be used to educate the Verifiers, Holders, and Issuers to do the right thing.*

• 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 is a particularly interesting aspect based on the context. As mentioned earlier, one would need to make sure that one is always asked for the minimum information, if and when available (e.g., prioritize Predicates Proof, then Selective Disclosure, and, if none, the whole credential), somewhat like what happens in SSL/TLS with ciphers.

• Continuity:

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

  • Analysis: This is the concept of continuity balancing in case of problems, although in this case, if there are problems, it’s the case to terminate the interaction. But in general, the holder needs a secure backup.

• Non-Repudiation:

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

  • Analysis: The issue of non-repudiation is interesting, and it makes me think about the logging issue, where it should be done, by whom, and how. It requires a strong trust element. Still, in general, it’s useful for the Holder to have the log of what happened and probably the Verifier as well (e.g., in case of checks of having given access to a certain service by those who had the right to do so, having presented a credential, but what to keep considering privacy as well)?

• Confidentiality:

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

  • Analysis: One of cryptography’s important aspects is how effectively it can guarantee confidentiality. A point can be post-quantum cryptography (PQC) readiness. A countermeasure is limiting a credential’s lifetime and reissuing 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: mainly Unlinkability and minimization, as described before. In the Digital Credentials API context, this also includes preventing third parties from unnecessarily learning anything 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 must be cryptographically signed.

• Alarm:

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

  • Analysis: It is important to notify users and then allow when an interaction happens, particularly when it has low values related to the Unlinkabiity Scale or Minimization Scale; this can happen for several reasons. For example, the Issuer uses a technology that "calls home," or the Verifier asks for data that could be minimized instead.

2.2.3.7. Responsible Innovation (Harms)

• Opportunity loss (Discrimination): Discrimination spans multiple areas. Digital divide: if digital identities are required for access to public services and no alternatives are present, and if they depend on certain hardware, software, or stable connectivity, it can lead to Discrimination for people who do not have access to these resources, in addition to Discrimination within the interoperability between the technologies and implementations used by different governments.

• Economic loss (Discrimination): the Discrimination of digital identities and related credentials, which can contain a lot of information regarding wealth status, can be used to discriminate against access to credit. This can also be generalized, as was identified during a W3C breakout session, concerns the Jevons paradox. The more information 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 be subject to 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. Therefore, it is necessary to provide privacy-preserving technologies and implement them properly.

2.2.4. Other Threats and Harms

2.2.4.1. Government-issued credentials

Considering the specific case of government credentials issued to people, it is useful to think about some use cases:

• 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 generally mitigate this, as they are intangible; they can be regenerated in the event of theft. A further consideration is how the threat agent will act in this situation and what mitigations (more process than mere 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.

  • One particularly useful and interesting aspect is the delegation of a credential (we use the term delegation loosely, as questions such as Guardianship have a precise legal meaning). This prevents abuse and identity theft, and should be properly modeled as Issuer rules at the upper layers of the architecture.

  • Also, delegation could be a crucial feature if the government generates a credential at the organizational level, which is then used by legal representatives (who are people).

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.3. What are we going to do about it?

Countermeasures/Features:

• **Signature Blinding**: is a type of digital signature for which the content of the message is concealed before it is signed. With Public-Private Key Cryptography, the signature can be correlated with the signer’s public key (and this is an important feature when we want to be sure of the sender, as in GPG). Zero-knowledge cryptographic methods do not reveal the actual signature. Instead, with ZKP, we can send a cryptographic proof of signature without providing the Verifier with any other information about who signed. Thus, 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, we can show only the date of birth rather than the entire driver’s license number. This allows us to minimize further the data sent to the VerifierPredicate Proofs and Range Proof**: 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 we say we are of age, I don’t have to show just the date of birth; I can compute the answer.

• 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 must 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 must be 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, suppose the Issuer is contacted by the Verifier to check the revocation of a credential, or that the Wallet contacts its vendor to collect usage statistics. In that case, we can consider two types of countermeasures:

  • 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: An important aspect, particularly about interactions where the user is required to interact through an Internet credential, is communication with the user, which occurs at the following times

  • Before the request for the proof: for example, a website requests age verification, permission must 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) must be indicated in a secure context.

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