...
Time | Agenda Item | Lead | Notes |
3 min |
| Chairs |
|
2 min | Review of previous action items | Chairs |
|
5 min | VID Decision Review | ALL | Reviewing these two decisions about VIDs made at the last meeting to make sure everyone is aware of them:
|
5 min | Protocol Versioning | Sam has started a discussion on the options about versioning. Here is the issue discussion. See screenshot #1 below. The discussion was about how the versioning representation and content in CESR should work. The current CESR spec is here ACTION: Samuel Smith to add a version for TSP. The options are:
ACTION: ALL — review the discussion on the protocol version identifier and share any feedback (positive, negative, or alternative). APAC: We further discussed protocol versioning. Wenjing Chu proposed that one version for the TSP as a whole was the most practical approach. After much discussion there, was a consensus that was the best approach, mostly because of our goal of keeping the protocol as simple (and stable) as possible. PROPOSED DECISION: The TSP shall have one version number as a whole, and not separate version numbers for the nested protocol layers that are defined by the TSP specification. | |
30 min | Working Draft Feedback Review | ALL | Per second action item above. All references are to the current Working Draft in Google docs. Wenjing started out discussing section 7.1.1. The key question is about the behavior of the two VIDs in creating a direct connection. What should happen when a VID does not verify? Ed Eykholt asked the question of whether this error would involve a change in key state that the other party does not know yet. Would that be a common example? Samuel Smith clarified that, with KERI, all key state messages are asynchronous, so the messages may be delivered out of order, so receivers of messages need to decide if they want to escrow messages. If so, the receiver could decide to be silent or could decide to respond with an error. Neil Thomson asked, if the VID verification fails, why the receiver doesn't just reply "Fail"? Samuel Smith explained that even a fail message gives an attacker info. This led to a discussion about synchronous vs. asynchronous protocols. DECISION: TSP will be asynchronous to keep it as simple as possible; any synchronous messaging protocol should be built as a layer on top of the TSP. There was agreement that the options for what the receiving party to a TSP message that does not verify are up to the receiving party and may depend on the context of the relationship (possibly as established by the OOBI). For example, the receiver might escrow the message in order to verify it with a subsequent key state for the sender's VID. Drummond Reed suggested it could be resolved via an OOBER (Out-of-Band-Error-Resolution) approach (about which we can make a note). ACTION: Drummond Reed and Ed Eykholt to meet offline and discuss the major questions Ed has about areas of the spec that might frustrate initial implementers, and then start a GitHub discussion with their conclusions and recommendations. We also discussed the tradeoffs of what should be in the TSP vs. in the layers above or below. Our goal is to keep the TSP as simple as possible so it is as widely useful as possible. APAC: In our discussion of section 7.1.1, there was agreement that we want to keep the TSP as simple as possible, and so questions about synchronous vs. asynchronous messaging should be tackled by higher-layer (trust task) protocols. Jo Spencer suggested that the spec should say that explicitly so that implementers understand why certain protocol features they might be looking for/expecting are not in the TSP spec. |
5 min | Prepare for Implementers Kickoff Meeting | ChairsPer third action item above | We agreed that we're still on course to prepare for a Implementer's Draft and kickoff meeting by early February. |
5 min | New Combined APAC Meeting | Chairs | The TSPTF, Trust Registry TF, and X.509 VID TF are combining their APAC meetings into one slot (Wednesdays 18:00-19:00 PT / 02:00-03:00 UTC) to leverage time and encourage attendance. |
5 mins |
| Chairs |
...