Updates of general interest to TATF members.

• Wenjing Chu did a recording of the talk he gave in Dublin about the ToIP Technology Architecture Specification. 

Proposal to complete a First Public Review Draft — including putting a GitHub-based public comment process in place — for Fall Internet Identity Workshop, Nov 15-17.

• This led to a discussion of the process we need to put into place for a public review using GitHub.
• We agreed there is a JDF contributors agreement that can apply to comments submitted via GitHub but we need to identify exactly what it is and how it is applied.
• Kevin Dean said that this is the process they followed for public comment at GS1.
• We agreed that we need to make sure all comments or proposed changes goes through the necessary contribution agreement before being accepted.
• Tim Bouma made the point that only maintainers can actually accept changes to the core spec, so they can make sure the process is followed.
• Judith Fleenor pointed out that feedback outside of GitHub must still go be subject to the CLA.
• DECISION: The Technology Architecture Task Force will use its best efforts to publish a First Public Review Draft of the ToIP Technology Architecture Specification by 15 November 2022 in order to begin public review at the Fall Internet Identity Workshop. 
• ACTION: A "Public Review Process Group" consisting of Drummond Reed Darrell O'Donnell , Christine Martin , Judith Fleenor , Elisa Trevino, and Jory Burson will sort out and propose the public review process we will use in GitHub plus any other acceptable "channels" (e.g., Google docs, email).

Wenjing Chu 

We reviewed over our TAS GitHub issues list to determine priority and assign (or resolve) issues.

• Our current status is 28 open issues and 4 closed.
• We reviewed the four closed issues (#1 thru #4) and agreed about their disposition.

For efficient resolution of issues — and to strongly encourage asynchronous progress — we agreed to the following process proposals:

1. We will form an Editors team who will take on the job of reviewing GitHub issues and proposing when an issue is ready for closure.
   1. The following volunteered to be Editors: Wenjing Chu, Drummond Reed, Andor Kesselman, and Christine Martin. Darrell O'Donnell was not on the call but was nominated to be one of the Editors.
2. The Editors will agree on a set of labels to prioritize issues for resolution and then apply those tags to existing and new issues.
3. If an issue appears to require in-depth discussion and analysis, the Editors will propose (or solicit) a subgroup to tackle that issue and come back to the TATF with a proposed resolution.
   1. The issue resolution sub-group to self-organize on communication channel (e.g., slack multi-person direct message group) and use one or more Google docs in the ToIP WG folder space to capture:
      1. Approach to solve the problem (ISO "Technical Report" as example - issue mandate, technical policy, high-level requirements and expected outcomes)
      2. Proposal (text and diagrams) (ISO "Technical Spec") which is a new or modified part of a TATF technical spec document  
4. When the Editors believe there is consensus about the proposed resolution of an issue, one of the Editors will apply the label "Proposed Close" to that issue.
5. Once that happens, a TATF member MUST object within 5 calendar days to reopen discussion of the issue.
6. If there is no objection within 5 calendar days, the proposed resolution will be applied to the spec by one of the Editors and the issue will be closed with no further discussion.

ACTION: Drummond Reed to post to Slack and send to the TSWG mailing list a summary of these proposals for processing and resolution of GitHub issues and a call for any other volunteers for the Editors team.

ACTION: The Editors team will: 1) Document to the TSWG branch of the ToIP wiki the process for raising, discussing, and closing issues; 2) Link to that page from the landing page for the ToIP Technology Architecture Specification.

APAC Meeting discussions (continuation on issue resolution, etc.)

• Some edits and additions to item (3), above
• It was suggested that 3 issues be identified as needing sub-group resolution as a proof-of-concept for this approach.
• The assumed next steps for issue resolution will be:
  • Gaps and issues in the TATF Arch Spec with the target of IIW for public review (Thurs Nov 10 deadline)
  • New issues
    • For the TATF spec
    • Determine components and sub-systems that need Tech Specs and generate topics/issues for each of those specs.  Question/observation - how to collect those issues before these more detailed specs have actually been started?
      A couple of examples:
      • Offline trust - and the on/offline transition - Daniel Bachenheimer suggested reviewing has this is being addressed in mDL (mobile Drivers License) as they have done in depth offline work. (Andor Kesselman raised as issued #36)
      • Revocation - both the technical and human aspect. E.g., you are in mid-flight (between countries) and something in the passport trust chain causes your passport VC to be revoked. Technical and human impact use cases.