IMPORTANT: Don’t read this version of this article about the “DID” ARM. This is an old article but it remains here 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
Draft Versions for Discussion Purposes Only
QUESTION: Are these diagrams precise, accurate, and complete? In particular, are the components and relationships in the Technology/Infrastructure Architecture layer precise, accurate, and complete? Please add a comment to the end of this article or email me at email@example.com.
The Decentralized Identifiers (DIDs) architecture reference model diagrams that follow were created to support the following discussion…
From: Michael Herman (Parallelspace)
Sent: December 20, 2018 10:01 AM
Subject: Review of the current draft DID specification
I’ve recently started a detailed review of the current draft DID specification document and to be direct, I have found even the first few sections to be quite imprecise and confuding.
I’m reviewing the draft spec from the perspectives of an Enterprise Architect and experienced blockchain developer. Most of the issues relate to a lack of precision in the use of key concepts and terminology …as well as unnecessary IMHO overloading of these key concepts/terms …things that should be prohibitive in a spec document.
That’s a bit of a brutal introduction… But those who have met me (in Basel for example) understand my proper passion around these topics.
I also understand there is a rush to advance this document from a Community draft specification to something with a more formal status. I honestly don’t think the document is ready …but I don’t know what the “bar” is.
What’s the best way to proceed? I’m not sure… …keep creating new issues? …write a lengthy position paper? … create a new PR?
Architecture Reference Model Diagrams
These diagrams are part of a larger effort to create an architecture reference model for the entire Hyperledger Indy software platform and Sovrin governance model. The achieve this goal, a deep and precise of the draft Decentralized Identifiers (DIDs) specification is required. I appreciate all of your help and input. …Michael
p.s. These diagrams will be updated regularly – sometimes a couple times per day.
Click on any of these diagrams to enlarge them.
Version 0.14 – January 1, 2019
Relative to version 0.11, version 0.14 recognizes Software Agents as Actors. Scroll down to Version 0.11 – December 30, 2018 for the most complete set of architectural principles.
Version 0.11 – December 30, 2018
The updates in version 0.11 of the Decentralized Identifiers (DIDs) ARM (architecture reference model) are limited to the Business Architecture Layer; more specifically, clarifying to roles and relationships between:
- Actors (Persons and Organizations), and
- Things (Pets, Cars, Houses, Business Documents, Products, Assemblies and Parts).
The role of Actor in the model is a key learning that came out of the Basel workshop.
I’ve taken the idea a step further to find a proper “place and set of relationships” for the Sovrin concept of “Things”. I believe I’ve (successfully?) done that but am looking for feedback/consensus about these ideas. They are presented visually in the diagram below.
The new Business Architecture basic principles are:
- An Actor is either a Person or an Organization.
- Each Person or Organization has one or more SS Digital Identities associated with it.
- Actors (Persons and Organizations) participate in Processes.
- A Process acts on/accesses Things (e.g. Pet, Car, House, Business Document, Product, Assembly, Part) to perform work.
- Business Documents, Products, Assemblies and Parts are different from the traditional or generic Sovrin concept of a Thing (e.g. Pet, Car, House).
- Each Thing has one or more SS Digital Identities associated with it.
To bridge from previous versions of the ARM (see below), the following Application Architecture basic principles also apply:
- A DID Document is a JSON-LD serialization of a DID Entity.
- A DID Entity is the in-memory, application-specific object that represents a de-serialized DID Document.
- A DID Entity is what application developers work with (program against) at the Application Architecture level of an app.
- DID Entities have a set of attributes such as the following:
- id (DID)
- service (endpoints)
- “id (DID)” exists as an attribute of a DID Entity (and by implication, as an attribute of DID Document, 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).
- DIDs are used to index, find, and retrieve DID Documents from the Technology/Infrastructure Architecture layer.
- DID Documents represent the primary object type that is exchanged between the Application Architecture layer and the Technology/Infrastructure layer.
Version 0.10 – December 21, 2018Figure 0.10 Decentralized Identifiers (DIDs) – Architecture Reference Model (ARM) v0.10 – December 21, 2018
Version 0.9 – December 21, 2018
Michael Herman (Toronto/Calgary/Seattle)