Time

Agenda Item

Lead

Notes

3 min

• Start recording

• Welcome & antitrust notice

• New member introductions

• 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:

2 min

Review of previous action items

Chairs

• Jeff noted that he is currently looking at the ToIP Technology Architecture Specification

30 mins

Complete the first round of feedback on the Working Draft

@Wenjing Chu @Sam Smith 

See the comments on the Working Draft.

We discussed all the remaining comments, including a number of them from @Jo Spencer and @Ed Eykholt. Wenjing was satisfied that we either resolved or had proposed resolutions for all comments so far.

APAC:

We discussed message ordering and agreed that the TSP would not natively need to support it as it could be handled by higher layer protocols.

@Jo Spencer: "Functional processing may depend on the retention of order. In payments systems, if the payment messages are not received (or more correctly processed by the recipient) in the same order as sent, the second (sent) payment could work, but the first one fail. It's a higher order processing logic (task) that needs to understand this. It's not the role of the TSP".

We discussed the topics of attachments and agreed that they would just be included as body content encoded as CESR payloads.

We discussed that in Section 9, we will include all of the CESR codes for serialization once we have reviewed all of the required messages in the spec.

We also discussed aligning all of the terminology about describing different message components: message, header, body, etc. @Wenjing Chu wants to use terminology aligned with HPKE.

We discussed Linked Data and how it would work with TSP. It is simply a type of data that could be carried in the body/payload of a message. Any VIDs, DIDs, or other identifiers of those Linked Data graphs can ride with the payload.

20 mins

Key rotation

@Wenjing Chu 

Wenjing shared screenshots #1 and #2 to explain the question of how TSP should handle key rotation.

There was a long discussion (see the recording). The result was two points:

1. A key rotation flag will be specified but it will be OPTIONAL.

2. Ideally this flag bit will be able to be specified within the 24 bits of the message type field.

APAC:

We went over screenshots #1 and #2 and discussed the different options. @Darrell O'Donnell made the point that the "flag" option may not work because the flag indicating a key change would be in a message that was already encrypted with the new key.

We discussed the option that it should be a standard control message.

ACTION: @Wenjing Chu to review the feedback on the topic of key rotation and propose a solution.

5 min

Documenting design decisions

@Darrell O'Donnell 

Darrell made the suggestion that the final section of the spec (or a separate Guide document) should document 

5 mins

• Review decisions/action items

• Planning for next meeting 

Chairs

ACTION: @Drummond Reed to add HPKE support to the agenda for the next meeting.