<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