Updates of general interest to TATF members.

• Drummond Reed announced that Avast has acquired SecureKey.
• Samuel Smith shared that the ACDC Task Force has a new draft of their specification for ACDC chained credentials.
• Judith suggested that we look at https://openidentityexchange.org/a-guide-to-trust-frameworks-for-smart-digital-id?page=self-sovereign-identity-models and asks if we have any feedback.

Review Tim Bouma's diagram (screenshot #1 below).

• Darrell O'Donnell explained the rationale for Tim's diagram.
• He explained that W3C Verifiable Credentials only defines a credential data format and signatures, but not protocols or governance.
• He then showed screenshot #2 to map a number of other credential and key management initiatives into our four layers. This was a test of how well our four-layer model works across all of these different standardization efforts. 
• He pointed out how well the Apple mDL solution fits all the needs but also ties them together in a brittle way.
• Phil Feairheller explained that in screenshot #2, KERI itself does not cross all three levels.
• ACTION: Phil Feairheller and Samuel Smith to create a diagram of KERI and ACDC across the four layers.
• We talked specifically about MDL and how it could be fit into the stack with "shims".
• Vladimir Vujovic explained that SICPA is currently using the Hyperledger Aries protocols and wants DIDComm to span all of it.
• ICAO/DTC is the Internation Civil Aviation Organization/Digital Travel Credential(s) - Guiding Core Principles - ICAO/DTC, not to be confused with the "Direct To Consumer" data model (which may also be relevant).
• ISO/mDL - is International Standards Organization/mobile Drivers License - ISO/IEC 18013-5:2021 Mobile driving license (mDL)

A few new requirement slides have been added and comments have been made on others in the storyline deck of layer-by-layer requirements. Our goal will be to review and incorporate as many comments as we can. (All slide numbers are of 2022-03-23 22:30 PDT.)

Slide 26.

Slide 29 (new).

Slide 33.

Slide 35. Privacy

• Neil Thomson explained his concerns about Layer 3 and privacy. He has been thinking about it in the context of 5G and the way cell phones can be tracked around the world.
• Layer 3 has been treated as a "data exchanged" layer — similar to the OSI session layer (#7) but there may be many other activities going on in a communications session between two parties.
• Neil has been wondering if there is a separate version of the stack that deals exclusively with data and data exchange, because that's different that other types of data exchange.
• He gave the example of a verifier needing to know something from a holder that is not in a credential.
• Those types of other data exchanges may need other considerations around topics like consent, privacy, and data protection.
• Darrell O'Donnell asked if these considerations are "inside" Layer 3 or are they outside of it (or at Layer 4).
• Neil said it may be both.
• Darrell O'Donnell felt that it's likely that there are so many uses of Layer 3 and Layer 4 that it may not be possible for the ToIP stack to go beyond the common baseline interoperability requirements for both layers.
• Neil suggested that we might want to think about "primary data" and "secondary data".
• Drummond suggested that we should think about MUSTs, SHOULDs, and MAYs for each of the layers because the complexity will be increasingly higher at each layer, and especially high at Layer 3 and 4.
• Neil brought up the term "observability" and suggested that we should look at the stack that way. What information can and cannot (or should and should not) be captured or recorded? That information can be very sensitive but also very necessary. So the agreement around what is happening with the data that flows between the parties, including streaming data, is very important. So it is important that we be able to answer how data exchange fits within the model and how it leverages information coming out of Layer 1, 2 and 3.
• Neil is inclined to draw the full picture of the stack and then figure out how data exchange fits within the model. For example, where do intermediaries fit?

Slide 38 — other L2 requirements:

• Encoding methods?
• Wallet backup and recovery?
• Multi-device wallet synchronization?

Darrell O'Donnell said that the last two bullets are out of scope.

Slide 43 (new).

Slide 46 (new).

Sam wanted to bring up a key architectural point about roots of trust.

• If an entity is not fully in control of their primary root of trust, then that entity is trusting some third part(ies). See screenshot #5 below.
• This affects the "trust basis" for an ecosystem and all the participants in that trust domain.
• The goal of ToIP is to enable transitive trust.
• So we want to be very careful to not have any shared control over root of trusts—that would be giving away control. Also known as "the Hotel California problem". See screenshot #6.
• As long as control stays within one trust domain, then value can flow across them. But if there is one shared trust domain, everyone is locked into it. See screenshot #7.
• Drummond Reed asked if the conclusion is that primary roots of trust MUST be at Layer 2 in order for an entity not to be locked into a secondary root of trust at Layer 1.
• There was agreement that this architectural principle is in fact quite important: it means that Layer 1 public utilities are very helpful as secondary root of trust, but that for full control of an identifier and the associated key pairs, you need to use DID method that does not depend on the secondary root of trust.
• The only solution that can provide portability across Layer 1 public utilities is an atomic swap protocol that works across all participating utilities.
• DECISION: The ToIP Technology Architecture Specification shall include a discussion of trust domains and a recommendation that: 1) primary roots of trust SHOULD be implemented in digital wallets at Layer 2 in order to avoid using shared control and "ledger lock", and 2) Layer 1 public utilities SHOULD be used as secondary roots of trust.

Our stated goal from the last meeting is to have a first full Working Draft of the spec by Internet Identity Workshop (April 26-28). This agenda item is to discuss a POA (plan of attack) for achieving that. Note that we also need to prepare a slide deck to present the spec in an IIW session.

• ACTION: Drummond Reed to begin working on a revised outline of the Google doc version of the ToIP Technology Architecture Specification to reflect the input from these meetings and the storyline deck.