2A/ The T.oIP Reference Architecture for Universal Interoperability / Wenjing Chu
From IIW
Session 1A
The T.OIP Reference Architecture for universal interoperability
Session Convener: Wenjing Chu
Notes-taker(s): Ajay Jadhav
Tags / links to resources / technology discussed, related to this session:
https://github.com/trustoverip/TechArch
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Wenjing presented:
- Stack vs. Reference Architecture
- What is the reference architecture? It is a generalization of various viable solutions
- It helps crystalize the most important architecture considerations while leave other details for substantiation
- A Stack is to view the decomposition vertically in functionality, where each higher layer incrementally adds functionality above the layer(s) below it.
- It is suitable within a domain of locus of control where dependencies are clearly ordered.
- But it is not suitable to capture relations between loci of control.
- The Reference Architecture is a prerequisite to to understand a Stack.
- An analogy for a Reference Architecture - a Building structure - layers vs. protocols between domains / locus of control
- For ex: Internet Architecture
- OSI Stack - HTTP, TCP, IP, etc.
- In reality -
- Intra-domain routing e.g. OSPF
- Ethernet devices, ARP, IP, ICMP, IGMP - inter-domain: e.g. BGP
- Another Example:
- OIDC in the reference architecture view.
- OpenID Connect Protocol - steps in abstract vs. a sequence diagram
- Most important considerations for TOIP - Design principles for TOIP
- Universal Connectivity
- A.k.a Reachability, Interoperability, Hourglass, End-to-end
- Decentralization
- Authenticity
- Verifiability
- Confidentiality, Privacy
Reference Architecture: Slide # 13-14-15-16
- Subsystems are delineated by locus of control (domain)
- They interact through a set of protocols, not just one.
- Each type of subsystems has a shared stack*, but the stack is not identical across different types of subsystems** (e.g. Blockchain)
- Intermediary systems - message forwarding & other functions..
- E.g. a peer-to-peer Trust Spanning Protocol between Endpoint Systems
- Examples of supporting systems:
- VDRs, Trust Registry, Witness, Watcher, Accounting/Auditing, Reputation, Discovery, etc.
- An Endpoint System
- Locus of control composed of layers
- Layer to layer communication, interfaces & protocols
Slide #17
- Reference Architecture example two endpoint systems - A & B
- Example of how systems communicate
What Layer 2 needs - (Trust Spanning Layer)
- AID / DID + And end-to-end verifiable messaging protocol
- Properties:
- A. authentication
- B.
- C.
An endpoint system example with Indy-Aries:
- Communicating with a Supporting system
Another example with KERI:
- Witness pool with Key Event Logs:
- KERI also uses other supporting systems (e.g. Watcher for confirmation) in addition to the Witness pool, as long as are required for functioning of AID or E2E
A Generalized Reference Architecture
- One system using Indy-Aries and another using KERI, will be able to talk to each other using the implementation reference architecture.
Intermediary Systems:
- E.g. DIDComm V2
- Works between the two end-systems
Another example - WEB5:
- DWN
- Can use the same Trust Spanning Layer for Universal Interoperability
An Endpoint System’s Protocol Stack: Slide # 24
- With this reference architecture, the details of each layer, interface and protocols can be specified one by one which, taken as a whole, completes the technical specification.