Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

TimeAgenda ItemLeadNotes
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 minAnnouncementsAll

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. 


2 minReview of previous action itemsChairs

ToIP Technology Architecture Specification Review Topics

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

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

15 minsIssue Capture & ResolutionChairs (Darrell)
  • Discuss how we will capture information.
    • GitHub Issues - preferred method
    • EMAIL - IPR Concerns (content only allows members only) - we have EXISTING METHODS 
  • GitHub - versioned PDFs?

"About not being able to accept contribution from non members - what's the end outcome desired from "public review" then?

  • Sankarshan

Great Question - if we are at PUBLIC REVIEW (we are NOT). 

DUBLIN - this is an announcement of the need for a broader ToIP Community to review, add. Additional:

  • drive interest 
  • OUTCOME:
    • Drive member and non-member input OR
    • member and "just-joined members" in order to comment/submit issue.
  • NON Member Agreement - protects on IPR issue.
  • EasyCLA - https://github.com/communitybridge/easycla

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
15 minsNext Steps (APAC Discussion)See the APAC attendee list

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., unexpected revocations of VCsnotification 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.  
15 minsTopic #3

5 mins
  • Review decisions/action items
  • Planning for next meeting 
Chairs

...