Versions Compared

Old Version 3

changes.mady.by.user Neil Thomson

Saved on

compared with

New Version 4

changes.mady.by.user Wenjing Chu

Saved on

Key

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

Meeting Date & Time

  •  
    • NA/EU 07:00-8:00 PT / 14:00-15:00 UTC 
    • APAC 1:00-2:00PM PT / 20:00-21:00 UTC

Zoom Meeting Links / Recordings

Attendees

Main Goal of this Meeting

TODO

Agenda Items and Notes (including all relevant links)

TimeAgenda ItemLeadNotes
5 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 minAnnouncementsAllUpdates of general interest to TATF members.
5 minReview of previous action itemsChairs
30 minsToIP Technology Architecture Specification Walkthrough

Wenjing Chu

Wenjing Chu walked through the ToIP Technology Specification - Working Draft 01, mostly about structural changes. The discussion was primarily about:

  • Who is the audience, and what information do they expect to see in an Architecture Spec (and other related and sub-documents), 
  • That this is a "top document" which should be relatively short, delegating more specific or detailed information to other documents (providing a list of those documents)
  • What are the key goals of the architecture and this document

Key Takeaways:

  • Tim Bouma As a Builder (of an application for this architecture) I would expect to find an overview document with a list of detailed specs that have to be implemented. For example:  component X needs a, b, c (requirements). 
  • Wenjing Chu Tim Bouma The rationale for the architecture belongs in a white paper. Detailed explanations can be in white papers or other specific documents.
  • Tim Bouma Layers need to specify both specific components and types of components that belong in a given layer (or classified as a "supporting system/service")
    • Daniel BachenheimerWhere do (data) schemas, accumulators and other components of that type fit? <TBD, need a list of all the components (and types of components) and the appropriate layer, etc.>
  • Wenjing Chu Tim BoumaIt's essential to indicate where the interfaces be technology agnostic, particularly from layers 4, 3 to Layer 2, 1. 
    • Tim Bouma What made governments nervous was the (perceived) dependency on specific vendors/product (Indy-Aries). If we build on layers 2 (3, 4) do we have a dependency on lock-in to a vendor/solution at Layer 2/1
  • Wenjing Chu Layer 1 effectively becomes a Wallet services layer from the perspective of being a container (and interfaces) to PKI material, VCs, etc. and as a secure store
  • Wenjing Chu , The architecture description language, is about patterns:
    • Neil Thomson
      • Layering & partitioning
      • Behaviour & interfaces
      • Components (expressed as roles and the purpose of those roles)
      • Requirements
      • Dependencies (between components, layers
    • Define the scope of control and governance within and between layers, components and workflows
  • Wenjing ChuA key goal that Interfaces from 3, 4 to Layer 2 be solution/tech independent
    • A key will be getting feedback from multiple implementers and other "customers" of the architecture, particularly for knowledge gaps in the document(s)
10 minsIntermediaries discussion

Wenjing Chu Neil Thomson

Quick discussion on Intermediary Services vs. Computational components as Intermediaries. It was agreed that Intermediary (Systems) are routers and the like which are forwarders between endpoints. Computational components are services (or micro-services) in the "Operator" sense as a service which any two actors (Holders, Verifiers) may choose to dynamically pull into a processing "pipe" to do some specific one-time task or by applications in building static or dynamic processing pipes/chains of Operators for which the Verifier is the "public face" of the application

Action for next meeting: Discussion of whether there is a requirement for Operator "trust". Proposal - there is a need for Operators to be under the control of a Registrar, which acts as Service Verifiable Credentials Issuer to be presented as to:

  • Certified capabilities/purposes of the Operator (KYC applied to Operators)
  • Usage constraints, including constraints on Holders and Verifiers (and other Operators) - e.g., what VCs/proofs they must present
  • ... TBD

 Registrars may also delegate to an Operator manager, which could provide an Operator Library, plus controls version update notifications, revocation, etc.  

10 minsSpecial topic #3

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

Actions: 

  • Tech Arch Spec document
    • Wenjing Chuto use the IIW slides as the primary source for diagrams to be inserted into the draft
    • General discussion on the next level (of detail) diagrams for each layer (and components)
  • Operator Trust 
    • As discussed unde

Screenshots/Diagrams (numbered for reference in notes above)

#1


Decisions

  • Sample Decision Item

Action Items

  •  Sample Action Item