<DAY> March <#>

Attendees

Co-Leads: Darrell O'Donnell
ID2020 PM: Todd Gehrke

Participants:

Drummond Reed
Kaliya Young

Agenda Items

Time	Item	Who
	Review community feedback	All
3 min	Wrap up	Chair

Meeting Notes

Reviewed community feedback on the document and worked through making edits:

General Feedback

Daniel Hardman - SICPA

You are defining "trust registry" too narrowly -- as an entity that "make[s] the list of DIDs it trusts available to the members of its ecosystem via a network service."

A trust registry answers the question, "What DIDs should be trusted?" -- but whether it does so by exposing a web service, or by publishing a document that the world can download, or by issuing verifiable credentials to entities it trusts, attesting to the world that the trust registry trusts them, is debatable.

By focusing in on the web service model, you are creating a point of centralization. You are also asking "verify the verifer" and "verify the issuer" interactions to work by different rules than "verify the holder" interactions. This is a real shame; it means we don't believe in the validity of VCs for anything except individuals, so we are perpetuating the power imbalance between individuals and institutions.

The web service-based trust registry model is less scalable and performant than the VC-based trust registry model. It uses PKI/TLS to protect the network pipes over which the web service calls run (so it introduces a dependency on a new security model besides DIDs). It will require new interfaces to be invented and standardized (instead of using the standards we've already built for requesting and presenting VC-based proof).

I am not really arguing that we should preclude web service-based trust registries from our model -- but I am arguing that we need to edit the language in this section such that a trust registry that publishes in some fashion other than "via a network service" is equally canonical.

Trevor Butterworth - Indicio.tech

Trust registries are represented as a network service. This is not necessary to meet the requirements in the blueprint. Certainly, registries will be used to organize the information about schemas, issuers, and verifiers; but a live call to a service is only one way to resolve the issues at the heart of the root of trust.

Trust Registries may also publish their information they contain in machine readable form. This allows the information to be downloaded and cached, enabling offline verification of issuers and verifiers. Schema information may also be used to cache appropriate information necessary for offline credential exchange.

Drummond Reed - Evernym

The references to "GHP Trust Registry Protocol Specification" in this section should be updated to "ToIP Trust Registry Protocol Specification" because the need for this protocol is much broader than GHP. The ToIP Technical Stack Working Group has formed a Trust Registry Task Force to define this

Changes:

7.2.2 - Added a section about other approaches and justification for the recommended approach.
7.2.4.2 - Reworded negative requirement in protocol-based section.
7.2.6.1 - Included more details of an approach for offline

Recording -Link

Action Items

TBC

Browser not supported