Draft document for discussion purposes.
DID End-to-end Path Version 0.3
The following graphic illustrates the path (flow) of a client app trying to: a) communicate/interact with, and/or b) access the metadata about a real-life something by using a Decentralized Identifier (id (DID)).
That is, in (almost) 10 steps or less, how to you get from an id (DID) attribute on the left to a Real-Life Something on the right?
2019-01-08 NOTE: The ultimate goal is to synthesize a simple(r) data model – not a more complex one. However, the interim analysis phase (tearing things apart) is expectedly going to result in a data model that is visually more complex. From this analysis model, we can hopefully synthesize a data model that is simple(r).
NOTE: Click on the graphic to enlarge it.
- 0. A DID Document contains an id (DID) attribute which is the unique identifier or key for a DID Document.
- A Real-Life Something can be associated with more than one DID Document (and by implication, more than one id (DID)).
- A DID Document (and its id (DID)) can only refer to one Real-Life Something.
- Client App (or Service) is interested in either:
- Communicating or interacting with a Real-Life Something.
- Gaining knowledge about a Real-Life Something. (Let’s refer this knowledge as Metadata about the Real-Life Something.)
- NOTE: A Real-Life Something can be either a Real-Life Actor or a Real-Life Thing.
- Client App calls DID Resolver to retrieve the DID Document that corresponds to a particular id (DID).
- DID Resolver uses the id (DID) as a key (unique identifier) to retrieve the corresponding DID Document from a DID Document Repository (14).
- DID Resolver, in turn, returns the DID Document to the Client App.
- The DID Document contains a service (endpoint) attribute that points to the Software Service Endpoint for the entity where:
- Client App can communicate or interact with a particular Virtual (Real-Life) Something (primary use case).
- Client App can retrieve additional information about a particular Real-Life Something (aka Metadata about the Virtual (Real-Life) Something) (secondary use case and, potentially, a sub-case of the primary use case).
- Client App calls Software Service Endpoint to either: a) communicate/interact with, or (b) retrieve metadata about a Virtual (Real-Life) Something.
- [Primary Use Case] Software Service Endpoint enables Client App to communicate or interact with a particular Virtual (Real-Life) Something.
- Virtual Actor is a Virtual (Real-Life) Something that is associated with a Real-Life Actor (9).
- Real-Life Actor is a Real-Life Something that is associated with a Virtual (Real-Life) Actor (8).
- Virtual Thing is a Virtual (Real-Life) Something that is associated with a Real-Life Thing (11). A Virtual Thing has an Owner. The Owner of a Virtual Thing is a Virtual Actor.
- Real-Life Thing is a Real-Life Something that is associated with a Virtual (Real-Life) Thing (10). A Real-Life Thing has an Owner. The Owner of a Real-Life Thing is a Real-Life Actor.
- [Secondary Use Case] Client App retrieves Metadata Document about Virtual (Real-Life) Something from the Metadata Document Repository (15) by calling Software Service Endpoint. As in the primary use case, the Virtual (Real-Life) Something can be a Virtual Actor or a Virtual Thing.
- Software Service Endpoint returns the Metadata Document for the particular Virtual (Real-Life) Something to the Client App; that is, the knowledge about the Virtual (Real-Life) Something that the Client App was originally interested in Step 1.
- DID Document Repository is a repository of DID Documents indexed by each document’s id (DID).
- Metadata Document Repository is a repository of Metadata Documents.
- An Actor is simply defined as being different from a Thing because an Actor is “a business entity that is capable of performing behavior” [ARCHIMATE].
- A Thing has an Owner.
- The Owner of a Thing is an Actor.
Please reference this URL in your answers: https://hyperonomy.com/2019/01/04/the-path-from-a-id-did-to-a-real-life-something/
- Can the data from the Metadata Document (6) be merged into/placed inside the DID Document (0)? If so how?
- Daniel Hardman (2019-01-07): A DID Document can contain additional sections besides those required by the spec – but I am not aware of a way to describe those sections in an interoperable way. So adding extra metadata to the DID Document would require a new convention or standard to be described.
- Related but separate from the first question, where does the Indy Schema effort/project artifacts (e.g. Schema Documents) fit into the above graphic?
- Daniel Hardman (2019-01-07): “Schema” is currently used mostly to describe credentials. We could apply the concern more broadly (e.g., to A2A messages), but there is not a common understanding of anything broader.
- Is there a third repository (Schema Document Repository) that needs to be added to the graphic? …or is schema stored as “just another” DID Document in the DID Document Repository? If so, in the most likely scenario, is there a separate DID Document Repository that acts as a global Schema Document Repository. Are Schema Documents resolved through the same DID Resolver (2)?
- Daniel Hardman (2019-01-07): Schemas for credentials are stored on the ledger – not in DID Documents, but in separate SCHEMA transactions. A schema lookup is a ledger lookup, but not a DID Document lookup. Schemas are not indexed by DID, since they do not require an endpoint or key rotation construct–but rather by an identifier that helps the ledger walk its own state trie with maximum efficiency
- Is the extended data for an entity stored in the original DID Document (0) (based on the Extensibility feature of a DID Dcoument) and can/does this feature explicitly rely on Schema?
- Michael Herman (2019-01-15): You don’t want to store extended data (in the sense I intended) because everything in the DID Document becomes persisted data on the Indy Ledger (which is not desirable).
Simplest DID Data Model
If you prefer the following simplest DID Data Model (from the Technology Layer), that’s OK too. 🙂
Figure 2. Simplest DID Data Model
- 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.
Appendix A – Older Versions of the (draft) DID Data Model
Figure 0.2. End-to-end DID Data Model v0.2