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)

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: Wenjing to resolve whether Intermediary as a vocabulary term conflicts with the recent EU Data Act on Intermediaries (which may be closer to the Operator definition)

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.  

After discussion Wenjing Chu, Neil Thomson, this is a Layer 4 (applications) concern, which is out of scope for the current ToIP Stack discussions and is tabled until Layer 4 is explored in more depth

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)