#iDIDit: [OLD] DID Comprehensive Architecture Reference Model (ARM) v0.8

IMPORTANT: Don’t read this version of this article about the “DID” ARM.  It’s incorrectly named – this article remains as a tombstone for the many places where this URL has been posted.  Please read: Hyperledger Indy/Sovrin Comprehensive Architecture Reference Model (ARM). (click here).

Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
January 2019

Draft document for discussion purposes.
Update cycle: As required – sometimes several times in a single day.

Overview

The purpose of the DID Comprehensive Architecture Reference Model (DID ARM) is provide a complete, reliable, precise, visual reference for the concepts presented in the draft Decentralized Identifiers (DIDs) specification (link). The primary audience for this article are: software people (software architects and developers), enterprise architects, and anyone new to the Hyperledger Indy project or the field of self-sovereign identity (SSI) looking to find a fast on-ramp.

The goals of the DID ARM are:

1. Create a reliable, precise, comprehensive, visual model depicting Decentralized Identifiers (DIDs), DID Entities, DID Documents, and the companion Hyperledger Indy ecosystem of software projects, software components, and data elements.
2. Enable software people to become more knowledge about and productive with the Hyperledger Indy software platform (and Sovrin governance framework) as quickly and as easily as possible.
3. Provide a common language of discourse for describing the current state architecture as well as potential future state architectures for the DID ecosystem and community (with particular focus emphasis on the needs and requirements of software people).

The guiding principles for the DID ARM are:

• Provide reliable documentation: timely, accurate, visual, and complete
• Save as much of a software person’s time as possible
• Leverage open source modeling specifications and tools like ArchiMate and Archi, respectively
• Leverage enterprise architecture concepts to explain Decentralized Identifiers and Entities in a way doesn’t detract from the adoption of the DID ARM

The drivers for the DID ARM are:

• The initial driver for the DID ARM is the create a reference model to help correct a series of issues found in the draft DID specification and documented in the project’s GitHub issues list (Fall 2018).

NOTE: Some of the elements depicted in the DID ARM have been influenced by the Verified Credentials project – particularly, the business roles and processes in the Business architecture layer (1) and the Credential Registry Agent Node (39) in the Technology architecture layer (30).

Companion Articles and Other Resources

• Vision: Trusted Digital Web
• In Practice: End-to-end Path from id (DID) to a Real-Life Something
• Modeling Specification: The Open Group ArchiMate 3.0 Specification
• Modeling Tool: Archi, the open source ArchiMate modeling platform

DID ARM Version 0.8

Horizontally, the DID ARM is partitioned into 4 perspectives:

• Projects and Distributions (A)
• Software Architecture (B)
• Data Model (C)
• Principles (D)

Vertically, the DID ARM is divided into 3 architecture domains that span the 4 perspectives:

• Business architecture (1) and (8)
• Applications architecture (23) and (12)
• Technology architecture (30) and (15)

The DID ARM is illustrated in the following “all in” view/projection of the DID reference model. The ARM is an actual queryable model – it is not a drawing (e.g. a Visio diagram).

The Narration section that follows the graphic includes a description of each of the numbered bullets.

Click on the graphic to enlarge it in a separate browser tab.  Suggestion: Drag the new browser tab onto a second monitor if you have one.

Figure 0.8: DID Comprehensive Architecture Reference Model (ARM) v0.8

NOTE: Physically, the DID ARM is approximately 60 cm x 50 cm in size – but it is quite readable when printed on a regular sized paper – with glasses.

Narration

1. Business Layer of the DID ARM. “The Business Layer depicts business services offered to customers, which are realized in the organization by business processes performed by business actors.” [ARCHIMATE]
   • The following Actor Roles are depicted in this version of the ARM: Issuer, Holder (x 2), Inspector, and Verifier. These roles are not formally defined in the draft DID specification; for the time being, they have been borrowed from the documentation related to the Verified Credentials project.
