Monthly Archives: November 2022

[OLD] DIDComm Agent Architecture Reference Model (DIDComm-ARM): A Preview

The final released version of this whitepaper can be found here:

Copyright (c) 2021 Michael Herman (Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
https://creativecommons.org/licenses/by-sa/4.0/legalcode

The following is an excerpt from a whitepaper I’m working on. Early feedback is always welcome.

BREAKING NEWS: I’ve added some of the more recent revisions that have been made to the DIDComm-ARM to this preview post:

  • Layer 4 DIDComm Agent Mesh Network Model
  • Layer 5 DIDComm User Agent Model

Examples of these models can be found at end of the blog post.

DIDComm-ARM 6-Layer Model

Each of the DIDComm-ARM layers is illustrated using a characteristic scenario:
• Layer 0 REST/HTTP Agent: Complete Model
• Layer 1 DID Addressable Agent: Complete Model
• Level 2 DIDComm Agent: Complete Model
• Layer 3 DIDComm Agent with Verifiable Credential Attachments Model: Complete Model
• Layer 4 DIDComm Agent Mesh Network Model: Complete Model
• Layer 5 DIDComm User Agent Model: Complete Model

The layers of the DIDComm-ARM model can be organized into feature matrix based on each layer’s use of DID Addressability and DIDComm Messaging.

Figure 44. DIDComm-ARM 6-Layer Feature Matrix

Each model is described in the following sections.

Layer 0 REST/HTTP Agent Model

Figure 17. Layer 0 REST/HTTP Agent: Complete Model

Layer 0 REST/HTTP Agent model is the simplest scenario: a plain text message is transmitted “in the clear” between a REST/HTTP Client and REST/HTTP Agent. The REST/HTTP Client needs to know or determine the Internet address of the REST/HTTP Agent Receiver. In this scenario, the Internet address is determined using conventional means; a DID Registry is not used nor is it part of this scenario.

Layer 1 DID Addressable REST/HTTP Agent Model

Figure 18. Layer 1 DID Addressable Agent: Complete Model

The Layer 1 DID Addressable Agent model builds on top of Layer 0 by including a DID Registry and associating, in this scenario, a person to each of the agents and using the person’s decentralized identifier (DID) to lookup the Internet address of the Receiver REST/HTTP Agent; in this case, Bob.


Layer 2 DIDComm Agent Model

Figure 19. Level 2 DIDComm Agent: Complete Model

The Layer 2 DIDComm Agent model builds on top of the Layer 1 DID Addressable Agent model by replacing the REST/HTTP plain text messages (and protocol) with authenticated, encrypted DIDComm messages. The Sender in this scenario is ABC Grocery’s DIDComm Client; the Receiver is David’s Cabbages’ DIDComm Agent.

Layer 3 DIDComm Agent with Verifiable Credential Attachments Model

Figure 20. Layer 3 DIDComm Agent with Verifiable Credential Attachments Model: Complete Model

The Layer 3 DIDComm Agent with Verifiable Credentials Attachments model builds on top of the Layer 2 DIDComm Agent scenario by enabling the use of DIDComm Message Attachments and using this capability to attach a verifiable credential to a DIDComm Message. In this specific scenario, a purchase order verifiable credential is issued by ABC Grocery’s DIDComm Client and sent as a DIDComm message attachment to David’s Cabbages’ DIDComm Agent.

Layer 4 DIDComm Agent Mesh Network Model

Figure 43. Layer 4 DIDComm Agent Network: Complete Model

The Layer 4 DIDComm Agent Mesh Network Model builds on the previous layers of the DIDComm-ARM by replacing the point-to-point DIDComm Message routing between a client and an agent or an agent and a second agent with a graph-based message routing solution to support mesh network routing of DIDComm Messages. This model can be thought of as an extension or elaboration of the how Mediators and Relays work with the DIDComm Routing pattern (https://didcomm.org/book/v2/routing).

What do Decentralized Identifiers Identify?

A decentralized identifier should be interpreted as a unique reference or identifier to a concrete something (aka subject): a person, an organization, a business document (purchase order, invoice, etc.), an education credential, a car, a boat, a house, a software module, a deployed instance of a software module, etc.
Everything else in a decentralized identifier-based software system is addressed by dereferencing or resolving the decentralized identifier to obtain something else (e.g. a DID Document, Revocation List entry, Service Endpoint addresses (via a second level of indirection through the DID Document)).
For example, the “id” field in a verifiable credential should be the unique identifier for the concrete object (aka subject) that the verifiable credential is an instantiation of.
The following are examples of subjects and their software agents to help clarify the above points.


People and Agents
Alice and Bob are people. In addition, each of Alice and Bob have their own software agent. Each software agent has one or more endpoints that are used to receive messages from other parties. Usually, an agent will also have an Origin capable to sending messages to another agent’s endpoint (as illustrated below).

Figure 28. People and Agents

In a decentralized identifier-based software system, each person is expected to have one or more unique decentralized identifiers. In the example low, Alice, the person, has the decentralized identifier did:person:1234 and Bob, also a person, has a decentralized identifier of did:person:5678 (see below).

Figure 29. People, Agents, and Decentralized Identifiers (DIDs)

Layer 5 DIDComm User Agent Model

Figure 49. Layer 5 DIDComm User Agent Model

Leave a comment

Filed under Uncategorized

Facts, Opinions, and Folklore: A Preliminary Taxonomy

Copyright (c) 2021 Michael Herman (Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
https://creativecommons.org/licenses/by-sa/4.0/legalcode

This preliminary taxonomy attempts to characterize the differences between facts, options, folklore, and related terminology. Your feedback is appreciated.

  • Facts
    • True Facts – Truths – Hard Facts – 100% true
    • False Beliefs – believed to be true but are, in fact, false
    • Fake Facts – knowingly or purposely 0% true (100% false)
  • Perturbations of the Facts
    • Misunderstood Facts
    • Misconceived Facts
    • Misstated or Miscommunicated Facts
  • Opinions
    • Feedback that may or may not be true
    • Vague
    • Poor recollected
    • Subjective opinions
    • Humorous/satirical
  • Folklore
    • Feedback originating with a fourth party and passed on by a third-party

Leave a comment

Filed under Uncategorized