NA/EU:

• Sam Smith: " like the term protocol suite it better captures a set of thin layers." Drummond Reed, Antti Kettunen, and Oskar van Deventer all agreed.
• Partha Pal: "Does 'contextual trust'  include time bound?"
  • Drummond Reed: "Yes, time can be one factor in context."
  • Daniel Bachenheimer: "right - temporal certs are the medium of exchange in the FIDO protocol."
• Scott Perry: "Trust in this context will always be broken into two separate components: 1) Do I trust whether the originator of the message actually sent the message and 2) Do I trust the message.  My contention is that only "1" can be solved in this task force.  "2" can only be assured through governance."
  • Scott Whitmire: "How can “2” be solved through governance? Trusting the message has a meaning, what meaning are you using?"
• Sam Smith: "There are several defintions of "authenticity" in the dictionary. One is expressed by what is called "authentication" as a process.  Daniel is using other definitions of authenticity besides the narrow definition of authentication implied by authenticatable. So to the extent we desire to support other types of authenticity, then we need additional information."
• Partha Pal: "Human <> Human trust , Human <> System trust , System <> System trust , need to be addressed separately ? Curious to know..."
• Scott Perry: "In this delivery message, the payload is a blob.  Anyone can say anything.  How someone trusts the blob is based on the ToIP trust principles.  Many factors go into that such as reputation of sender, a trust registry process, a trust assurance scheme, etc."
  • Drummond Reed: "Scott, that’s true, but there are many “trust task-specific” elements of making trust decisions. What I think Daniel is getting at is the “universal” elements of trust decisions that belong at the TSP layer, i.e., they are shared by many if not all trust tasks."
  • Scott Whitmire: "Anything related to the payload blob, as Scott put it, is the responsibility of higher layers. Thus, trusting the actual message, including context and purpose, are not the responsibility of the spanning layer."
  • Keerthi Thomas: "How the payload will be interpreted will depend on the application context."
  • Drummond Reed: "That’s the debate we’ll have: which elements are universal enough to be at the spanning layer."
  • Scott Perry: "Given Sam's minimization tenet, we cannot expect the trust spanning layer to do anything about the payload. Consistent with IP, the neck of the hourglass does nothing about the payload."
• Sam Smith: "Other elements in a protocol header like message type can make it unambigous what the intent of the speaker was without providing a destination identifier. I think it is misstating that my minimization is only the weakest bottom layer I have stated several times that we need to build a protocol stack of thin additive layers so we should consider whats in the payload at upper layers in a suite of layers."
  • Scott Whitmire: "I think we’re on the same page. In IP, the payload is just a package that needs to be delivered. The header contains only what is necessary to carry that out. If we follow that idea, any decision that depends on the content of a specific payload belongs in a higher layer."
  • Scott Perry: "@Sam, then the focus is on the attributes of the payload not the content of the payload."
• Oskar van Deventer: "More weakness" == "Fewer features"?"
  • Drummond Reed: "Yes, but with the subtleties that Daniel is explaining."
• Scott Whitmire: "So, what should go into the spanning layer? Basically, what is required to authenticate the source and provenance of the payload. Anything related to a specific payload goes elsewhere."
• Andor: "Great stuff. Has some big implications for the TRTF, so looking forward to learn more." Antti Kettunen agreed.
• Andor: "Thanks @Daniel. Great presentation. Loving these proposals." Multiple thumbs up.

Sam Smith also started this new Github Discussions thread.

APAC (note that Daniel Hardman was not able to attend due to his time zone in Switzerland):

• Michael Michael shared screenshot #1 below as a way of illustrating the credential sender-receiver model. A video of this Internet Credential (InterCredential) Architecture Reference Model 0.70 ft. 4-Corner Interop Model is available here.
• Michael also shared screenshot #2 to discuss interfaces between senders and receivers in a series of protocol usages.
• We had a good discussion about Daniel Hardman's proposed "destination" element and the challenge of multiple recipients and group messaging.
  • Drummond pointed out this was intentionally put out of scope for the DIDComm V2 Working Group, but that they are keen on tackling it in a subsequent version.
  • Andor said he plans to raise this question in the Proposal #2 discussion thread.
• At the end of the all, Drummond Reed pointed out one of the final slides in Daniel Hardman's deck (screenshot #3) that maps many of the features of the DIDComm V2 basic protocol (and other "DIDComm protocols" built on top of the basic protocol) to the ToIP stack, both at the TSP layer (Layer 2) and at the trust task layer (Layer 3). In his view, that slide could be worthy of an entire dedicated TSPTF meeting to discuss in depth — and certainly should be discussed in depth in Github Discussions.
  • Drummond noted that 6 attendees on the NA/EU call agreed it was a seminal slide.

Next week's meeting will be Proposal #3 from Wenjing Chu.