2. An Issuer causes a self-sovereign identity for a Something for be Issued; e.g. a Purchase Order (3). In this example, the SSI is for a Thing (10); in particular, a completed and approved Purchase Order (3). The Purchase Order is issued to a Holder. Both the Issuer and the Holder work for a fictitious company called Acme Corporation.
3. SSI for a Something (a Purchase Order) issued by the Issuer @ Acme (2).
4. The Holder @ Acme accepts the SSI for the Thing (a Purchase Order) from the Issuer (2). In turn, the Holder @ Acme presents the SSI for the Purchase Order to a Holder at Baker Limited. The Holder @ Baker receives the SSI for the Purchase Order from the Holder @ Acme (4).
5.  An Inspector @ Baker may request that the Holder @ Baker present the SSI for the Purchase Order to him/her/it. The Inspector @ Baker receives the SSI from the Holder @ Baker.
6. The Inspector @ Baker (or any Holder) can ask for the SSI for the Purchase Order to be verified by a Verifier.
7. There is a set of Business Services (e.g, Issue, Store, Request, Verify, Register, etc.) that support the above processes.  These Business Services are supported by services exposed by the Applications Architecture Layer (23).
8. Business Layer – Data Model captures the key business-level model elements such as Actor (9), Things (10), and Business Processes (37).
9. An Actor is “a business entity that is capable of performing behavior.” [ARCHIMATE]
   • Examples of Actors include Persons, Organizations, and Software Agents.
10. A Thing is inanimate entity. Things and Actors are mutually exclusive (P3). A Thing has an Owner (P2). An Owner is an Actor (P2).
    • Examples of Things include Pets, Cars, Houses, Business Documents, Products, Assemblies, and Parts.
    • The software component of a Software Agent is a Thing. If you’re talking about Software Agent as a business entity capable of performing behavior, then the Software Agent, in this context, is an Actor.
    • A slice of a particular kind of Toast is not a Thing because it is fungible. A slice of Toast can be a Thing in the future when each slice of bread has its own bar code or serial number. A photo of a slice of Toast is a Thing because it is non-fungible (most photographs are non-fungible and hence, are Things).
    • A living cell (skin cell, blood cell, etc.) would not be considered an Actor (or a Thing). It is not a business entity nor a Non-Fungible Entity (within a single body of DNA) ..at least, not for the foreseeable future.
11. Business Processes. Actors (Persons, Organizations, and Software Agents) participate in Processes. A Process acts on/accesses Things (e.g. a Pet, Car, House, Business Document, Product, Assembly, Part) to perform work.
12. Application Layer – Data Model captures the key application-level model elements such as id (DID) (12) and DID Entity (13).
13. id (DID) exists as an attribute of a DID Entity (13) (and by implication, as an attribute of DID Document (15), the JSON-LD serialization of the corresponding DID Entity).
    • The id (DID) attribute is given the nickname “DID” (aka Decentralized Identifier) for convenience; but more importantly, to clarify what a DID specifically refers to (as well as to clarify what the term DID specifically does not refer to). “DID” should only be used to refer to the id (DID) attribute of a DID Entity (or DID Document).
    • id (DID) are used to index, find, and retrieve DID Documents from the Technology Architecture layer (28/14).
14. A DID Entity is the in-memory, application-specific object that represents a de-serialized DID Document (15). (P4)
    • DID Entities have a set of attributes such as the following:
      • id (DID)
      • service (endpoints)
      • authentication
      • publicKey
      • @context
      • etc.
15. Technology Layer – Data Model captures the key technology-level model elements such as a DID Document (15).
16. A DID Document is a JSON-LD serialization of a DID Entity.
    • The id (DID) attribute is the unique identifier or key for the DID Document.
    • id (DID), aka a DID, is used to index, find, and retrieve a DID Document (also see (12)).
17. When DID Documents (16), in turn, are serialized to the Indy Ledger (36) by the Indy Ledger Nodes (37) and (17), they are stored as a series of Indy Ledger transactions. DID Documents, specifically, are written to the Indy Ledger by the Node Agent Nodes (36) and (37) using Indy NYM and Indy ATTRIB transactions.
18. Technology Layer – Projects and Distributions highlights the Hyperledger (and potentially other) open source projects that design, build, and supply software components to both the Applications and Technology Architecture Layer.
19. The Hyperledger Indy-SDK project includes two key software components used to implement an Indy Wallet (25) and (32):
    • libIndy (lower-level)
    • libVCX (higher-level)
