This work focuses on how a party or its agent can decide whether or not to engage with a counterparty in a transaction. The purpose of this work is to enable a party to share a list of Verifiable Issuers and Verifiers in a way that is useful to a particular transaction.

There was extensive analysis of existing initiatives performed at the Rebooting the Web of Trust 11 conference in The Hague as well as a number of follow on meetings to coordinate activity across various communities. The paper analyzing the existing state of the art is available from the Rebooting The Web of Trust paper archive.

This specification is intended to align with work happening in other venues such as the Trust Over IP Foundation, ESSIF-Lab, The European Digital Identity Initiative and other European Trust Frameworks, Canadian Trust Framework activities, as well as commercial ventures that are exploring Trust Frameworks. Effort will continue to be expended to align this specification with work happening in other related venues. The authors and editors of this specification invite commentary on this specification through the Github issue tracker listed at the top of this document.

This is an experimental specification and is undergoing regular revisions. It is not fit for production deployment.

Introduction

The maintenance of lists of Verifiable Issuers, sometimes referred to as Trusted Registries, are a well-known concept from the pre-internet age. Whenever there is a diploma signed by a university, there are people and organizations that keep track of what universities exist and what methods there are to confirm the authenticity of that diploma. A list could be maintained by HR staff for the purpose of hiring personnel based on qualifications asserted by particular Verifiable Issuers, and the governance of that list would be minimal. Another list could be maintained by a government, associated with well-governed accreditation procedures, for the purpose of assuring that a diploma represents a proper education. Lists of Verifiable Issuers support Verifiers in their decision to trust the Issuer of a Verifiable Credential that is presented by a Holder.

Digitally sharing lists of Verifiable Issuers and Verifiers is a relatively new concept. Examples are the list of parties that are allowed to use the digital fingerprint information on the chip of RFID-based digital passports. This is cryptographically enforced: “chip-says-no” when an unauthorized party attempts to access this information on the chip. Also eIDAS v2 will have a Verifiable-Verifiers List that limits the access of Verifiers to credentials in a EUDI (EUropean Digital Identity) wallet. Verifiable-Verifiers Lists support Holders and holder implementations in their decision to trust a Verifier to share a Verifiable Presentation to that Verifier.

Lists of Verifiable Issuers and Verifiers help to automate the decision process of whether to engage with a counterparty in a transaction and make it more auditable by ensuring that software can note that a party was on a list before engaging with them. This paper contains the following sections that provide background on the problem space as well as a proposed set of solutions given the current state of the market:

The target audience of this paper are people that know the basics of Self-Sovereign Identity (SSI) such as the concepts of Issuer, Holder, Verifier, and Verifiable Credential. SSI developers may use this document as input and inspiration for their code and other products. Deployers of SSI use cases may use this document in the specification process of their deployment.

Terminology

The following terms are used to describe concepts in this document.

Credential

A set of one or more claims made by an issuer. A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations, which can also be cryptographically verified. The claims in a credential can be about different subjects.

Electronic Identification, Authentication and Trust Services (eIDAS)

eIDAS (electronic IDentification, Authentication and trust Services) is an EU regulation on electronic identification and trust services for electronic transactions in the European Single Market. It was established in EU Regulation 910/2014 of 23 July 2014. All organizations delivering public digital services in an EU member state must recognize electronic identification from all EU member states from September 29, 2018.

European Digital Identity (EUDI)

The European Digital Identity is based on a European Commission document called “European Digital Identity Architecture and Reference Framework” that has established the functional and architectural requirements for an upcoming European Digital Identity Wallet.

Holder

A role an entity might perform by possessing one or more verifiable credentials and generating presentations from them. A holder is usually, but not always, a subject of the verifiable credentials they are holding. Holders store their credentials in credential repositories.

Issuer

A role an entity can perform by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder.

Level of Assurance (LoA)

The degree of certainty that a relying party can have about the true identity of someone presenting an identity credential. Four levels of assurance were outlined by a 2006 document from the US National Institute of Standards and Technology (NIST 800-63). The level of assurance is measured by the strength and rigor of the identity proofing process, the strength of the token used to authenticate the identity claim, and the management processes the identity provider applies to it.

Sharing

The act of transferring information from one party to another. This paper uses the word "sharing" instead of "publishing" as the latter presumes a one-way and public transfer of information. The Verifiable Issuer/Verifier lists described in this paper are made available in some form or other. They might be pushed to a party or pulled from a party and might use a public communication channel or a private one.

