This document outlines the use cases and requirements for an issuer to express a list of recognized entities and their corresponding actions, such as issuing and verifying.

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 document and its corresponding 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, and 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.

Introduction

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 exist 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 rely on 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 the information on the chip. eIDAS v2 will also 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 and requirements to address it:

• Section 2 presents a set of use cases in the digital age that explain the use of lists of Verifiable Issuers and Verifiers.
• Section 3 provides the conceptual model for sharing lists of Verifiable Issuers and Verifiers and the requirements for such lists.

The target audience of this paper is people that know the basics of Self-Sovereign Identity (SSI) (such as the concepts of [=issuer=], [=holder=], [=verifier=], and [=verifiable credential=]) and want to learn about the use cases that require the publication of lists of recognized issuers and verifiers.

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:

• Verifiable Issuers
• Verifiable Verifiers

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 the content of those use cases in this document, they are included by reference:

• Authorized Issuer List Use Cases
• ESSIF-Lab Trust Management Infrastructure (TRAIN) Business Case

Verifiable Issuer Use Cases

• Acme Inc. is a producer of medical equipment. Twin Mountains Hospital decided to buy equipment from Acme Inc. The law says that medical equipment should be certified by a 3rd party certification body. Twin Mountains Hospital requests a certification from Acme, Inc.; Acme, Inc. delivers it to them. The hospital then checks if Acme Inc. is in the Verifiable Issuer List of licensed 3rd party certification bodies to see if the Issuer of Acme Inc.'s certification is an approved certification body.
• Note: The solution might need to convey a single item in a List vs. the entire List.
• Note: Many similar certification/license use cases are out there.
• Walmay, Inc. is a wholesaler of drugs. John & Jane is a manufacturer of drugs. Walmay, Inc. finds out that a lot of Adenosine Triphosphate drugs has broken packaging and decides to return the lot to the manufacturer. It is required that all interactions in the drug market happen only between authorized trading partners. John & Jane requests an Authorized Trading Partner (ATP) certificate from Walmay Inc. The certificate credential contains a link to the Issuer. John & Jane then verifies that the Issuer is a member of the Verifiable-Issuer List of Issuers authorized to issue ATP credentials.
• Elena is an IT Administrator in the hiring department of a mid-size company that would like to vet job applicants as having received their degrees from an accredited college or university. Elena configures their hiring software to refer to multiple lists (Verifiable-Issuer Lists) containing several hundred organizations that are curated by the various accreditation bodies that they trust.
• Line is elected treasurer of a Dutch church. In her role as treasurer, she goes online to open a bank account for the church. To comply with certain laws and adhere to internal risk mitigating policies, the bank needs to verify that Line has been authorized by the church to sign on its behalf. For companies, personal information about executive board members is registered by the Chamber of Commerce alongside the registration of the legal entity. However, due to the special sensitive nature of data regarding religious affiliations, the Chamber of Commerce in the case of religious institutions (mosque/synagogue/church) is prohibited from registering any data that can be correlated with a natural person. Instead of checking the Chamber of Commerce public register, the bank requests a credential from Line stating her mandate to sign, which she received from the church. The bank checks whether the church is on the Verifiable Issuer-List of Churches, which is maintained by the Chamber of Commerce. Finding the church on the list, the bank is now able to open a bank account for the church, which Line can administer.

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

• Yuri has a digital driver's license and is attempting to rent a car from CarMart. CarMart requests to see Yuri's age, motor vehicle class, and driver's license number. Yuri's software checks against a Verifiable-Verifier List to make sure that CarMart is a Verifiable authority for information of that type, so it can warn Yuri if CarMart isn't trusted to request that information from Yuri.
• Oskar joins a tennis club. The tennis club requests a government-issued proof of birth date. However, the tennis club does not have authorization to ask for this personal information. As a consequence, Oskar’s certified EUDI wallet refuses to present the information, based on the absence of the tennis club in the relevant Verifiable-Verifier List. The tennis club realizes that they cannot obtain this high-LoA information from the EUDI wallet and instead accepts a self-asserted date-of-birth by Oskar.
• Oskar was invited by the European Commission to become an evaluator. Even though Oskar would be paid only the equivalent of a book voucher, the EC requires a full contracting process, which includes an eIDAS LoA high identification and a recent authentic bank statement. Even though Oskar considers these requirements unreasonable, Oskar’s certified EUDI wallet accepts the request, as the EC is registered in the relevant Verifiable-Verifier List. This way, Oskar knows at least that the request is genuine, and that there exists a sufficiently-well-governed policy associated with the request.
• Oskar crosses the border to Dystopia. Immigration requests that Oskar surrender all Verifiable Credentials in his SSI wallet, including identification, driver’s license, diplomas, certifications and other records. Immigration of this country is not authorized to make such a wide request, as it is not included in the relevant Verifiable-Verifier List. As a consequence, Oskar’s certified EUDI wallet refuses to present this information. Even the threat of denial-of-entry or worse cannot change the situation, as neither immigration nor Oskar himself is physically able to compromise Oskar’s EUDI wallet to surrender the 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 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.

• A list may be created and governed by any individual, group of individuals, organization, group of organizations, or other.
• A list and/or its entries shall be made available to subscribers.
• A list and/or its individual entries shall be serializable in one or more formats such as a Verifiable Credential.
• Entries may be made available via a Wallet, a Website, a URI, a QR code, a DNS Resource Records, DNSSEC, on-chain Ethereum transactions, or other methods.
• A list and its entries shall be cryptographically verifiable.
  • A list shall accommodate Different cryptographic mechanisms (X.509, JWK, etc.).
  • There shall be an ability to authenticate the list or an individual entry.
• A list and its entries shall have associated Governance Metadata Format, including:
  • Policies; and
  • Qualifier details.
• A list and its entries shall be publicly resolvable.
• A list and its entries shall be privately transmittable/retrievable.
• A list may have metadata associated with it, e.g., metadata that is applicable to all of its entries.
• A list may have different levels of privacy/confidentiality, ranging from fully public to for-authorized-yes-only.
• Entries shall be able to be created, read, and deleted.
• Entries may be updated, suspended and/or revoked.
• Entries may have an individual level of assurance associated with it.
• Entries may have an associated level of assurance.

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.