diff --git a/index.bs b/index.bs index ff04f77..38a5f60 100644 --- a/index.bs +++ b/index.bs @@ -50,13 +50,13 @@ When we think about identity, we often think about our identity as individuals. Analyzing the etymology, the term **identity** comes from the Latin root “*idem*”, which means “*the same*” [[oxford-etymology-identity]] so while it's an intimate concept, we also use it to distinguish ourselves from others. This is well explained in the Cambridge Dictionary in which the identity is “*the fact of being, or feeling that you are, a particular type of person, organization, etc.; the qualities that make a person, organization, etc. different from others*” [[cambridge-dictionary-identity]]. -Thus, *"from a sociocultural perspective, an individual’s identity is socially constructed, forming from early childhood from their interactions and relationships with others"* [[constructing-an-identity]]. Therefore, our identity is tied to society and the third parties we interact with and which, often, provide us with an identity, the elements to refer to it and to prove who we are. +Thus, *"from a sociocultural perspective, an individual’s identity is socially constructed, forming from early childhood from their interactions and relationships with others"* [[constructing-an-identity]]. Therefore, our identity is tied to society and the third parties we interact with, which often provide us with an identity, the elements to refer to it, and to prove who we are. Looking more closely at the Information Technology (IT) domain, the ISO/IEC 24760-1:2019 [[ISO-IEC-24760-1]] defines **Identity** as “*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*". These **attributes** are “*characteristics or properties*” such as “*an entity type, address information, telephone number, a privilege, a MAC address, a domain name*”. To complete the definition of *entity* and *identitfiers*, it is important to note that they always refer to a **domain** of applicability, the specific *context* where they can be used (e.g., an organization, a country, a university). Thus, a particularly important point is clear: there are not only identities of people, individuals, or human beings. We can also have identities for organizations, pets, and **Non-Human Identities** (NHI). NHI are all those accounts widely used by “devices, services, and servers” in networking, cloud, and workloads [[the-evolving-landscape-of-non-human-identity]]. -Now, an important logical step. To claim our identities, we present **credentials**, 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 credential, as it changes according to context. Starting with the definition from the Cambridge Dictionary, a (digital) credential is “*a piece of information that is sent from one computer to another to check that a user is who they claim to be or to allow someone to see information*” [[cambridge-dictionary-identity]]. While high-level, this definition considers two important aspects: on the one hand, the credential is used to prove our claims, such as who we are, and on the other hand, it can be used to gain access to information: +Now, an important logical step. We present **credentials** to claim our identities, 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 credential, as it changes according to context. Starting with the definition from the Cambridge Dictionary, a (digital) credential is “*a piece of information that is sent from one computer to another to check that a user is who they claim to be or to allow someone to see information*” [[cambridge-dictionary-identity]]. While high-level, this definition considers two important aspects: on the one hand, the credential is used to prove our claims, such as who we are, and on the other hand, it can be used to gain access to information: * The **ISO/IEC 24760-1** definition is very close to the last aspect from the dictionary, where a credential is a “*representation of an identity for use in authentication*” [[ISO-IEC-24760-1]]. * The **Identification for Development (ID4D)** definition is close to the first aspect: “*any document, object, or data structure that vouches for a person’s identity through some method of trust and authentication*” [[types-of-credentials-and-authenticators]]. @@ -65,15 +65,15 @@ Now, an important logical step. To claim our identities, we present **credential Note: Therefore, we will refer to the specific definition of credential in the various sections of the document according to the context. -These definitions introduced important concepts such as *identifiers*, *authentication*, and *trust* that are good to clarify. +These definitions introduced important concepts that need clarification, such as *identifiers*, *authentication*, and *trust*. -**Identifiers** are *pieces of information used to uniquely refer to an entity within a specific context*. According to the W3C Decentralized Identifiers, there are various types of identifiers: “*communication addresses (telephone numbers, email addresses, usernames on social media), ID numbers (for passports, driver's licenses, tax IDs, health insurance), and product identifiers (serial numbers, barcodes, RFIDs). URIs (Uniform Resource Identifiers) are used for resources on the Web, and each web page you view in a browser has a globally unique URL (Uniform Resource Locator)*” [[did-core]]. +**Identifiers** are *pieces of information that uniquely refer to an entity within a specific context*. According to the W3C Decentralized Identifiers, there are various types of identifiers: “*communication addresses (telephone numbers, email addresses, usernames on social media), ID numbers (for passports, driver's licenses, tax IDs, health insurance), and product identifiers (serial numbers, barcodes, RFIDs). URIs (Uniform Resource Identifiers) are used for resources on the Web, and each web page you view in a browser has a globally unique URL (Uniform Resource Locator)*” [[did-core]]. Note: Although entity, identity, and identifier are related, they are distinct: Identity refers to the essence of who or what an entity is, while an identifier is a specific piece of information used to recognize and refer to that entity uniquely. Let us then try to understand the *authentication* process and how it differs from identification, verification, and authorization: -* **Identification** is recognizing an entity through the information it provides. For example, we enter our first name, surname, and email address in a social network (and there are different levels of proofing of our real-identity). +* **Identification** is recognizing an entity through the information it provides. For example, we enter our first name, surname, and email address in a social network (and there are different levels of proofing of our real identity). * **Verification** allows us to confirm that the presented information is valid through further testing. Verification is a generic process that can take different forms and have different effects. For example, we often receive an email with a confirmation link to verify an email address. We confirm that the email address is under our control by clicking on it. This type of verification demonstrates control over the identifier. Verifying identity information online, such as a specific name and surname, is more complex. When verifying identity information, we use the term *identity verification*. * **Authentication** is a specific, *formal* verification type that aims to grant access to a resource, service, or information. This process usually involves verifying control of our identifier with something we know (e.g., a password), something we have (e.g., a hardware token), or something we are (e.g., a biometric characteristic). For instance, similar to the email example, we demonstrate control over a username (the identifier of our identity) by entering the corresponding password. * **Authorization** is another key process that follows authentication. It verifies whether our authenticated identity has the necessary permissions to access a particular resource. This step ensures that we are only granted access to resources we can use even after confirming our identity. @@ -97,11 +97,11 @@ Therefore, it’s important to remember that we can have digital credentials tha We introduce the last topic with the example of credentials that universities can issue. In addition to degree certificates, universities usually have student ID cards containing information such as first name, last name, and photo. -Why can a driver’s license and a student ID card, both having the same attributes and being cryptographically verifiable, only allow the driver’s license to be used to open a bank account? +Why can a driver’s license and a student ID card, having the same attributes and being cryptographically verifiable, only allow the driver’s license to open a bank account? There are several aspects, first of all, the *context* and *domain* in which the credential lives. The key difference lies in the **trust** we place in the issuers of these credentials. Trust can be defined as "*the belief that someone is good and honest and will not harm you, or that something is safe and reliable*" [[cambridge-dictionary-trust]]. Essentially, trust is a choice we make; we choose to trust or not trust someone or something [[OSSTMM-3]], and often, it is not a binary question. -*Cryptographic trust*, such as verifying a credential, is not the same as *human trust* [[self-sovereign-identity]]. Cryptographic methods ensure that the credentials haven’t been tampered with. Human trust involves trusting the entity that issued the credential and that the issuer provided the credential to the legitmate user. +*Cryptographic trust*, such as verifying a credential, is different from *human trust* [[self-sovereign-identity]]. Cryptographic methods ensure that the credentials haven’t been tampered with. Human trust involves trusting the entity that issued the credential and that the issuer provided the credential to the legitimate user. This is why we also need **governance frameworks** or **trust frameworks**. These frameworks include business, legal, and technical rules that help establish and maintain trust in the issuers of credentials. @@ -136,11 +136,11 @@ However, target 16.9 of the 2030 United Nations Sustainable Development Goals (S Digital identities and credentials are powerful business enablers and offer significant opportunities for individuals, governments, and organizations. -They can guarantee other rights, such as the right to accessibility promoted by the *Marrakesh Treaty* [[marrakesh-treaty]], and to "*empower refugees, stateless individuals, and forcibly displaced persons*" [[UNHCR-digital-identity]]. +They can guarantee other rights, such as the right to accessibility promoted by the *Marrakesh Treaty* [[marrakesh-treaty]] and the right to "*empower refugees, stateless individuals, and forcibly displaced persons*" [[UNHCR-digital-identity]]. -These technologies can also be used on a humanitarian level. Referring to the NHIs, the International Committee of Red Cross (ICRC) investigated *Digital Emblems* [[ADEM]] to identity ICT assets protected under international law [[digitalizing-report]]. +These technologies can also be used on a humanitarian level. Referring to the NHIs, the International Committee of Red Cross (ICRC) investigated *Digital Emblems* [[ADEM]] to identify ICT assets protected under international law [[digitalizing-report]]. -Note: However, like all innovations, these technologies can have downsides. To paraphrase Paul Watzlawick, the innovation of these technologies must not become “*ultra-solutions*” where “*operation successful, patient dead*” [[ultra-solutions]]. So, the challenge is to enable this technological innovation by being aware of the threats, not only to privacy and security but also to human rights. +Note: However, like all innovations, these technologies can have downsides. To paraphrase Paul Watzlawick, the innovation of these technologies must not become “*ultra-solutions*” where “*operation successful, patient dead*” [[ultra-solutions]]. So, the challenge is to enable this technological innovation by being aware of the threats to privacy, security, and human rights. So, the challenge is enabling this technological innovation by being aware of the threats to Privacy, security, and Human Rights. Therefore, it is necessary to analyze the various threats to mitigate them at their root in designing and implementing these technologies and related standards. @@ -149,7 +149,7 @@ As an example, below is an initial analysis of threats to human rights (Harms) c * **Opportunity Loss** (*Discrimination*): This complex issue 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 availability of these resources. In addition to discrimination within the same country, there is further discrimination if there is no “cross-border” interoperability between the technologies and implementations used by different governments. * **Economic loss** (*Discrimination*): The availability 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](https://github.com/w3c/breakouts-day-2024/issues/12) - and concerns the [Javons paradox](https://www.tandfonline.com/doi/abs/10.1080/15487733.2009.11908028). The more information available, the more likely it is that collection, particularly in greedy data-driven contexts, is abused. -* **Dignity loss** (*Dehumanization*): For example, if the vocabulary used does not correctly describe people’s characteristics, this can reduce or obscure people’s humanity and characteristics. +* **Dignity loss** (*Dehumanization*): For example, if the vocabulary does not correctly describe people’s characteristics, this can reduce or obscure people’s humanity and characteristics. * **Privacy Loss** (*Surveillance*): if this technology is not designed and implemented properly, it can lead to surveillance by state and non-state actors such as government and private technology providers. For example, centralized or federated models are more prone to these threats, while decentralized models are less so, but it depends on how they are implemented. Therefore, it is necessary to provide privacy-preserving technologies and implement them properly. # Digital identity management models # {#digital-identity-management-models} @@ -177,13 +177,13 @@ The centralized identity model is the typical scenario when the user logs in to Here is the simplified *Data Flow*: -* **Authentication**: The user authenticates themselves with the centralizdd system using their credentials. +* **Authentication**: The user authenticates themselves with the centralized system using their credentials. * **Access Granting**: This system grants access to the resource. Perspectives: * **Security**: there are different issues. For the *user*: password re-use in case of compromised password, so the user should use different passwords for different providers; there are also Phishing and Man-in-The-Middle attacks. From the provider’s point of view, as the passwords are stored on their systems, they need to implement proper security measures to protect them at rest and during transport. * **Privacy**: the centralized system can completely track the user. -* **Standards**: Standards intervene at different levels. In how credentials are exchanged and sent: historically, *Basic Autentication* [[RFC1945]], *Digest Authentication* [[RFC2069 obsolete]] (and related updates), and via *HTML forms* with `input type=password` and `Cookies` for maintaining the session information on the Client. Other standards for increasing authentication factors such as HTOP [[RFC4226 obsolete]] and TOTP [[RFC6238]]. Also, with with SSL/TLS [[RFC2246 obsolete]] (and related updates) for the protection of credential transport and and traffic in general. Other standards protecting the credentials at rest such as the (now obsolete) MD5 [[RFC1321]] and other [hashing algorithms by NIST](https://csrc.nist.gov/projects/hash-functions). +* **Standards**: Standards intervene at different levels. In how credentials are exchanged and sent: historically, *Basic Authentication* [[RFC1945]], *Digest Authentication* [[RFC2069 obsolete]] (and related updates), and via *HTML forms* with `input type=password` and `Cookies` for maintaining the session information on the Client. Other standards for increasing authentication factors such as HTOP [[RFC4226 obsolete]] and TOTP [[RFC6238]]. Also, with with SSL/TLS [[RFC2246 obsolete]] (and related updates) for the protection of credential transport and and traffic in general. Other standards protecting the credentials at rest such as the (now obsolete) MD5 [[RFC1321]] and other [hashing algorithms by NIST](https://csrc.nist.gov/projects/hash-functions).
Enabling passwordless credentials for authentication and payments
@@ -209,29 +209,29 @@ Here is the simplified *Data Flow*: * **Authentication**: The user sends their credentials to the IdP to authenticate. * **Obtaining Identity Assertions**: The IdP then creates an identity assertion, a verifiable confirmation of the user's identity. * **Sending Identity Assertions**: The user sends their identity assertion to the SP or RP. -* **Trust and Access**: The SP or the RP, trusting the IdP, accepts the Identity Assertion sent by the user and grants access. +* **Trust and Access**: The SP or the RP, trusting the IdP, accepts the user's Identity Assertion and grants access. Perspectives: -* **Security**: This model mitigates the user's issue of remembering multiple passwords, the identity fragmentation, and relieves the need for the SP or RP to manage the authentication aspects. +* **Security**: This model mitigates the user's issue of remembering multiple passwords and identity fragmentation and relieves the need for the SP or RP to manage the authentication aspects. * **Privacy**: this model still has some implications because the IdP knows what third-party services the user has accessed. Additionally, the technology uses "*third-party (cross-site) cookies that are considered harmful to the web and must be removed*" [[third-party-cookies-must-be-removed]]. * **Standards**: standards support interoperability between different systems. The most used in this context are [OASIS Security Assertion Markup Language (SAML)](https://www.oasis-open.org/standard/saml/) and [OpenID Connect](https://openid.net/connect/), which underpins [OAuth](https://oauth.net/) for authorization and different token formats.
Enabling Federated identity in the Web platform without third-party cookies
- The [Federated Identity Community Group](https://www.w3.org/community/fed-id/) was born to resolve these privacy concerns for this model. The Group is working on Federated Credential Management API [[FEDCM]] and other APIs such as Login Status API, to implement the Federated Identity Model in the Web Platform. The [Federated Identity Working Group](https://www.w3.org/groups/wg/fedid/) also came from this group to proceed with standardization. + The [Federated Identity Community Group](https://www.w3.org/community/fed-id/) was born to resolve these privacy concerns for this model. The Group is working on Federated Credential Management API [[FEDCM]] and other APIs, such as Login Status API, to implement the Federated Identity Model in the Web Platform. The [Federated Identity Working Group](https://www.w3.org/groups/wg/fedid/) also came from this group to proceed with standardization.
## Decentralized identity model ## {#decentralized-identity-model} -In the decentralized model, also known as the Self-Sovereign Identity (SSI) or three party model, the user independently administers their identities and is the highest expression of user-centric identity. It is the newest model, and several pilot projects are underway for large-scale implementations. +In the decentralized model, also known as the Self-Sovereign Identity (SSI) or three-party model, the user independently administers their identities and is the highest expression of user-centric identity. It is the newest model, and several pilot projects are underway for large-scale implementations. Note: We will examine the decentralized identity model more closely, as it is the source of new challenges. ### Architecture ### {#architecture} -The decentralized identity model marks a significant shift in architecture. Moving away from federated Identity Providers (IdPs) and Service Providers (SPs) or Relying Parties (RPs), the focus now centers on the user. +The decentralized identity model marks a significant shift in architecture. Instead of federated Identity Providers (IdPs) and Service Providers (SPs) or Relying Parties (RPs), the focus now centers on the user. -In this model, the user *controls* their credentials, acquires them from an *Issuer*, stores them in their *wallet*, and presents *them* to a Verifier. Verification activities are mediated by a *Verifiable Data Registry*, which contains the various information needed. +In this model, the user *controls* their credentials acquires them from an *Issuer*, stores them in their *wallet*, and presents *them* to a Verifier. Verification activities are mediated by a *Verifiable Data Registry*, containing the necessary information.
@@ -240,9 +240,9 @@ In this model, the user *controls* their credentials, acquires them from an *Iss
-To best understand the decentralized model and its end-to-end operation, we can refer to the model by Decentralized Identity Fundation [[did-faq]] build on the Trust Over IP architecture [[introduction-toip]] [[evolution-toip]]. +To best understand the decentralized model and its end-to-end operation, we can refer to the model by Decentralized Identity Foundation [[did-faq]] build on the Trust Over IP architecture [[introduction-toip]] [[evolution-toip]]. -This model comprises both technology and governance aspects, sliced in different layers.We will then provide an overview of the various layers, focusing on specific elements related to credentials and identifiers, which are considered the two pillars of decentralized identities. +This model comprises both technology and governance aspects, sliced into different layers. We will then provide an overview of the various layers, focusing on specific elements related to credentials and identifiers, considered the two pillars of decentralized identities.
@@ -254,76 +254,74 @@ Let us start by looking at the layers. #### Layer 5: Trust Frameworks and Ecosystems #### {#trust-layer} -At this level we find compliance and regulation, governance and trust frameworks, which tell us who we can trust such as a particular issuer that follows specific Level of Assurance. These trust elements depend on the context - or domain - of reference. We can have different contexts such as state, government, as well as university contexts. +At this level, we find compliance and regulation, governance, and trust frameworks, which tell us who we can trust, such as a particular issuer that follows a specific Level of Assurance. These trust elements depend on the context—or domain—of reference. We can have different contexts, such as state, government, and university contexts. -Each context is governed by one or more governance or trust frameworks. For example, for the domain of credentials issued by governments in Europe we have [EU Digital Wallet](https://ec.europa.eu/digital-building-blocks/sites/display/EUDIGITALIDENTITYWALLET/Technical+Specifications) and we can have others related to other states, as well as other domains such as individual organizations, enterprises or universities. +Each context is governed by one or more governance or trust frameworks. For example, for the domain of credentials issued by governments in Europe, we have [EU Digital Wallet](https://ec.europa.eu/digital-building-blocks/sites/display/EUDIGITALIDENTITYWALLET/Technical+Specifications), and we can have others related to other states, as well as other domains such as individual organizations, enterprises or universities. Therefore, in the various architectures, *"Trust"* and its framework permeates all layers. -Note: There are differences between the levels of DIF and with **ToIP Techological Stack**: *Governance* is a parallel halves and have specific frameworks for each level. +Note: There are differences between the levels of DIF and the **ToIP Technological Stack**: *Governance* is divided into parallel halves, with specific frameworks for each level. #### Layer 4: Applications, Wallets, Products #### {#application-layer} -At this level we find the various applications, accessible to end users, that implement the model: - * **Applications**: that can be Native, Web Based, and it is possible to interact with them in different ways. +At this level, we find the various applications accessible to end users that implement the model: + * **Applications**: These can be Native or Web, and it is possible to interact with them differently. * **Digital Wallets**: in which the Holder stores their credentials. Just as a physical wallet holds more than just IDs, the digital wallet can store various credentials and information. We can classify the wallets depending on several factors - * *Technology*: Wallets can be Native Applications (e.g., Mobile), Web Application (e.g, Cloud). - * *Cryptographic Key location*: Custodial (e.g, the key is stored in the Cloud) or Non-Custodial (e.g., the key is stored in a device in possession of the end-user) - Simplifying their structure, is composed by a secure storage and then an Agent that manages interactions. + * *Technology*: Wallets can be native applications (e.g., Mobile) or web applications (e.g., Cloud). + * *Cryptographic Key location*: Custodial (e.g., the key is stored in the Cloud) or Non-Custodial (e.g., the key is stored in a device in possession of the end-user) + Simplifying their structure comprises a secure storage and an agent that manages interactions. Note: There are differences between the levels of DIF and with **ToIP Techological Stack**: *Wallets* are at [Layer 2](#agents-and-infrastructure). *Layer 4* is for practical applications, which we cover in [Use cases](#uses-cases). #### Layer 3: Credential Layer #### {#credential-layer} -At this level, the various actors exchange credentials. Let's see what happens, using the specific definitions of the W3C Verifiable Credentials Data Model (VCDM) [[vc-data-model-2.0]] +At this level, the various actors exchange credentials. Let's see what happens using the specific definitions of the W3C Verifiable Credentials Data Model (VCDM) [[vc-data-model-2.0]] The actors are: -* The **Issuer** creates and *issues credentials* to the *Holder*. It also writes the necessary information within the *Verifiable Data Registry*. This can be a trusted third-party entity like governments or universities. In some cases, credentials can be *self-issued* by the user e.g., to represent informal skills or competencies. This flexibility allows for a broader range of credentials and applications. -* The **Holder** (the *user*), at the heart of this architecture, receives the credentials from the Issuer, stores them in a *Digital Wallet*, and *presents credentials* to the *Verifier*. -* The **Verifier** receives the presented credentials by the *Holder* and verifies them. In this model is akin to an SP or RP in federated models. This process does not necessarily involve informing the *Issuer*. This decoupling is a key aspect of the decentralized identity model, enhancing privacy and control for the user. +* The **Issuer** creates and *issues credentials* to the *Holder*. It also writes the necessary information within the *Verifiable Data Registry*. This can be a trusted third-party entity like governments or universities. In some cases, credentials can be *self-issued* by the user, e.g., to represent informal skills or competencies. This flexibility allows for a broader range of credentials and applications. +* The **Holder** (the *user*), at the heart of this architecture, receives the credentials from the Issuer, stores them in a *Digital Wallet*, and *presents* them to the *Verifier*. +* The **Verifier** receives the presented credentials by the* Holder* and verifies them. In this model, it is akin to an SP or RP in federated models. This process does not necessarily involve informing the *Issuer*. This decoupling is a key aspect of the decentralized identity model, enhancing privacy and control for the user. Note: In this model, the definition of a **credential** shifts to a set of *claims* (attributes) linked to *identifiers* controlled by the user. While credentials represent identities, not all claims within a credential are used for identification. They can describe various characteristics, extending the application of credentials beyond mere identification. -The actors exchanges: -* **Verifiable Credential (VC)**: when the Issuer sends the credential to the Holder, who then stores it in their Wallet. It is called *Verifiable* because adds *technologies, such as digital signatures, makes verifiable credentials more tamper-evident and more trustworthy than their physical counterparts*. +The actors' exchange: +* **Verifiable Credential (VC)**: when the Issuer sends the credential to the Holder, who then stores it in their Wallet. Credential is called *Verifiable* because has *technologies, such as digital signatures, makes verifiable credentials more tamper-evident and more trustworthy than their physical counterparts*. * **Metadata**: of the Credentials. * **Claim(s)**: one or more assertions where a characteristic of a subject is described (e.g., the subject is a citizen of a certain state, was born in a certain place on a certain day, month, and year, and can drive cars of this type). * **Proof(s)**: cryptographic proof of the integrity of the credential, typically via a digital signature. -* **Verifiable Presentation (VP) **: when the Holder sends a credential to the Verfier which then verifies it. The basic case is to present the credential as is. However, in many scenarios, the holder may wish to present only a subset of the claims of a credential to the verifier - this is called *Selective Disclosure (SD)* - or a combination of information from different credentials. It contains: +* **Verifiable Presentation (VP) **: when the Holder sends a credential to the Verifier, which then verifies it. The basic case is to present the credential as is. However, in many scenarios, the holder may wish to present only a subset of the claims of a credential to the verifier - this is called *Selective Disclosure (SD)* - or a combination of information from different credentials. It contains: * **Metadata**: of the presentation. * **Credential(s)**: information derived or combined from one or more credentials. * **Proof(s)**: cryptographic proof of the integrity of the credential(s) and the presentation. Note: For a comprehensive overview of Verifiable Credentials, refer to Ivan Herman's [W3C Verifiable Credentials Overview](https://www.w3.org/TR/vc-overview/). -Obviously the Issuer, the Holder and the Verifier needs a **credential exchange protocol** for VCs and VPs. This is not described in VCDM, but it is defined by other standards such as VC API and OpenID4VC. +Obviously, the Issuer, the Holder, and the Verifier need a **credential exchange protocol** for VCs and VPs. This is not described in VCDM but is defined by other standards, such as VC API and OpenID4VC. #### Layer 2: Agent Frameworks and Infrastructure #### {#agents-and-infrastructure} -At this level, the software responsible for the interaction between the various actors communicates by processing the identifiers in the credentials. Agents do content retrivals, resolve them, render them, and facilitate interactions between the various actors and the lower-levels. +At this level, the software responsible for the interaction between the various actors communicates by processing the identifiers in the credentials. Agents retrieve content, resolve it, render it, and facilitate interactions between the various actors and the lower levels. #### Layer 1: Identifiers and Namespaces #### {#identifiers-and-namespaces} -At this level we find identifiers - which are considered, along with Verifiable Credentials, one of the two pillars of decentralized models - and the Verifiable Data Registry (VDR) where referenced information is written, updated, read, and deleted. +At this level, we find identifiers and the Verifiable Data Registry (VDR), where referenced information is written, updated, read, and deleted. -As indentifiers, we mainly refer to the **Decentralized Identifiers (DIDs)**, a new Uniform Resource Identifier (URI) [[RFC3986]] type that allows entities and resources to be identified. +As identifiers, we mainly refer to the **Decentralized Identifiers (DIDs)**, a new Uniform Resource Identifier (URI) [[RFC3986]] type that allows entities and resources to be identified. DIDs, along with Verifiable Credentials, are considered one of the two pillars of decentralized models — -One of the powers of DIDs, is to provide for different methods of referencing resources [[did-core]]. - -These methods can rely on various technologies, including blockchains such as Bitcoin or Ethereum, the web, InterPlanetary File System (IPFS), and Domain Name System (DNS) [[did-spec-registries]] and it is possible to write your own method. +DIDs provide for different methods of referencing resources [[did-core]], called methods. These methods can rely on various technologies, including blockchains such as Bitcoin or Ethereum, the web, InterPlanetary File System (IPFS), and Domain Name System (DNS) [[did-spec-registries]], and it is possible to write your own method. Some distinctive properties of DIDs are [[did-intro]]: * **Decentralized**: do not depend on centralized registries, identity providers, authorities, etc. * **Persistent**: once created, it is permanently assigned to the subject. -* **Resolvable**: it is possible to find out basic set of information on the subject. -* **Cryprographically verifable**: there is a mechanism to cryptographically prove identity and ownership. +* **Resolvable**: it is possible to find out a basic set of information on the subject. +* **Cryptographically verifiable**: there is a mechanism to prove identity and ownership cryptographically. -Note: The **ToIP Techological Stack** often icludes Identifiers also at other layers. +Note: The **ToIP Techological Stack** often includes Identifiers at other layers. -The **Verifiable Data Registry (VDR)**, is the registry holds the data needed to verify credentials and their status. +The **Verifiable Data Registry (VDR)** holds the data needed to verify credentials and their status. This can be government databases, distributed ledgers, or other services. By maintaining this information, the VDR, depending on its form, enables verification without direct communication between the *Issuer* and the *Verifier*. @@ -356,17 +354,17 @@ It is interesting to reflect on how this model differs from a security and priva * **Decentralized vs. Federated Model**: Let us analyze one of the privacy issues of the federated model: whoever provides the identity can track the user. This is one of the threats this model wants to mitigate since the identity is in the user’s Wallet, and they use it as they wish. Does this guarantee its untraceability? One can presume that the answer is *"it depends"*. It depends on how the architecture is defined and implemented and the technologies used. For example, when we present our credentials to log in, the verifier contacts the issuer directly, asking if the credentials are still valid, and we continue to be traceable. -* **Decentralized vs Physical Document**: If we instead think about the case where I have to send my passport online to open a bank account, to date, the most used method is to send the file with the passport scan. The bank usually sends the file to third-party services, which often use Machine Learning systems for analysis. In addition, the file could be reused by someone who has access to it, exposing all our data and not only the one needed. +* **Decentralized vs Physical Document**: If we instead think about the case where I have to send my passport online to open a bank account, to date, the most used method is to send the file with the passport scan. The bank usually sends the file to third-party services, often using Machine Learning systems for analysis. In addition, the file could be reused by someone who has access to it, exposing all our data and not only the one needed. - Presenting a digital credential, which could also support the submission of a subset of the contained claims, can improve the situation but, again, we may encounter the problem of the verifier contacting the issuer for verification, a problem that is rarer to happen sending the file, although databases of stolen documents do exist and a verifier could make a request with the passport-id to verify the status. + Presenting a digital credential, which could also support the submission of a subset of the contained claims, can improve the situation, but, again, we may encounter the problem of the verifier contacting the issuer for verification, a problem that is rarer to happen to send the file. However, databases of stolen documents do exist and a verifier could make a request with the passport-id to verify the status. -Note: Architectural change can solve some issues and generate new ones. This is why a thorough analysis is necessary. +Note: Architectural change can solve some issues and generate new ones, so a thorough analysis is necessary. We can take a step back and understand what privacy properties are needed for digital identity, considering that the higher the level of credential assurance, the more threats can impact the user. Over the years, several proposals have been made to understand the properties of digital identities, such as [Kim Cameron's 7 Identity Laws](https://www.identityblog.com/?p=352) and Ben Laure's Privacy Requirements. Analyzing the latter [[selective-disclosure]]: * **Verifiable**: Identities, credentials, and various claims must be verifiable, which is possible through appropriate cryptographic proofs. This is part of the security aspects, which include cryptography. * **Minimal**: This is a privacy aspect. When we send information to the verifier, the information should be minimized as much as possible. For example, if we have to show that we are of age, it is okay to submit all the credentials or even the specific claim of the date of birth, but simply that I am of age. -* **Unlinkable**: This is another privacy aspect of the minimal issue anyway. Suppose any party involved in the interaction, such as the Issuer or Verifier, or even a third party, can link and correlate the information we have sent. In that case, this can be done through various techniques, and privacy is compromised. +* **Unlinkable**: This is another privacy aspect of the minimal issue anyway. Suppose any party involved in the interaction, such as the Issuer, Verifier, or even a third party, can link and correlate the information we sent. In that case, this can be done through various techniques, and privacy is compromised. So we have a number of properties, both security and privacy as a starting point. How can we implement them? First of all, different credential formats, have different privacy and security features [[verifiable-credentials-flavors-explained]] and we can expand the discussion not only to formats but to all other components of the architecture, which must be aligned to ensure security and privacy. @@ -390,7 +388,7 @@ So we have a number of properties, both security and privacy as a starting point * **Privacy**: *LINNDUN* (Linking, Identifying, Non-Repudiation, Detecting, Data Disclosure, Unawareness & Inintervenability, Non-Compliance) [[LINDDUN]], and *Privacy Considerations for Internet Protocols* [[RFC6973]]. * **Human Rights**: *Harms Modeling* [[harms-modeling]], and *Access Now #WhyID* [[access-now-whyid]]. - Other approaches includes the [Self-Review Questionnaire: Security and Privacy](https://www.w3.org/TR/security-privacy-questionnaire/) and the *OSSTMM* [[OSSTMM-3]]. + Other approaches include the [Self-Review Questionnaire: Security and Privacy](https://www.w3.org/TR/security-privacy-questionnaire/) and the *OSSTMM* [[OSSTMM-3]]. The Threat Model also includes a list of various mitigation techniques, particularly those based on cryptography techniques such as Zero Knowledge Proof (ZKP), and additional methods for enabling secure and privacy-preserving technology. @@ -401,15 +399,15 @@ So we have a number of properties, both security and privacy as a starting point As noted, VCDM and DID define only certain elements of the architecture. Other SDOs define other elements that are essential for the architecture to function. -Therefore, coordination between these entities is necessary to ensure everything works seamlessly. So, let us look at the standards involved for the various components needed. +So, coordination between these entities is necessary to ensure smooth operation. Let us examine the standards involved for the various components needed. -To understand the extent of the various standards, is it possible to refer to Michael Palage's [Digital Identity Galaxy](https://www.linkedin.com/posts/michaelpalage_eic2024-identiverse2024-iam-activity-7168002034833604608-JF5E). +To understand the extent of the various standards, we can refer to Michael Palage's [Digital Identity Galaxy](https://www.linkedin.com/posts/michaelpalage_eic2024-identiverse2024-iam-activity-7168002034833604608-JF5E). -Note: Not all of the technologies indicated are standard, so they are not to be considered normative references. Some are drafts, and others have been indicated because, although in an embryonic state, they have interesting features. +Note: Not all of the technologies indicated are standard, so they should not be considered normative references or endorsements. Some are drafts, and others have been indicated because, although in an embryonic state, they have interesting features. This is why several Standards Development Organizations (SDOs) such as the World Wide Web Consortium (W3C), the Internet Engineering Task Force (IETF), the OpenID Foundation (OIDF), and the Decentralized Identity Foundation (DIF) are coordinating to standardize the components and how they should communicate: -* **Data Models:** abstract models for Credentials and Presentation such as the [Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model/), and mDL in ISO/IEC [18013-5:2021](https://www.iso.org/standard/69084.html). +* **Data Models:** abstract models for Credentials and Presentation such as the [Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model/) and mDL in ISO/IEC [18013-5:2021](https://www.iso.org/standard/69084.html). * **Identifiers**: [DIDs](https://www.w3.org/TR/did-core/) and the [DID methods](https://w3c.github.io/did-spec-registries/#did-methods), or [WebID](https://w3c.github.io/WebID/spec/identity/). * **Encoding Schemas:** JSON, JSON-LD, CBOR, CBOR-LD. * **Securing Mechanisms:** Each mechanism may or may not support different privacy features or be quantum-resistant: @@ -428,15 +426,15 @@ Note: This list is representative. For more detailed information, please refer t It's not easy to manage digital identities. In particular, if they are related to humans, it's important to *give people control over the identifying information about themselves they are presenting in different contexts on the web, and be transparent about it* [[design-principles]]. - Given that, a *user agent should help its user present the identity they want in each context they are in, and should prevent or support recognition as appropriate* [[privacy-principles]], the [Web Platform Incubator Community Group (WICG)](https://www.w3.org/groups/cg/wicg/), incubated the Digital Credentials API [[DIGITAL-IDENTITIES]], a browser API to mediate the use of Digital Credentials between websites and wallets, to mitigate different threats to the users and promoting interoperability, and it is already working on the [Profile for OpenID4VP](https://github.com/openid/OpenID4VP/issues/125). + Given that a *user agent should help its user present the identity they want in each context they are in and should prevent or support recognition as appropriate* [[privacy-principles]], the [Web Platform Incubator Community Group (WICG)](https://www.w3.org/groups/cg/wicg/), incubated the Digital Credentials API [[DIGITAL-IDENTITIES]], a browser API to mediate the use of Digital Credentials between websites and wallets, to mitigate different threats to the users and promoting interoperability, and it is already working on the [Profile for OpenID4VP](https://github.com/openid/OpenID4VP/issues/125). The interoperability is important: if a service supports only a specific format, it excludes and discriminates against users who use a different format due to their government’s decisions rather than their own. Consequently, this limitation affects users and restricts the service’s business potential. - This API will follows the *users first, developers second, and browser engines third* principle [[design-principles]], and meeting the needs of regulations (e.g. [eIDAS](https://www.european-digital-identity-regulation.com) or [Children's Online Privacy Protection Rule (COPPA)](https://www.govinfo.gov/content/pkg/PLAW-105publ277/pdf/PLAW-105publ277.pdf)) [[digital-identity-explainer]] . + This API will follow the *users first, developers second, and browser engines third* principle [[design-principles]], and meeting the needs of regulations (e.g. [eIDAS](https://www.european-digital-identity-regulation.com) or [Children's Online Privacy Protection Rule (COPPA)](https://www.govinfo.gov/content/pkg/PLAW-105publ277/pdf/PLAW-105publ277.pdf)) [[digital-identity-explainer]]. - For these reasons, the Federated Identity Working Group - which has an API to integrate federated identities and thus has a close implementation link to decentralized ones - is in a [rechartering process to adopt the Digital Credentials API](https://github.com/w3c/strategy/issues/450), being guided by the Threat Model to make the API secure, privacy-preserving and rights-respecting. + For these reasons, the Federated Identity Working Group—which has an API to integrate federated identities and thus has a close implementation link to decentralized ones—is in a [rechartering process to adopt the Digital Credentials API](https://github.com/w3c/strategy/issues/450), guided by the Threat Model to make the API secure, privacy-preserving, and rights-respecting. - Moreover, the group’s new scope proposal has a broader perspective. It can incorporates also the other data flows of decentralized identity model to enable all possible use cases through the web platform. + Moreover, the group’s new scope proposal has a broader perspective. It can also use the other data flows of the decentralized identity model to enable all possible use cases through the web platform.
@@ -446,7 +444,7 @@ The world of Digital Identities is quite broad and has different uses in differe To imagine these use cases, we can play a game: see what is inside our physical or digital wallets. -For example, the driver’s license (and the international one), the passport (and the passport also have visas for entry to other countries, or if you have minor children, they can be in your passport), payment cards, cash, association cards, tickets (e.g., events, concerts, boarding passes), loyalty cards (from hotels, airlines, the grocery store), the university card, the badge to get into the office, medical insurance card and health card, emergency contacts, some receipts, public transportation card, my business card and the business cards of some people I met, the card to get into the gym and the library. +For example, the driver’s license (and the international one), the passport (and the passport also has visas for entry to other countries, or if you have minor children, they can be in your passport), payment cards, cash, association cards, tickets (e.g., events, concerts, boarding passes), loyalty cards (from hotels, airlines, the grocery store), the university card, the badge to get into the office, medical insurance card and health card, emergency contacts, some receipts, public transportation card, my business card and the business cards of some people I met, the card to get into the gym and the library. If we extend this concept to include those documents that are often too large to be put inside a physical wallet if not unfolded but which we use during the day, we also have employment contracts, house contracts, utility bills, ​​the papers of our pet (which, if it travels, has a chip and a passport), marriage certificate (for those who are married), a power of attorney to sign the documents of a company, the tax return, bank statements, amateur radio license or other licenses, medical prescriptions, exam results (both medical and college), degree, professional qualifications (e.g., medical doctor, lawyer, psychologist), warranty certificates of the items I bought and much more. @@ -457,7 +455,7 @@ If we extend this concept to include those documents that are often too large to * We are not the subjects of some credentials, as in the case of pet travel documents. -Let us proceed to examine the use cases for those organization-related identities. +Let us go ahead and look over the use cases for those organization-related identities. ## Organizations ## {#organizations} @@ -465,7 +463,7 @@ We can look at organizations from different aspects. On the one hand, they can b ### Organizational Identity ### {#organizational-identity} -Organizations can also have a digital identity and related identfiers such as the Registration Number with the government where it was opened, possibly the VAT Number if not the Legal Entity Identifier. Although the organization has an identity of its own, it operates through individuals who, in the bylaws, have various authorizations, delegations, and signing powers. Therefore, when you do any transaction, such as opening a bank account or a business transaction, you need the organization’s and the personal documentation of the various individuals involved. The use of digital identity in a wallet, with delegation managed through Verifiable Credentials, certainly streamlines the various transactions both with governments and suppliers and with customers, particularly for those aspects of global transactions where the trust relationship goes through a digital transaction and the Association of Certified Fraud Examiners (ACFE) estimates that organizations lose 5% of revenue to fraud each year [[acfe-occupational-fraud-2024]]. +Organizations can also have a digital identity and related identifiers such as the registration number with the government where it was opened and possibly the VAT number, if not the legal entity identifier. Although the organization has an identity of its own, it operates through individuals who, in the bylaws, have various authorizations, delegations, and signing powers. Therefore, when you do any transaction, such as opening a bank account or a business transaction, you need the organization’s and the personal documentation of the various individuals involved. The use of digital identity in a wallet, with delegation managed through Verifiable Credentials, certainly streamlines the various transactions both with governments and suppliers and with customers, particularly for those aspects of global transactions where the trust relationship goes through a digital transaction and the Association of Certified Fraud Examiners (ACFE) estimates that organizations lose 5% of revenue to fraud each year [[acfe-occupational-fraud-2024]]. ### Identity and Access Management (IAM) ### {#identity-and-access-management} @@ -479,7 +477,7 @@ The fact is that, net of a further trend in the last year of "back to the office ## Things ## {#things} -Although applications with identities linked to individuals are the most studied cases and are delicate to handle, identities also find fertile ground in the *supply chain* and *IoT* world, which are decentralized and distributed by nature. +Although applications with identities linked to individuals are the most studied cases and are delicate to handle, identities also find fertile ground in the *supply chain* and *IoT* world, which is decentralized and distributed by nature. ### Supply Chain ### {#supply-chain} @@ -495,7 +493,7 @@ In "Self-Sovereign Identity" [[self-sovereign-identity]], we find an interesting The challenge is that the transmission grid must maintain a consistent frequency to function properly. Power plants typically coordinate to adjust the input frequency in response to changes in energy consumption. However, this becomes particularly complex when integrating small and distributed devices. -It is necessary to identify small devices correctly to avoid issues throughout the network. Verifiable Credentials are present within the devices' operating systems to ensure the IAM aspect, as well as DIDs to identify them correctly [[energy-web-credentials-overview]]. +It is necessary to identify small devices correctly to avoid issues throughout the network. Verifiable Credentials are present within the devices' operating systems to ensure the IAM aspect and DIDs to identify them correctly [[energy-web-credentials-overview]]. ### Automotive (IoT) ### {#automotive-(iot)} @@ -511,7 +509,7 @@ A car, identified by the Vehicle Identification Number (VIN), interacts with var It could also be opened and closed directly through the owner’s Wallet, making the car a *Verifier* during unlocking and a *Subject* in the owner's wallet. -This illustrates the utility of IoT identities and credentials, and their integration with governmental and human identities [[self-sovereign-identity]]. For example, when buying and selling a used car, several elements must be verified, such as: +This illustrates the utility of IoT identities and credentials and their integration with governmental and human identities [[self-sovereign-identity]]. For example, when buying and selling a used car, several elements must be verified, such as: - The vehicle's characteristics and history. - Ownership verification of the seller. - The buyer's creditworthiness. @@ -523,7 +521,7 @@ Note: The automotive case is particularly interesting. Even though it is a Non-H Let us return to the initial example and analyze human identities, focusing on those issued by the government. These have the most assurance and thus expose the user to the most security, privacy, and human rights threats. -A government issues a human-citizen with a specific set of credentials for the purpose of identification and to outline their attributes: +A government issues a citizen a specific set of credentials for the purpose of identification and to outline their attributes: * Travel documents (e.g., Passports and Entry Visas) * Personal licenses (e.g., Driver’s Licenses, Amateur radio licenses, Professional licenses, Marriage Licenses) @@ -588,7 +586,7 @@ Moreover, an additional privacy concern is inherent in this use case - which app ### Pure Digital Credentials ### {#pure-digital-credentials} Governments and regulatory bodies have also stepped up to issue digital credentials for citizens. -Each government has made its own architectural choices and can offer different services, from centralized or federated authentication to decentralized identities giving citizens a wallet to hold one’s digital credentials. +Each government has made its own architectural choices and can offer different services, from centralized or federated authentication to decentralized identities that give citizens a wallet to hold their digital credentials. Below is a short list with some implementation examples: @@ -606,35 +604,35 @@ Some governments are doing pilot projects with Decentralized Identities, providi Let's delve into an extensively debated use case requiring a solution: age verification. -The holder has a digital passport in the form of government-issued credentials; this credential, in its claims, also contains age information. -* **Full Credential**: It is possible to send the full credential since it also contains the date of birth, from which the verifier can derive the age. This doesn’t meet the principle of Data Minimization, though, as I’m sending a lot of other information that can be misused and make us traceable. -* **Selective Disclosure** [[selective-disclosure]]: If only the date of birth is submitted, we still have a minor data release, as the verifier is interested not in the date of birth but in whether the person is of age. If the credential provided supports this privacy feature, which allows us to send individual attributes/claims, we can send only the date of birth, by which the verifier can derive the age. It certainly improves the situation concerning Data Minimization, but it does not solve it totally. To overcome this problem, some credentials have specific attributes with boolean values to present that our age exceeds a certain value (e.g., 16, 18, 21). +The holder has a digital passport in the form of government-issued credentials; these credentials, in their claims, also contain age information. +* **Full Credential**: It is possible to send the full credential since it also contains the date of birth, from which the verifier can derive the age. However, this doesn’t meet the principle of Data Minimization, as I’m sending a lot of other information that can be misused and make us traceable. +* **Selective Disclosure** [[selective-disclosure]]: If only the date of birth is submitted, we still have a minor data release, as the verifier is interested not in the date of birth but in whether the person is of age. Suppose the credential provided supports this privacy feature, which allows us to send individual attributes/claims. In that case, we can send only the date of birth, by which the verifier can derive the age. It certainly improves the situation concerning Data Minimization, but it does not solve it totally. To overcome this problem, some credentials have specific attributes with boolean values to present that our age exceeds a certain value (e.g., 16, 18, 21). * **Range Proof** [[range-proofs]]: If we send the verifier the boolean result of a computation related to the value of a specific attribute (e.g., the verifier asks us if we are older than 21 years old, and we send the result of the computation on the date of birth). The problem is that, even in the last two cases, we can present potentially linkable information to us or our issuer, which the verifier can use to make correlations. For example, it is necessary to decouple the signature from the signer and not use the same identifiers in different sessions. -Conversely, the verifier will have to somehow prove that they performed the age verification, which further complicates the matter. +Conversely, the verifier will have to prove that they performed the age verification, further complicating the matter. Therefore, even in a scenario that may seem trivial, it requires extensive study.
Mitigating the threats at technological and governance levels
- In the context of high-assurance credentials and particularly those issued by governments, even the solution related to a seemingly simple problem requires a thorough analysis of the impacts these solutions may have on the population. + In the context of high-assurance credentials, particularly those issued by governments, even the solution to a seemingly simple problem requires a thorough analysis of the impacts these solutions may have on the population. - As we have analyzed, an end-to-end solution requires the conjunction of technological aspects related to the stanzardization of technologies, their implementation, and the adoption, which is defined by elements of governance that permeate the technological aspects. + As we have analyzed, an end-to-end solution requires the conjunction of technological aspects related to the standardization of technologies, their implementation, and their adoption, which is defined by elements of governance that permeate the technological aspects. - In this specific case, we have different stakeholders such as SDOs, implementers, governments who through regulatory bodies defines the needs, the requirements, and the architectures, and last but not least, the users who are impacted by these solutions. + In this specific case, we have different stakeholders, such as SDOs, implementers, and governments, who, through regulatory bodies, define the needs, requirements, architectures, and, last but not least, the users impacted by these solutions. - Therefore, it is important for all these stakeholders to work together for joint value creation [[stakeholder-relationships-and-responsibilities]], also to ensure the proper handling of threats in the areas of security, privacy, and human rights: some threats exist at the technology level and can be managed by SDOs and implementers, but governments must manage others at the governance level: + Therefore, it is important for all these stakeholders to work together for joint value creation [[stakeholder-relationships-and-responsibilities]] and ensure the proper handling of threats to security, privacy, and human rights. Some threats exist at the technology level and can be managed by SDOs and implementers, but governments must manage others at the governance level: * A centralized system is prone to surveillance. In contrast, a decentralized system with certain technological features and cryptographic methods can mitigate surveillance and respect human rights. - * When a decentralized system is used there are issues related to digital wallets. On the one hand, it is necessary to balance security and hardware and software requirements that could discriminate. On the other hand, it is important to avoid vendor lock-in and prevent what happened with the Digital Market Act and default browser choice. + * When a decentralized system is used, issues related to digital wallets arise. On the one hand, it is necessary to balance security and hardware and software requirements that could discriminate. On the other hand, it is important to avoid vendor lock-in and prevent what happened with the Digital Market Act and default browser choice. - * If threats cannot be effectively managed at the technology level, they should be addressed at the governance level. This can involve measures such as prohibiting certain uses or removing features that cannot be technically mitigated to reduce the threat. + * If threats cannot be effectively managed at the technology level, they should be addressed at the governance level. This can involve prohibiting certain uses or removing features that cannot be technically mitigated to reduce the threat. - Active cooperation between governments, SDOs, implementers and users is essential. SDOs can serve as a neutral forum to discuss these issues and create value together. + Active cooperation between governments, SDOs, implementers, and users is essential. SDOs can be a neutral forum to discuss these issues and create value.
@@ -770,7 +768,6 @@ Several individuals contributed to the document. The editor especially thanks Pi "year": "2023" }, "digitalizing-report": { - "authors": ["Felix Linker", "David Basin"], "title": "Digitalizing the Red Cross, Red Crescent and Red Crystal Emblems: Benefits, Risks, and Possible Solutions", "href": "https://dl.acm.org/doi/10.1145/3576915.3616578", "publisher": "International Committee of Red Cross"