20. The Hyperledger Indy-Agent project is used to implement the Indy Agent functionality in the:
    • Edge Agent App (24)
    • Edge Agent Web App (28)
    • Edge Agent Lightweight App (29)
    • Cloud Agent Node (31)
    • Ledger Agent Node (35), and
    • Credential Registry Agent Mode (39)
21. The Hyperledger URSA project is a utility that provides implementations of the cryptographic functionality required across all of the Hyperledger projects.
22. The Hyperledger Indy-Node project is used to implement the Indy Node functionality in the: Ledger Agent Node (35).
23. Applications Layer of the DID ARM. “The Application Layer depicts application services that support the business, and the applications that realize them.” [ARCHIMATE]
24. The Edge Agent App 1 is an end-user application for interacting with the self-sovereign identities an Actor owns: personal, organizational, as an Owner of Thing, or as a Guardian of another Actor (9) and (10). This is typically a mobile or a desktop app.
25. The Edge Wallet is a mobile or desktop application component that supports the Edge Agent App’s requirements (24) for managing actual self-sovereign identities it owns.
26. Edge Agent App 2 is an example of another Edge Agent App in the ecosystem. Communication between Edge Agent Apps takes place using the Indy Agent-to-Agent Protocol (A2A Protocol) (27).
27. The Indy Agent-to-Agent Protocol (A2A Protocol) is the protocol used for communication between Edge Agent Apps (24) and (26), Cloud Agent Nodes (31 and 33), and Ledger Agent Nodes (35) and (37).
28. The Edge Agent Web App is an Edge Agent implemented as a server-hosted web application.
29. The Edge Agent Lightweight App (EAPA) is a mobile or desktop application that doesn’t use a local Edge Wallet. Instead, the EAPA relies on the services of a Cloud Agent and Cloud Wallet.
30. Technology Layer of the DID ARM. “The Technology Layer depicts technology services such as processing, storage, and communication services needed to run the applications, and the computer and communication hardware and system software that realize those services.” [ARCHIMATE]
31. The Could Agent App 1 is a cloud or server-based application for interacting with the self-sovereign identities an Actor owns: personal, organizational, as an Owner of Thing, or as a Guardian of another Actor (9) and (10). The Cloud Agent App is an alternative to using an Edge Agent App (24) and Edge Agent Wallet (25).
32. The Cloud Wallet is a cloud or server-based technology component that supports the Cloud Agent App’s requirements (31) for managing actual self-sovereign identities it owns.
33. Cloud Agent App 2 is an example of another Cloud Agent App in the ecosystem. Communication between Cloud Agent Apps takes place using the Indy Agent-to-Agent Protocol (A2A Protocol) (34).
34. The Indy Agent-to-Agent Protocol (A2A Protocol) is the protocol used for communication between Edge Agent Apps (24) and (26), Cloud Agent Nodes (31 and 33), and Ledger Agent Nodes (35) and (37).
35. Ledge Agent Nodes support the requirements of Edge Agent (24) and Cloud Agent (31) applications for persisting, managing, and interacting with DID Documents (16) persisted to the Indy Ledger (36) and (17).
36. The Indy Ledger is the distributed ledger technology that supports the persistence, management of DID Documents (16) persisted to the Indy Ledger as Indy NYM and ATTRIB transactions (17).
37. Ledge Agent Node 2 is an example of another Ledge Agent Node in the ecosystem. Communication between Ledge Agent Nodes takes place using the Indy Agent-to-Agent Protocol (A2A Protocol) (38).
38. The Indy Agent-to-Agent Protocol (A2A Protocol) is the protocol used for communication between Edge Agent Apps (24) and (26), Cloud Agent Nodes (31 and 33), and Ledger Agent Nodes (35) and (37).
39. Credential Registry Agent Node is a repository for persisting, managing, and interacting with Verified Credentials. It’s implementation is based on technologies similar to those used to implement Cloud Edge Agents.
40. DID Resolver Node is a key component that is used by Edge Agent (24) and Cloud Agent (31) applications to resolve a id (DID) (13) into a specific DID Document (16) (assuming the DID Document has been persisted to the Indy Ledger (36) and (17)).

Best regards,

Michael Herman (Toronto/Calgary/Seattle)