Need explanation of DIDComm's role as a foundation for higher-level protocols

[dhh1128]

Some who approach DIDComm may view it simply as a transport mechanism, with the purpose being to enable arbitrary messages to flow securely. That is not wrong, exactly -- but it's incomplete. A major purpose of many features in DIDComm (e.g., timing headers, threading, etc) is to facilitate higher-level protocols. If you read the DIDComm spec and don't get that, you've missed something really important.

Our current spec doesn't surface this truth, and doesn't provide guidance about how to write a protocol atop DIDComm.

I suggest we add a couple paragraphs to the core spec explaining the general theory, and then add some content to the Guide that explains how to take advantage of DIDComm features to build good protocols.

[Arxcis]

As a newcomer I can testify that the current DIDComm spec is confusing. I was expecting transport-only, but then we have a section like § 12 General Message Constructs which lists the following concepts:

• Decorators (headers)
• Threading
• Message types / families
• Reliable Delivery
• Attachments
• Attachment/Payload Signatures
• Timing
• ACKs
• Errors
• Tracing / troubleshooting

Are these things mandatory for any protocol on top? Shouldn't it be enough to only require the message-type-attribute?

My example protocol If I make a new protocol called "type": "did:github:Arxcis#mini/1.0", to transmit mini-messages, I would expect to be able to send messages which look like this:

{
    "@type": "did:github:Arxcis#mini/1.0",
    "msg": "Hello"
}

Am I allowed to do that according to the DIDComm-spec? Which fields are required? If so, why do we ever need more than the "@type"-field to be required?

[Arxcis]

I found some answers regarding @id and @type here -> https://github.com/hyperledger/aries-rfcs/tree/9363159d517afa3c17a79b5d8394e933c652de84/concepts/0047-json-ld-compatibility#what-the-casual-developer-needs-to-know

[dhh1128]

Sorry about the lack of clarity. The spec has a number of rough edges right now. One of them is that we copied a bunch of material from other documents that described the first generation of DIDComm, and we haven't yet edited all the material for coherence. Sometimes the tribal knowledge is not obvious to those of us who have worked on this too deeply -- so it is super helpful to have a new person's perspective. Thank you!

Your example protocol would be totally legal under DIDComm v1 (as described in the Hyperledger Aries RFCs). All of those extra topics are general DIDComm features that MAY be used but that are optional.

Under DIDComm v2 (the spec you are reading), you no longer use the @ on type and id. Also, id is now required. (Although a given protocol may imagine that it doesn't need to identify messages, having an id allows errors to point to the message that triggered them, so it was deemed broadly useful no matter the protocol.) And the properties that make a message type unique now move into body, with decorators now being referred to as "headers." Thus, your sample would look like this in DIDComm v2:

{
    "id":  "abc123",
    "type": "did:github:Arxcis#mini/1.0",
    "body": {
        "msg": "Hello"
    }
}

Please ask as many follow-up questions as you need to; as I said, it's super helpful to see what a new reader of the spec wonders about.

[Arxcis]

To summarize: For any protocol under DIDComm v2, there are 3 required properties: id, type and body. Am I correct?

UPDATE: Relevant section in the spec: https://identity.foundation/didcomm-messaging/spec/#message-headers

[dhh1128]

Yes. That's my understanding.

[Arxcis]

Question: Consider §12.1 Protocols which states:

DIDComm serves as a foundational layer for the development of protocols. This spec does not include protocols themselves, but describes the basic requirements and foundational elements

Still there are multiple protocols included in the spec, which conflicts with the above statement.

Here are the ones I found:

• https://didcomm.org/routing/2.0/(forward)
• https://didcomm.org/out-of-band/0.1/(invitation)
• https://didcomm.org/discover-features/1.0/(query|disclose)
• https://didcomm.org/trust_ping/1.0/(ping|ping_response)

What is the plan for these protocols? Would they eventually be moved out of the spec to a separate location?

Maybe a "DIDComm Specification Registries" would be a good idea? Like the DID Specification Registries?

[swcurran]

Two of them are clearly part of DIDComm -- routing (how messages get to their recipient) and OOB, which is how a connection is established.

I personally think the other two should be moved out, as they are not about the messaging base.

• Trust ping is there likely because it is the most trivial way to verify that you have a connection. But not really crucial to the lower layer messaging.
• Discover features is there so once you have a connection, you can ask the other party what is possible with the connection. Again -- not crucial to the lower layer messaging and so IMHO, should be removed.

But the two are in the gray area between layers that there are arguments on both sides.

[dhh1128]

I 100% agree with Stephen about what is crisp and what is gray. Part of what is keeping the gray stuff in the spec is that we don't yet have a good alternative place to put them (right now, we could put them in Aries, but they'd be next-generations of the Aries stuff; Aries is not yet dealing with DIDComm v2). Perhaps when that gets resolved, we'll get them moved out of the spec, just leaving the 2 necessary items.

[kdenhartog]

I've been thinking that discover-feature and OOB could be collapsed into a single protocol recently. This way if someone wants to focus on connection setup they do it all together, but if it's an update to a connection (say for example after a 0-RTT message) then they could send the same message to perform the update. This makes it easier to manage the state of a connection I suspect (not confirmed in an implementation yet though)

[TelegramSam]

DIscussed WG 20220110. Will add commentary about role of protocols (also see Oliver's suggestions in another ticket.).