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) Allan Thomson presenting on use cases, 2) Moving the spec from Google docs to GitHub.

We reviewed a proposal from Allan call Interoperability Test Cases that will be posted to the TSWG Google Drive folder. 

• It starts with a high-level 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: Allan Thomson to: 1) add a few additional high-level motivational use cases to his document, 2) add his document to the TSWG Google Drive folder.

It has been suggested we start using GitHub to either 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.