Time

Agenda Item

Lead

Notes

3 min

• Start recording

• Welcome & antitrust notice

• Introduction of new members

• Agenda review

Chairs

• 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:

5 min

Announcements

All

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. 

2 min

Review of previous action items

Chairs

ToIP Technology Architecture Specification Review Topics

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

• TAS GitHub Markdown version

• TAS GitHub issues list

• TAS Source Diagrams (Google Slides) <== SOURCE DIAGRAMS used in the TAS

• ToIP Protocol Stack Diagrams (Google Slides) <== All of all our past diagrams (some of which have been copied to TAS Source Diagrams)

• TAS WORKING DRAFT 03 Google doc version <== REFERENCE ONLY — NO LONGER ACTIVE

• TAS OLD WORKING DRAFT 02 Google Doc version <== REFERENCE ONLY — NO LONGER ACTIVE

• Evolution of the ToIP Stack <== NEW proposed companion document

• TATF Google Drive Folder <== WHERE ALL OF THE ABOVE may be found

10 mins

New goal for First Public Review Draft?

@Drummond Reed 

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 (Deactivated) 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 (Deactivated) , @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).

20 mins

Review & prioritize TAS GitHub issues

@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, 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 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.

5 mins

• Review decisions/action items

• Planning for next meeting 

Chairs