Time | Agenda Item | Lead | Notes |
5 min | | Chairs | |
10 mins | Review of action items from the last meeting | | |
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 | | Chairs | |