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.