This the home page for a draft of the ToIP Trust Registry Protocol specificationProtocol Specification, a proposed Draft Deliverable of the TSWG developed by the Trust Registry Task Force. The Working Draft of this specification will proceed through three stages:

...

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document , when appearing in ALL CAPITALS, are to be interpreted as described in RFC 2119.

All other terms in bold will be defined in one or more of the ToIP glossaries in a process being defined by the ToIP Concepts and Terminology Working Group.

Purpose

The purpose of this TSS this specification is to specify a standard interoperable protocol for interactions with any ToIP-compliant trust registry. 

...

1. What issuers are authorized to issue what types of verifiable credentials.
2. What verifiers are authorized to request what types of verifiable presentations.
3. What other governing authorities are trusted to authorize these same parties and actions within their own trust registriesother trust registries are trusted by this trust registry.

As with all layers of the ToIP stack, the purpose of a TSS a ToIP specification is to enable the technical interoperability necessary to support transitive trust across different trust communities implementing the ToIP stack. In this case, the desired interoperability outcome is a common protocol that works between any number of decentralized trust registries operated by independent governing authorities representing multiple legal and business jurisdictions. One specific example of this need is the digital trust ecosystem defined by the Interoperability Working Group for Good Health Pass (GHP). The GHP Trust Registries Drafting Group produced an extensive set of recommended requirements for a GHP-compliant trust registry.

...

In the same W3C CCG thread, Daniel Hardman made this point:

I feel like decentralization is running into a difficult tension here: we want to democratize issuance (anyone can do it), but we want to trust a limited set of issuers (or at least, a limited set on any given topic). Anybody can create a COVID test result credential, but we only want to accept them if they were issued by a lab that we have reason to trust. Etc...

One solution to this problem is registries: list trusted sources and have your software check whether the issuer is on approved/accredited list by querying. Of course this re-centralizes around the oracle.

...