Verifiable Issuer / Verifiable Verifier

A party that is verifiable might have different levels of trustworthiness associated with it by different parties. Note that “trusted” or “authorized” are sometimes used as synonyms for “verifiable”, as the purpose of some lists is to assure trust or authority. This paper uses the word “verifiable” as no presumption should be made about the application of the lists, or the trust/authority that they assure.

Verifiable Issuer/Verifier List

A container that consists of a set of Verifiable Issuers or Verifiers. The word “list” can be considered synonymous to “register”, depending on the amount of governance, assurances and authority associated with it. This paper uses the word “list” and presumes there will always be some form of governance, if only the establishment of its purpose and the format of its entries.

Verifier

A role an entity performs by receiving one or more verifiable credentials, optionally inside a verifiable presentation for processing. Other specifications might refer to this concept as a relying party.

Criteria

This section contains criteria that can be used to determine whether something does or does not fit a particular terminological definition in the previous section.

sharing

  • Enables other parties to obtain a copy of a list entry about an Issuer or Verifier from the list, e.g. in VC format, through DNS query, or other mechanism.
  • May or may not enable others to obtain a copy of the full contents of a list.
  • Those others may be anyone in the world, or they may be only those who have access to the list or to a specific entry about an Issuer or Verifier.

list

  • Contains zero-or-more entries about any party.
  • A list entry contains data about one specific party. The data is specified by the party that governs the list.
  • A list is associated with a policy containing one or more criteria that are used to determine whether or not a party qualifies for being registered in the list. Criterion may distinguish between parties, e.g., between parties that are trusted to issue or verify VCs of a specific kind.
  • Other parties may use the data in a list entry as the basis for a decision, e.g., to share further information, or to engage in a transaction. The perceived use of list entries by other parties should guide the party that governs the list as it specifies the structure of list entries.

parties

  • Are expected to perform the roles of issuer, holder, and verifier as well as other verifiable-credential-related roles (e.g., revocator).
  • May or may not be a legal authority.
  • The party that manages the list has to be able to precisely describe the thing that the list entry enables because software will act upon that machine-readable description. For example, "Issues Student ID cards for University X".

A conforming list is any concrete expression of the data model that complies with the normative statements in this specification. Specifically, all relevant normative statements in Sections of this document MUST be enforced.

A conforming processor is any algorithm realized as software and/or hardware that generates or consumes a conforming list. Conforming processors MUST produce errors when non-conforming documents are consumed.

This document also contains examples that contain JSON and JSON-LD content. Some of these examples contain characters that are invalid JSON, such as inline comments (`//`) and the use of ellipsis (`...`) to denote information that adds little value to the example. Implementers are cautioned to remove this content if they desire to use the information as valid JSON or JSON-LD.

Use Cases

This section outlines use cases that highlight the need for the technology described in this paper by discussing the use cases in two categories:

A final use case section then checks for commonalities and differences between the two categories

There are a number of other locations that have published use cases that are related to this paper. Rather than include those use cases in this document, they are included by reference:

Verifiable Issuer Use Cases

A graduate holding a diploma with a text bubble attached to the diploma that says 'Verifiable-Issuer List says diploma is genuine'

Figure 1: A Verifiable-Issuer List helps verifying whether a diploma is genuine.

Verifiable Verifier Use Cases

See also Verify the Verifier - Anti-coercion by Design; October 2020 | TNO

A police officer standing over a child asking for their credentials and the child saying that they cannot provide the credentials because their digital wallet cannot identify that the police officer is authorized to ask for all of that information.

Figure 2: A properly-implemented wallet with Verifiable-Verifier List protects citizens against overzealous law enforcement.

Commonalities and Differences

Conceptually and technically, the two types of lists (Verifiable Issuer, Verifiable Verifier) are fairly similar. Each type is a governed list of parties with a role in SSI exchanges. Each type needs to provide some form of sharing (publication/access), so that the list is available to its users. This paper will presume that the types of lists themselves, as well as their sharing methods, can be technically identical. The only distinction is that a list could contain only Verifiable Issuers, only Verifiable Verifiers, or a mixture2 of both, so the data model should accommodate this.

Major differences arise in the applications surrounding the lists. Verifiable Issuer lists target Verifier implementations, whereas Verifiable Verifier lists target Holder (digital wallet) implementations. Also there may be major differences in the governance between the two types of lists, or whether/how the consulting of lists is implemented and enforced. All of these differences are out of the scope of this paper.

