Updates of general interest to TATF members.

• Samuel Smith shared that the latest editor draft of the ACDC spec has been published.
  
  • This version has graduated disclosure and contractually protected disclosure.
  • Graduated disclosure is an advanced form of selective disclosure that is protected by contract.
  • Graduated disclosure includes partial disclosure, selective disclosure, and compact disclosure.
  • Partial disclosure is sharing just metadata.
  • Selective disclosure is sharing just some of the claims in a credential, or just making proofs about the claims.
  • Compact disclosure sends only digital signatures on SAIDs.
  • Contractually protected disclosure uses graduated disclosure.
  • At each step, the holder is sharing just the amount they need to to proceed with a transaction.
  • ACDC credentials also simplify credential presentations because each presentation can itself be a chained credential, even when applying selective disclosure.
• Wenjing Chu said he had read the paper about chain-link confidentiality that Sam had brought up in the APAC call last week, and asked Sam how the legal paper applied to ACDC chain-link credentials.
  
  • Sam explained that it brings confidentiality law—not privacy—to bear on shared data.
  • Wenjing asked whether it was supposed to work like software licenses.
  • Sam explained that no, it works by contract.
• Sam and Drummond said they are going to a ACDC for Muggles session at IIW.

Drummond Reed
Antti Kettunen

John Phillips (APAC)

Report on progress and plan for calls this afternoon and next Tuesday.

• Drummond explained that the group working on the post got "stuck" with regard to the key messages.
• Daniel Bachenheimer pointed out that the post was not specific about what we propose as solutions to the issues we have with the post.
• Drummond explained that Viky Manaila suggested that the ToIP Foundation make a submission to the Toolbox Consultation portal offering our assistance.
• Tim Bouma has a general concern about the European Digital Identity Wallets approach being too "authoritarian".
• Antti Kettunen joined the call and shared that he has learned several things through this dialog about the blog post. For example, he has learned that the requirements for a wallet enable the credentials to be shared with non-governmental wallets.
  • His concern is focused that the approach the EU is taking is potentially going to make a digital identity wallet a high-value "luxury" instead of making it a commodity that is widely adopted.
  • He is looking forward to working out the key points of the post.
• Darrell O'Donnell is advising several governments about digital identity wallets and said that there is a difference between a "high value credential" and a "high assurance credential".
  
  • He used the example of authorizing a $500K loan or money transfer — that requires a high-assurance credential. He questions whether that is in fact a real use case.
• Allan asked about how the use cases that we will cite in the ToIP Technology Architecture Specification spec and compare them with the ones that the EU is focused on. He makes the point because if we want to try to influence them, we need to have something to influence them with.
  • The strongest position we could be in could be to have our own test suite.
  • Antti asked why they would listen to us. He said there are multiple EU member states who are supporters of SSI architecture, and ToIP can amplify those opinions.
• Vlad Zubenko asked about the high-security use case and said that if the wallet was able to strongly prove the identity binding with the owner, then the bank or other relying party could in fact rely on the wallet and the high-assurance credential.
  
  • Darrell explained that it is a question of priorities — focusing on high-assurance credentials and use cases will have an order of magnitude lower adoption.
  • Daniel Bachenheimer confirmed that digital wallets are intended to provide that identity binding.
• Allan Thomson shared the analogy of the initial very simple use case that the 802.11 wifi standards focused on: a person with a wifi-enabled phone being able to walk into a coffee shop and connect. Many more higher-value and complex uses cases then became possible.  But you have to nail the very simple use cases first.
• There was a general feeling this same logic applied to V1 of the ToIP stack.

Walk-through of the progress on sections 1 through 6 of the ToIP Technology Architecture Specification.

APAC

• We talked about the parallels between ToIP standards and 802.11 wifi standards.
• In the morning session, Allan Thomson used this analogy: ________
• Wenjing Chu explained how the process worked between the 802.11 technical standards committee and the Wifi Alliance and the manufacturers of the chipsets that implemented each version of the standard.
  
  • Wenjing said that the wifi process is fairly simple compared to 5G.
  • Drummond pointed out that we don't have the constraint of hardware production.
  • Judith observed that with ToIP implementers still have the need for a stable, well-developed roadmap process.
  • Wenjing agreed, and emphasized that is why we need to focus on specific use cases. Even though it won't involve chipsets, it does involve changes in the market, and changes in user behavior.
• We then discussed sections 5, 6, and 7 of the spec.
  • We had a good discussion about Figure 7 and revised it to the version shown below in screenshot #1.
  • DECISION: In section 7 of the spec, will use the "neck and waist shape" double-spanning layer diagram (above) to explain the four layer architecture of the ToIP stack.
  • We also agreed that section 7, which currently contains content from the Design Principles for the ToIP Stack V1, can be shortened if it is proceeded by the content in sections 1 through 6.

ACTION: Wenjing Chu to: a) draft the content for section 5: Reference Architecture, and b) edit/revise/shorten the content in section 7: Architectural Layering of the ToIP Stack.

ACTION: Drummond Reed to a) add initial content to sections 7.4 through 7.7, and b) convert the rest of the content from the storyline slide deck into sections 9, 10, and 11.