| 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:
|
| 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
- 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.
- PROTOCOL
- ACTION: Drummond Reed to recommend what text is needed in this section vs. the overall Requirements section.
- 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
|
| 10 mins | Restructure of Requirements section |
| - See this suggestion (in a comment) from sankarshan
- Sankarshan ran through his proposed three categories; there was consensus those would be good.
- ACTION: sankarshan will do a pass on the suggested reorganization of the Requirements section.
- We discussed Sankarshan's suggestion about the age of the TR
- Savita said it could be derived from date of conception
- We discussed 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 raised the question about "super public DIDs"—don't the DIDs for TRs need to become very well-known
- 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 agrees 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, TR metadata will be out of scope, however we will publish an Appendix with a proposed TR metadata format that can be an export capability of a JSON file that TR can define.
- 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.
|
| 25 mins | Other open spec issues |
| |
| 5 mins | Any other topics |
| - Jim St.Clair brought up the topic of rules engines and automated rules processing in future versions.
- ACTION: Jim St.Clair will draft text for the Scope section about this as a future feature.
- We talked about final publication being only a Markdown file and a YAML file. We just need the output artifact.
|
| 5 mins | - Review decisions/action items
- Planning for next meeting
| Chairs |
|
