Meeting Date & Time

Jan 8, 2025 This Task Force meets every other Wednesday. There is a single meeting for the NA/EU. (Updates for the APAC time zone will be at the monthly TSWG APAC meeting the first Tuesday of every month.)

NA/EU meeting: 08:00-09:00 PT / 15:00-16:00 UTC

See the Calendar of ToIP Meetings for exact meeting dates, times and Zoom links.

Zoom Meeting Links / Recordings

NA/EU Meeting: https://zoom-lfx.platform.linuxfoundation.org/meeting/96565410414?password=9db52340-ad99-4a33-aa07-c44481d32968

To see the recording of the meeting, click on the calendar entry for the meeting in the ToIP Calendar. The link to the Zoom recording should appear there approximately one hour after the meeting ends.

Attendees

Dan Bachenheimer

Agenda Items and Notes (including all relevant links)

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. NOTICE: In addition to the licensing terms of this Working Group’s JDF charter, this Working Group operates under the official policy that any Working Group Participant who makes a contribution to a Draft Deliverable shall have a maximum of 45 days from the date of that contribution to exclude any Essential Claims pertaining to that contribution. New Members:
2 min	Review of previous action items	Chairs	None
10 mins	IIW #40 Recap	All	@Sam Smith covered KERI security topics, starting with the hardest thing to protect against: the malicious or compromised controller (which requires the watcher network). The controller can do an eclipse attack, where the controller can control the network to hide information. It doesn't even require key compromise. The second day he did key compromise. The third day he covered "bound issuances", i.e., when a verifier cannot verify the key state for issuance of a credential. If keys are compromised, all issuances need to be re-issued. Wenjing and Drummond were able to have a sit-down with Steve McCown, co-chair of the DIF DIDComm WG. They are thinking that the next step for DIDComm is to add binary encoding schemes. They could choose the CESR direction, or they may directly add CBOR. We also discussed running DIDComm over TSP to take advantage of TSP's functions. We believe that it worth trying, as it does not require changes to either spec. @Rob Aaron said that the DIDComm WG is planning to add support for CBOR first with optionality to use other encodings like CESR. We also had several discussions with developers using DIDComm who are now interested in running it over TSP. @Drummond Reed said there was also a lot of interest in developing the trust tasks needed to support First Person Credentials.
10 mins	The Relationship of TSP to MCP and A2A	All	@Wenjing Chu said that the AIMTF has been discussing those protocols being trust tasks. They plan to show some examples in upcoming meetings. This illustrates that all trust task protocols run over TSP but are opaque to TSP—which is exactly the purpose of a spanning protocol.
15	The Relationship Formation Task	@Sam Smith	Relationship formation is a "native trust task" embedded in the TSP itself. It enables forming of TSP relationships. @Sam Smith shared his proposal—see screenshot #1. There are four-letter codes that all start with X. There are 5 payloads defined. The subprotocols are shown in screenshot #2. The interaction pattern is in screenshot #3. They are a hashchain. Wenjing pointed out that currently the thread ID is used for that, and he wants to continue to use that term. We discussed the need for a salty nonce in order to prevent correlation. Screenshot #4 shows the effect on the TSP wrappers. @Wenjing Chu said that relationship formation is covered in section 7 of the TSP spec — see screenshot #5 — and section 9 — screenshot #6. So this is where any changes for relationship formation will be reflected. Sam argued for maintaining the cryptographic agility by including the codes to be strongly embedded in the primitive so that it can be decrypted as long as the CESR was saved. Wenjing asked Sam for CESR codes for Sealed Box. See screenshot #7. Sam said that each Sealed Box option will take 6 codes as shown in screenshot #8. Sam confirmed that the CESR code table space (especially for long codes) is very large: 64 to the 4th. ACTION: @Wenjing Chu to work offline with @Sam Smith to decide about the code values that need to be added to the CESR code table to support Sealed Box in section 9.2.2 of the spec (per issue #9).
15 mins	Open Issues		See the issues list.
5 mins	Review decisions/action items Planning for next meeting	Chairs

Screenshots/Diagrams (numbered for reference in notes above)

#1

#2

#3

#4

#5

#6

#7

#8

Decisions

None

Action Items

ACTION: @Wenjing Chu to work offline with @Sam Smith to decide about the code values that need to be added to the CESR code table to support Sealed Box in section 9.2.2 of the spec (per issue #9).