Former user (Deleted) and Paul Knowles will discuss the role of intermediaries in the ToIP stack; discuss a "plan of attack" for developing a consensus picture of ToIP protocol stack layering.
Agenda Items and Notes (including all relevant links)
Time
Agenda Item
Lead
Notes
5 min
Start recording
Welcome & antitrust notice
Introduction of new members
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:
5 min
Review of previous action items
Chairs
ACTION: Chairs to develop a "plan of attack" for starting to refine the protocol stack diagram suggestions and begin drafting the ToIP Technology Architecture Specification.
30 mins
The potential role of intermediaries in the ToIP stack
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
15 mins
Plan-of-attack on preparing a more detailed ToIP protocol stack diagram
Update on a conversation Drummond had with Sam 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.
