• Start recording
• Welcome & antitrust notice
• Introduction of new members
• Agenda review

• Antitrust Policy Notice: Attendees are reminded to adhere to the meeting agenda and not participate in activities prohibited under antitrust and competition laws. Only members of ToIP who have signed the necessary agreements are permitted to participate in this activity beyond an observer role.
• New Members:

Updates of general interest to TATF members.

• MS meetings
  • TAS caused difficulty - too much info up front. The Credential in an OIDC context is their world. QUESTION for ToIP and TSWG is how do we help the OIDC realm folk step out from that model.
• The OIDC realm is the hardest consumer of the ToIP model. They have a model that mostly works in a very bounded (IAM, OIDC, SAML, etc.) realm. This will create resistance - and opportunity. 

Discussion of progress on the working draft of the ToIP Technology Architecture Specification. Links to all the relevant documents and diagrams:

• READONLY Google Doc - content has been moved to GITHUB
• Evolution of the ToIP Stack <== NEW proposed companion document
• ToIP Protocol Stack Diagrams (Google Slides) <== All of all our past diagrams (some of which have been copied to TAS Source Diagrams)
• TAS Source Diagrams (Google Slides) <== SOURCE DIAGRAMS used in the TAS
• TATF Google Drive Folder <== WHERE ALL OF THE ABOVE may be found
• TAS GitHub Markdown version
• TAS GitHub issues list

APAC mtg discussion on Spec, and next steps - see the "Discussion, Next Steps" at the end of the meeting minutes, below.

• Discuss how we will capture information.
  • GitHub Issues - preferred method
  • EMAIL - IPR Concerns (content only allows members only) - we have EXISTING METHODS 

• Public Review - presentation will drive reviewers to ToIP membership due to IPR concerns

PARKED FOR NOW

• Non-verifiable credentials "We still don't have a use case for dealing with non-verifiable credentials (or an example of useful non-verifiable credentials)." Neil
  • Neil has some examples working in his head at the moment. 

Given that the content of the top-level Tech Arch Spec is approaching its "first complete draft" state, some discussion was held on the next steps, which may be pursued in parallel:

• Tech Arch Spec - continued comments and refining in GitHub, with a small number of authors, with comments directed on completing the first full draft to be presented on Sept 14 in Dublin, plus identifying larger issues to be addressed in the second draft.
  • Whilst having the "issue" in GitHub is useful, ideally, the details would include the section wording, diagrams etc., so that the issue can be read independently and not have to go back to the spec. Is this going to be copied through into the placeholder issues?
• Use Cases - review the Tech Arch Spec use cases and identify gaps and use case topics which require that one or more specific use cases be created with an eye to addressing: 
  • 2 or 3 "80/20" use cases
  • 7 + use cases to stress the architecture (e.g., notification of VC revocation, secure messaging, registries, etc.)

It is suggested that each Use Case be captured (in detail) in separate documents, which may contain variations or related sub-use cases. Discussion on the impact on the Tech Arch Spec will first be discussed in the Use Case document and any conclusions on the impact on the Arch Spec will be rolled up after closure on the Use Case definition.

• Component and non-Component Detailed Specifications (Services, Features, Capabilities - e.g. commercial model and value exchange) - essentially the next level of details on the Tech Architecture will be to detail the components defined in the Tech Arch Spec and specific detailed topics that are identified from the Component and overall Arch Spec that need attention in some detail
• Additional roles in managing the Tech Arch "Document Set" to include:
  • A Tech Arch Spec issue, comment screener and manager (mostly about GitHub) - details TBD, but to at least include asking for more details on unclear issues and comments, consolidating issues and comments and generally managing the resolution of issues and comments with the authors. It is expected that resolving the issues will be discussed with the entire Tech Arch contributors group on Thursday NA/EU and APAC meetings
  • A document set project manager, with the role of coordinating cross-document feedback and coordinating reviews and release decision points (including managing the issues to be resolved to pass a given release date.  
• Integrity and Authenticity Discussion - It was agreed that these are part of the Design Principles for the ToIP Stack, plus either the ToIP or Tech Arch Terms Wiki's. These terms should either be removed from the Tech Arch Spec or references provided to the Design Principles or Terms Wiki(s).

• Review decisions/action items
• Planning for next meeting