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.