Jan Lindquist
Paul Knowles

Jan and Paul will take us deep into the question of the role of intermediaries in the ToIP stack. See this January 13th ToIP blog post — and especially diagram #1 below (taken from that post).

• The blog post was inspired by the adoption of the Data Governance Act (DGA) in the EU.
  • It was written by members of the Inputs and Semantics WG.
• The Data Governance Act builds on EU GDPR (General Data Protection Regulation).
  • See diagram #2 below for an overview of how the GDPR roles (data subject, data controller, data processor) map into the DGA architecture.
  • A very important aspect of the DGA is that all the intermediaries must be registered with the government.
• To map the DGA architecture into the ToIP model, Jan and his co-authors created diagram #1 below.
  • The key new role in that diagram is the Intermediary. This is essentially a specialized form of agent.
  • The intermediary serves a number of key functions in this enhanced model.
  • One of the them is adding/enhancing the data semantics per the ISWG model.
• Daniel Bachenheimer pointed out that one of the main points of the ToIP model is to "disintermediate" current intermediaries.
  
  • An example he used is the IATA Travel Pass architecture (and the Good Health Pass architecture) where the intermediary became another secondary issuer.
  • Jan was interested in how the intermediary could share the data in other forms besides verifiable credentials.
  • This role can take advantage of a semantic container as defined by the ISWG.
• Darrell O'Donnell did not feel that this model needs to break anything in the ToIP model.
  • The intermediary model can fit within the ToIP model by becoming a credential.
  • He shared diagram #3 below.
  • His point was the key privacy issues are:
    • Awareness of connections.
    • Content of data communicated within for connections.
    • If both of these can be controlled by the subject/holder, then it can all fit the ToIP model.
• Antti Kettunen explained that there are a whole bunch of ToIP Layer 4 uses cases that can take great advantage of intermediaries.
  • This is the key role highlighted in the MyData operator role.
• Daniel Bachenheimer asked the question about how one cryptographically verifies the provenance of the data passing through the intermediary.
• Tim Bouma compared this to the Canadian concept of "civic data trusts", which are very useful.
  • But Canadian privacy legislation does need to catch up.
• Bart Suichies asked the question about the "semantic data container" part.
  • He pointed out the Web3 meme that "no one wants to run their own server".
  • But this raises the question of where the data is hosted/processed.
  • Jan suggested that this is a core focus of the Data Storage and Portability Task Force meetings hosted by the Inputs and Semantics WG.
  • Bart suggested that it's basically a service using protocols, rather than a protocol itself (it might require some additional protocols, to sort out the secure storage for instance)
• Daniel Bachenheimer brought up the challenges of ICAO and their ePassport standards.
  • They currently don't allow any form of selective disclosure.
  • ICAO also does not allow any form of intermediation of the passport object. The big question will be whether the government will allow the ICAO data to be intermediated.
  • Darrell O'Donnell suggested that will eventually change, but it's not a battle to fight now.
• Antti Kettunen said that an intermediary as a role in ToIP scenarios and potentially directly in the stack architecture.
  • Darrell O'Donnell said that role can fit into many co-protocol patterns.
  • Wenjing Chu said that this pattern can be generalized at Layer 3, but it may also be carried out at other layers.
  • Jan said that we should look at the functions necessary to support an intermediary.
  • Wenjing pointed out that is can be a question of the legal parties in a flow.
  • Drummond pointed out that intermediaries play a very critical role in the payment protocol proposed by TBDex: https://tbdex.io/whitepaper.pdf 
• Neil Thomson suggested that the role of an intermediary may be part of a complete separate stack.
  
  • It does not always have to be credential exchange.
• The two ISWG task forces that alternate weekly are Mondays at 6PM CET:
  • Storage and Portability
  • Privacy and Risk

APAC Discussion:

• Neil said that the topic of intermediaries also intersects with the work of the ACDC Task Force on chained credentials.
• Darrell spoke to diagram #3 below about what privacy/confidentiality needs to apply to the ToIP stack. The different types of confidentiality are what we need to support in the design of the stack. As a result, Darrell believes that our design is capable of supporting all those requirements.
• DanB and Drummond both agreed that it is a very important to separate confidentially of the existence of a connection vs. the contents of a communication within the connection.
• Judith asked about legal regulation. Wenjing pointed out that the distinction about awareness by a third party does not apply in the U.S. to telecos because under law they are not considered a third-party. This is also true for ISPs and HTTP.
• Drummond pointed out that this may vary with legal jurisdictions. Wenjing pointed out that the actual physics of what information is available where is the same for all TCP/IP and HTTP.
• We agreed that when we are defining the ToIP stack, this consideration of what metadata is "out of the party's control" is a critical design consideration.

Update on a conversation Drummond had with Samuel Smith about how we could start to "decompose" the components of KERI and DIDComm to assemble a unified stack.

• Darrell O'Donnell suggested that we need to move into "writing mode" and follow the "storyline" format that Drummond has used.
• Tim Bouma said he is a big fan of Dan Roam's approach https://www.amazon.com/Pop-up-Pitch-Two-Hour-Persuasive-Presentation/dp/1541774515
• Samuel Smith talked about the overall approach to "decomposing" the layers involved with KERI and DIDComm.
  
  • This involves covering how connections are formed securely - using out-of-band interactions (OOBI) and and out-of-band authentication (OOBA)

APAC

• We agreed to start a "storyline" format deck to tackle the written description and diagramming of the stack.
• ACTION: Drummond Reed to prepare a starting storyline deck and share via Slack before next week's meeting.
• Drummond also explained that Samuel Smith is working out the layering approach he recommends "from the bottom up" (i.e., starting with KERI AIDs and how connections are formed and authenticated).
• ACTION: Drummond Reed to interview Sam to start to document Sam's approach to "filling in the details" of the four layers.