Meeting Date
Zoom Link / Recording
Attendees
Main Goal of this Meeting
Close open issues with the draft specification.
Agenda Items and Notes (including all relevant links)
| Time | Agenda Item | Lead | Notes |
| 5 min | - Start recording
- Welcome & antitrust notice
- Introduction of new members
- Agenda review
| Chairs | - Antitrust Policy Notice: Attendees are reminded to adhere to the meeting agenda and not participate in activities prohibited under antitrust and competition laws. Only members of ToIP who have signed the necessary agreements are permitted to participate in this activity beyond an observer role.
- New Members:
|
| 5 mins | Reflections on ToIP All-Member Meeting on Trust Registries | Chairs | - Excellent attendance and wonderful chat activity—clearly TRs is a hot topic
- Darrell O'Donnell highlighted that Andre Kudra observed that in the EU, the trust registry function is very much associated with governments and regulation (eIDAS), and this seems very centralized.
- There was a lot of chat discussion about how the trust registry function could become much more decentralized with a standardized protocol.
- The sessions on GCCN helped highlight the challenges to actually implementing and making real functioning TRs work.
|
| 20 mins | Open issues with current Working Draft spec | Chairs | - Current Working Draft specification (Google doc)
- Open Issue: specification name
- Drummond Reed pointed out the tension between a general name—ToIP Trust Registry Protocol—vs. a more limited name describing a more limited V1 functionality—ToIP Trust Registry Query Protocol.
- Savita Farooqui preferred the more general name.
- Daniel Bachenheimer said that registration and authorization are important topics that eventually we need to discuss.
- Darrell O'Donnell clarified that the initial scope of authorization was just for controlling what consumers can query the registry—for example preventing DDOS attacks.
- The larger issues of managing a TR - registration and authorization—may eventually need to be in scope.
- Savita said that APIs plus sequence and timing of messages = protocol and suggested Trust Registry Communication Protocol.
- John Walker prefers the more general name Trust Registry Protocol.
- Darrell suggested we could use the more general name and then specify in the V1 spec that we are only initially specifying the query operation.
- sankarshan suggested we make sure that identify the overall patterns of usage, even those that may be outside of the coverage of the spec, to show readers what parts of operating a TR are covered by a specific version of the spec.
- Savita shared that we should identify the sequence of operations that are expected in the protocol that are beyond strictly making the API call.
- Tomislav Markovski felt that the spec should standardize the data model and the requirements for the endpoints. He felt the API is adequate as it is.
- Vitor Pamplona raised a new issue regarding revocation of credentials. There are two scenarios:
- The issuer needs to revoke one credential.
- All credentials from that issuer were invalid because the issuer was fraudulent.
- Vitor pointed out that the solution can be able to show the TR history of a particular issuer.
- One option is that the client keeps the history of query results instead of the TR keeping it.
- Darrell pointed out that we could add an optional call to return the history of a particular issuer, but it does add complexity.
- Daniel Bachenheimer asked about an issuer being revoked from a registry, so we are not talking about revocation of VCs, just revocation of registry entries.
- Vitor pointed out that knowing the history of a TR entry can be valuable information to a holder (or for an app to communicate to a holder).
- Vitor would prefer to get the full history every time.
- DECISION: The specification will include an option to get the history of activity for a registry entry but it will be RECOMMENDED, not REQUIRED.
- Open issue: should the TR DID be the same as the ecosystem governance framework (EGF) DID?
- What's the relationship of the API to this specification? What other scope decisions can we make.
- DECISION: The API should be an integral part of the specification.
- DECISION: The specification must include a data model for the data returned from a query.
|
| 15 mins | Feedback from outreach for review |
| We ran out of time for this agenda item. |
| 5 mins | - Review decisions/action items
- Planning for next meeting
| Chairs | |
Decisions
- DECISION: The API should be an integral part of the specification.
- DECISION: The specification must include a data model for the data returned from a query.
- DECISION: The specification will include an option to get the history of activity for a registry entry but it will be RECOMMENDED, not REQUIRED.
Action Items
