Updates of general interest to TATF members.

• Microsoft made a big announcement yesterday about Microsoft Entra. They are using the issuer/holder/verifier model with a trust fabric. Tim Bouma observes that "the big players are moving slowly". 
  • Daniel Bachenheimer noted that Microsoft's play is aimed at the enterprise.
  • Vladimir.Vujovic observed that most of the enterprises that use Microsoft technology because Microsoft Authenticator is the user's wallet.
  • Tim noted that the consumer space is still "wide open".
  • Vikas Malhotra was not sure what kind of database or Layer 1 technology they were using. DanB confirmed that it was did:ion. Tim is going to check with his contacts to find out more.
  • Kevin Dean pointed out that Microsoft usually expands from enterprise to consumer; that is their usual pattern.
  • Drummond Reed mentioned a discussion with Ankur Patel of Microsoft at the European Identity Conference about finally joining ToIP to tackle interop.
  • Tim added that this can actually make it much easier for policymakers to understand the new model — Microsoft can really help.

• ACTION: Neil Thomson will consolidate the terms being defined for purposes of this spec into a glossary at the end of the spec. Available for comment/suggest @ TATF Spec - Working Glossary. A placeholder until we have a terms wiki set up.
• ACTION: Drummond Reed will work with the Concepts and Terminology WG members to set up a terms wiki for the Technology Stack WG that we can begin using immediately with this spec.
• ACTION: Drummond Reed to add two items to next week's agenda: 1) thomsona presenting on use cases, 2) Moving the spec from Google docs to GitHub.

We reviewed a proposal from Allan call Interoperability Test Cases (now posted to the TSWG Google Drive folder). 

• It begins with a high-level component diagram to establish an overall framework of components to be tested. See screenshot #1 below.
• It presents a set of four typical use cases for verifiable credentials.
• It then defines a framework for interoperability testing.
• The first part is a set of test case categories to help organize test cases.
• Next it defines a method for defining specific test profiles against which implementations can be tested. 
• It gives an example of how a specific software stack can be tested against a specific example test profile.
• Allan noted that once we develop a test suite, we will need to either:
  • Develop and operate our own test harness against which implementations can be tested (and potentially certified, either by ToIP or third parties)
  • Self-certification
• Allan then reviewed specific generic tests that are proposed in the document in several categories, including:
  • Connection and authentication (L2)
  • VC issuance and presentation (L3)
  • Interaction with Layer 1 networks (L1)
  • UI/UX tests (L2) focused on human usage
• Wenjing Chu thinks that this is a wonderful contribution to being able to translate the ToIP Technology Architecture spec into an actual test harness.
• Neil Thomson expressed that the number of combinations of different elements at each layer can lead to an explosion of possibilities to be tested.
  • Allan explained that this is the reality of where the tech is right now. The market will start to narrow down the sets of possibilities by choosing the some profiles in which to prove interop.
  • Neil agreed that the test suite structure can be structured to support that.
• Wenjing said that, from a spec editor standpoint, the high-level descriptions are probably the type of high-level use case that would fit at the start of the document.
  • Another one he noted was payments. We discussed that briefly as an option for Layer 3.
  • Tim pointed out that proof of age is a common one.
  • Allan agreed that he would add those use cases to the table in his document.
• ACTION: thomsona to add a few additional high-level motivational use cases to his Interoperability Test Cases document.

APAC