Requirements

Conceptual Model

An Assurance Community is what governs a list of Verifiable Issuers and/or Verifiers. The community can consist of a single person, a group of people, an organization, a group of organizations, or any other relevant structure. The governing can be purely manual, partially automated, or completely automated through the use of APIs or smart contracts.

A list of Verifiable Issuers and/or Verifiable Verifiers contains entries with information about the Issuers and/or Verifiers that it verifies.This information can be as minimal as a single DID or public key per Verifiable Issuer or Verifiable Verifier, or it can also include metadata about each entity and the services that each entity performs.

An Interested Party is an entity that uses one or more entries from the List of Verifiable Issuers and/or Verifiable Verifiers in a decision making process. An interested party is typically software that is acting on behalf of an Issuer, Holder, or Verifier. The party might request the entire List, or portions of the List over either a public channel, or a private channel.

Requirements

The following requirements have been specified by the authors. It includes both requirements on a Verifiable-Issuers/Verifiers List (“a list” in short) as a whole and its individual entries. These requirements may be updated in the future.

The only technology approach that we were not able to analyze deeply is Trinsic's approach. We need to make sure their approach is integrated into and aligned with the documented use cases, requirements, and the rest of the document.

Data Model

The following sections outline the data model that is used by this specification for Verifiable Issuer and Verifier Lists.

The data model described in this section has been built using input from a variety of the prior art evaluated for this paper including input from the EBSI Trusted Issuer Registry, ETSI TS 119 612, eSSIF-Lab TRAIN, the Trust over IP Foundation Trust Registry Protocol, and Rebooting the Web of Trust input documents. The data model described in this section is capable of expressing many, but not all, of the concepts described in those other specifications.

The unified data model for this work can be represented as a list of entries that represent parties.

Each list entry, representing a party, contains the following mandatory information:

Each list entry, representing a party, might contain the following optional information:

Verifiable Credential

The data model described in this section can be expressed as a Verifiable Credential as outlined in the example below: 

{
  "@context": [
    "https://www.w3.org/2018/credentials/v2",
    "https://w3id.org/verifiable-party/v1"
  ],
  "issuer": {
    "id": "did:web:authority.example",
    "name": "National Education Accreditation Authority of Utopia"
  },
  "issuanceDate": "2023-02-13T00:18:30.053Z",
  "type": ["VerifiableCredential", "VerifiablePartyCredential"],
  "credentialSubject": [{
    "id": "did:web:registrar.utopia.edu.example",
    "type": "VerifiableIssuer",
    "name": "Utopia University Registrar",
    "legalName": "The Polytechnic University of Utopia Registrar",
    "website": "https://utopia.edu.example/",
    "email": "accreditation@neaau.org.example",
    "identifier": [{
      "type": "PropertyValue",
      "propertyId": "Utopia Educational Institution ID",
      "value": "123456789"
    }],
    "usesOperationalScheme": [{
      "id": "http://oid-info.com/get/1.2.3.4.5",
      "name": "Utopian Trust Scheme 819-4"
    }],
    "accreditation": [{
      "id": "https://utopia.gov.example/accreditations/123"
    }],
    "authorizedToIssue": [{
      "type": "UniversityDegreeCredential",
      "credentialSchema": {
        "id": "https://Issuer.example/degree.json",
        "type": "AuthorizedIssuerJsonSchema2022",
        "schema": "{\"properties\":\{\"credentialSubject.state\":\"UA\"}}"
      }
    }]
  },
  "proof": { ... }
}

Acknowledgements

The Working Group thanks the following individuals for significant contributions to the community: TBD

Work on this specification has been supported by the Rebooting the Web of Trust community facilitated by Christopher Allen, Joe Andrieu, and Erica Connell. The participants in the Internet Identity Workshop, facilitated by Phil Windley, Kaliya Young, Doc Searls, and Heidi Nobantu Saul, also supported the refinement of this work through numerous working sessions designed to educate about, debate on, and improve this specification.

The Working Group would like to thank the following individuals for reviewing and providing feedback on the specification (in alphabetical order):

Some of the imagery in this specification was provided by Ron Lach and Kindel Media under the Pexel's license. We are thankful to those individuals and Pexels for providing imagery that this community could use and have made donations to each of those contributors.