Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
Draft document for discussion purposes.
Update cycle: As required – sometimes several times in a single day.
- Hyperledger Indy/Sovrin Comprehensive Architecture Reference Model (INDY ARM)
- End-to-end Path from id (DID) to a Real-Life Something
DID Data Model
Figure 1. Simplest DID Data Model
- [Informative] A DID Entity is a data structure comprised of a collection of key-value pairs with keys such as: id (DID), service (endpoints), authentication, publicKey, @context, etc.
- A DID Document is a JSON-LD serialization of a DID Entity.
- A DID Document has a set of attributes such as the following:
- id (DID)
- service (endpoints)
- The id (DID) attribute is the unique identifier or key for the DID Document.
- 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 Layer. 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).
- When DID Documents, in turn, are serialized to the Indy Ledger by Indy Ledger Nodes, they are stored as a series of Indy Ledger Transactions.
- Edge Agents and Cloud Agents call an Indy Ledger Node to persist a DID Document to the Indy Ledger. DID Documents, specifically, are written to the Indy Ledger by the Indy Ledger Nodes using Indy NYM and Indy ATTRIB transactions.