• thomsona gave another overview of his Interoperability Test Cases contribution.
• He emphasized that an interoperability test suite could be used for either self-certification, ToIP certification, or third-party certification.
• Neil Thomson suggested: "There is a case to be made for "sanity suite" use cases (test cases) which is a small number of difficult use/test cases which are a "stress test" to check if changes have broken a wide range of interoperability tests. The intention is as a "canary in a coal mine" which point to a need for running a "full" compliance test suite" The sanity suite also flags to those new to interop as to critical areas of compatibility."
• Allan agreed that many interoperability test harnesses don't test the "non-happy paths". A good test harness will test both happy and sad paths.
• Allan also suggested that we develop the tests that allow it to be integrated into a testing lab or that can be downloaded for private internal testing because there can be issues with public testing.
• Darrell O'Donnell explained how he has designed test suites before so testing can be done locally but the results can be certified by third parties. He thinks this will really be needed for the ToIP stack.
• Allan agreed that interoperability problems are extremely expensive, which is why automation of interoperability verification is so important.
• Jo Spencer likes the approach and shared that SSI solutions can include standard issuance and verification services—and even wallet verification services—can be part of offerings from governments and others in the industry. And he seconded that the test harness should support failure scenarios.
• Allan shared his recommendation of how to build the test suite: it is made to be configured by profiles than then run the appropriate tests to be run based on that profile.
• Daniel Bachenheimer described a test harnesses he has worked with,
•  https://www.niem.gov/about-niem/niem-model, and said it can be very elaborate but also very useful.
• Darrell O'Donnell mentioned the Hyperledger Aries Interoperability test profiles and its test harness system.
• Drummond Reed mentioned the U.S. Department of Homeland Security SVIP interop test suite.
• Wenjing Chu suggested again that we should revive the Interoperability Task Force. 

Check-in on progress on the ToIP Technical Architecture Spec - Working Draft.

On the NA/EU call we ran out of time so we deferred this to the APAC call.

APAC:

• Wenjing explained that most of the work this past week has been on resolving comments. This is where we could benefit from starting to work issues on GitHub issues (see the next topic).
• Wenjing has not completed all of section 5, but feels that the rest of it can be completed fairly quickly once we have the earlier comments resolved.
• Then we can tackle layer-by-layer requirements. Both Wenjing and Neil Thomson suggested that could also be a separate document.

It has been suggested we start using GitHub to edit the spec in Markdown. However Darrell O'Donnell (among others) feels the spec is still incomplete enough that Google docs is a much more user-friendly editing platform until the document is closer to completion. However an intermediate step would be to start using GitHub issues to discuss issues that are flagged in the Google doc.

This led to a short but decisive discussion with the following outcomes:

• DECISION: We will continue to edit the existing Google doc working draft of the ToIP Technical Architecture Spec as a Google doc until the end of June 2022. At that point we will freeze the Google doc and convert it to Markdown in GitHub for completion. Until then, a subteam headed by Wenjing Chu and Neil Thomson can begin moving over sections of the document that are already "content complete" in advance of the June 30 deadline.
• DECISION: We will immediately begin using GitHub issues to discuss more complex issues as soon as a GitHub repo can be set up.
• ACTION: Wenjing Chu and Drummond Reed will work with Judith Fleenor and Elisa Trevino to contact Kevin Griffin about setting up the repo.

APAC:

Tim shared a new model he has developed for explaining the stack to policymakers and other non-technical audiences. See screenshots #2 and #3.

Quotes from Tim:

• "The reason our work here is so important is that we have the ability to scale trust."
• "People either want to prove something or pay something."
• "Everything starts with the identification function."
• "Data is presented and then either accepted or rejected."

Other notes from the discussion:

• Tim's screenshot #2 introduces the role of the "Registrar", which corresponds to the ToIP concept of a trust registry.
• Tim believes that whomever combines proof-of-identity and proof-of-payment is going to be a big winner.
• He used the analogy of Thomas Cromwell's invention of vital statistic registries in England. They tracked baptisms and funerals as the key statistics that needed tracking (not births and deaths, because they are not actually social events).
• Daniel Bachenheimer pointed out that in South Africa, you legally can't bury someone until their death has been recorded is to avoid fraud.
• DanB also pointed out that issuers, holders, and verifiers are all active in the diamond in screenshot #2, but the registrar is more passive. He felt it maps to the governance function, which is why ToIP shows the bottom point of the diamond as the governing authority.
• Tim pointed out that an entity can play any role in the diamond.
• Lastly, Tim explained that his conceptual model is actually technology independent. The ToIP stack can be mapped onto Tim's model, but it is broader than the ToIP stack.
• Drummond Reed suggested that Tim should turn this into a white paper that can be published in conjunction with the ToIP Technology Architecture Specification. He volunteered to help with that because it will provide a wonderful conceptual "bridge" to understanding the tech arch spec.