Page tree
Skip to end of metadata
Go to start of metadata

This page is the charter of the TSWG Trust Registry Task Force. See the Meeting Page for links to the meeting agenda and notes for each meeting.


The objective of this Task Force is to develop the ToIP Trust Registry Protocol as a ToIP Specification. The purpose of this deliverable to enable interoperability between ToIP-compliant trust registries.


The mission of the ToIP Foundation is to define a complete architecture for Internet-scale digital trust that combines cryptographic trust at the machine layer with human trust at the business, legal, and social layers. The ToIP stack has two parallel halves—a technical stack and a governance stack—operating at four layers 1) Utility (DLT Blockchain), 2) Agent/Wallet, 3) Credential Exchange (Issuer/Verifier/Holder) and 4) Ecosystem (Application).  See further details in the ToIP white paper.

A core role within ToIP Layer 4 is a trust registry (previously known as a member directory). This is a network service that enables a governing authority for an ecosystem governance framework (EGF) to specify what governed parties are authorized to perform what actions under the EGF. For example:

  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 trust registries (and their governing authorities) are trusted by a host trust registry.

As with all layers of the ToIP stack, the purpose of 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.


  1. Darrell O'Donnell
  2. Drummond Reed

Membership and Joining

Prior to participating in the meetings, please ensure that you are a member of the Trust Over IP Foundation (Contributor Membership is free to both organizations and individuals). More details can be found at this link.

To join this TF, add your name to this list:


  1. ToIP Trust Registry Protocol TSS. This is a formal specification of a protocol for interactions with a ToIP-compliant trust registry service. Note that this specification is initially being drafted as a Google doc which will then migrate to this wiki and finally move into GitHub for final publication.
  2. OpenAPI 3.0 API - managed in GitHub. 
  3. X.509 DID Interop concept.

Link to GitHub repository : TODO

Intellectual Property Rights (Copyright, Patent, Source Code)

As a Task Force (TF) of the Technical Stack WG (TSWG), the GSWG P&R TF inherits the IPR terms from the TSWG JDF Charter. These include:


Key milestones will include, but are not limited to:

  1. Publication of the first Draft Deliverable as a ToIP wiki page.
  2. Publication of the final Draft Deliverable.
  3. Approval of the Draft Deliverable as a Working Group Approved Deliverable.

The work of the this Task Force will be complete when the Working Group Approved Deliverable is approved by the TSWG.


Meeting Schedule and Notes

The first meeting of this Task Force will be Thursday 17 June 2021 at 07:00-8:00 PT / 14:00-15:00 UTC. The Zoom link is available on the ToIP Calendar. At the first meeting we will decide on a regular meeting schedule (which may be multiple times a week to complete a spec quickly).

See the Meeting Page for links to the meeting agenda and notes for each meeting.

Mailing List and Communications

This task force uses the following for communications

  • Slack: #tswg-trust-registry-tf <== This channel encouraged for regular comms.
  • Mailing List: There is no mailing list; TBD if we will need one.

  • No labels