ALL

Wenjing Chu Sam Smith

Sam has started a GitHub 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: Sam Smith to add a version for TSP.

The options are:

1. One version type for all of TSP.
2. One version type for each message type within the protocol.

ACTION: ALL — review the discussion on the protocol version identifier and share any feedback (positive, negative, or alternative).

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?

Sam 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"? Sam Smith explained that even a fail message gives an attacker info.

This led to a discussion about synchronous vs. asynchronous protocols.

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.

We agreed that we're still on course to prepare for a Implementer's Draft and kickoff meeting by early February.

ACTION: Drummond Reed to check with Darrell O'Donnell and Kevin Griffin about progress on a ToIP Technical Specification Template (presumably using the Spec-Up tooling from DIF) so that Wenjing Chu has a clear path to take once we are ready to convert the Working Draft from Google docs to GitHub Markdown (which is what the Spec-Up tooling produces).

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.

ACTION: Drummond Reed to drop a note to Michelle Janata to add the Trust Registry TF to the calendar invite description for the combined APAC meetings on Wednesdays 18:00-19:00 PT / 02:00-03:00 UTC.