| 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: none
|
| 10 mins | Review of action items from the last meeting |
| - FRONT MATTER SECTIONS
- ACTION: Drummond Reedto review all front matter sections to ensure they are ready for an Implementers Draft.
- REQUIREMENTS
- ACTION: Darrell O'Donnell and Drummond Reed to review notes and either add additional requirements or remove the notes by next week's meeting.
- Still needs to be completed.
- SCOPE
- DATA MODEL
- ACTION: Darrell O'Donnell to propose a textual description of the data model that refers to Appendix A for the normative requirements.
- Carry forward.
- PROTOCOL
- ACTION: Drummond Reed to recommend what text is needed in this section vs. the overall Requirements section.
- Carry forward.
- APPENDIX A: OpenAPI Specification
- ACTION: Darrell O'Donnell to complete any other edits to the OpenAPI specification and then add the authoritative links to Appendix A for the Implementer's Draft.
- Carry forward (progress discussed on this call)
|
| 10 mins | Restructure of Requirements section |
| - See this suggestion (in a comment) from sankarshan
- Sankarshan ran through his proposed three categories (discovery, security, and protocol)
- There was consensus those would be good.
- ACTION: sankarshan will apply his suggested reorganization of the Requirements section before next week's call.
- Next we discussed Sankarshan's suggestion about the age of the TR.
- Savita Farooqui said it could be derived from date of conception.
- That took us into a discussion about the generation of trust signals and metadata such as what GCCN is doing.
- Eric Drury suggested that the DID for the registry would be one signal from the standpoint of inception.
- However the generation of the DID and the operation of the TR may not be connected.
- It is a helpful trust signal, however.
- Eric pointed out that it would part of the "KYC of the registry".
- Drummond Reed pointed out that TRs essentially need not just public DIDs, but "super public DIDs"— DIDs that become very well-known, much like root certificates for conventional CAs.
- Sankarshan: "The age might be out of scope for v1.0 obviously. However the issue of trust signals and how implementations like GCCN would like to determine it using metadata which can be easily gathered and understood - that is something we will need to revisit in the near term (ie. not right now)"
- Darrell: "My point is that GCCN is doing work about what the metadata will be. When it lands on a schema that is executable the next question is “what metadata should we be able to harvest from a trust registry directly - as opposed to building/deriving?”
- Darrell: there should be a "getMetadata" call defined in the future.
- John Walker It should start with a minimal description — it should be atomic, and limited to the base information any TR directory would need. There should be a single description file that the TR can exchange with a client.
- John agreed it can be a future feature, but does not have to be in V1.
- Savita Farooqui suggested that getMetadata should be part of a future version, and the definition of the JSON object (or other formats) is to be defined.
- DECISION: In the V1 spec, Trust Registry metadata will be out of scope, however we will add a statement to the Scope section proposing it for a future version.
- ACTION: Darrell O'Donnell and Drummond Reed to add to the Scope section that TR metadata is out of scope for this version of the specification but is planned for a future version.
|
| 25 mins | Other open spec issues |
| - See the other comments in the ToIP Trust Registry Protocol V1 Specification (Google doc)
- Darrell O'Donnell said that Tomislav Markovski make two suggested changes to the API
- Changed from a list to an object for anything that was returning more than one value.
- Switched to RFC-style HTTP responses that return a formal object instead of just an error number.
- At this point Darrell considers the API definition ready.
- ACTION: John Walker to review the API and post feedback to our Slack channel.
|
| 5 mins | Any other topics |
| - Jim StClair brought up the topic of rules engines and automated rules processing in future versions.
- ACTION: Jim StClair will draft some text for the Scope section about rules processing as a future feature.
- We discussion final publication consisting of just a Markdown file and a YAML file. We just need the output artifact.
- DECISION: For the public review period, we will use a Google doc and the YAML file. Once we are ready to finalize the V1 specification, we will convert the Google doc to a Markdown file, so the final V1 specification will consist of a Markdown file and a YAML file.
|
| 5 mins | - Review decisions/action items
- Planning for next meeting
| Chairs |