DIDComm Nomenclature

[tplooker]

Opening this issue based on the conversation on the Aries WG call, tagging those that had a direct opinion on the call @swcurran @TelegramSam @dhh1128 @talltree @kdenhartog.

The pitch I made is around the issue we are having around the conflated use of the term protocol.

At present we speak about DIDComm as a messaging protocol, that is used to support different protocols such as credential exchange. DIDComm is also then hosted and communicated by a myriad of different transport layer protocols.

So in short we use protocol at three levels.

My thoughts on this matter is to redefine DIDComm as something along the following lines.

DIDComm is a messaging standard, that sets out semantics that are valid for DIDComm messages. As a standard it provides the basis for implementing DIDComm protocols such as credential exchange etc.

That way we have DIDComm protocols (e.g credential exchange) that are realised through the DIDComm messaging standard and are sent and received over different transports.

This may seem like a very subtle change in our language but I do feel it is a valuable clarification that will enable better communication with the wider community.

[dhh1128]

I'm aligned with the spirit of what you're saying, @tplooker . But I'd like to explore some questions before I vote strongly about it, because I think there are some gaps in our mental model that need filling before terms will stick.

1. If we had to put an adjective in front of "protocol" to describe things like credential issuance, hotel bookings, online auctions, tic-tac-toe, and so forth, what adjective would we pick? Those are ______ protocols?

"business"? "user-level"? "high-value"? "application"? "human-friendly"? "surface"? "creative"? "custom"? "getting-stuff-done"? "goal-oriented"? "direct"? "problem-specific"? "controlled"? "intentional"? ...

2. What contrasting adjective would we use for the layer where encryption and routing are spec'ed?

"infrastructure"? "plumbing"? "carrier-level"? "low-level"? "foundational"?, "generalized"? "means-to-an-end"?

3. What things in the scope of Aries would we consider not to be protocols? Wallets, for example? Is the encryption format for envelopes a protocol, or just a data format?

[tplooker]

Great @dhh1128, in my eyes at least I see the following.

In reference to your first point I would say they are what we would call DIDComm protocols (i.e credential exchange is a DIDComm protocol). Note in my language credential exchange is a protocol implemented using the DIDComm messaging standard.

I would like to seperate the two points you have made in point 2.

• Encryption to me is a loaded term, if you are talking about the encryption used at the envelope level of DIDComm messages, I think it should be spoken about in that context. E.g we use the following encryption techniques and object notation i.e JOSE to achieve the envelope format that is apart of the DIDComm messaging standard.

• As far as routing is concerned, the way we have defined that today is via a DIDComm protocol (e.g the the routing family of messages). In my personal opinion routing is not a concern of the DIDComm messaging standard, it is merely a protocol that can be realised using DIDComm.

Your final point I think I have touched on above, the envelope definition is apart of the messaging standard which outlines the semantics and or the data format that envelopes feature.

[dhh1128]

@tplooker Can I entice you to pick a different adjective besides "DIDComm", at least as a temporary experiment? Maybe you could convince me to go with "DIDComm" in the long term, but it doesn't help me in the short term to get at the mental model problem I was trying to tease out. What I'm fishing for is some word that explains the distinguishing quality that these protocols have, that lower-level protocols lack. I don't think "DIDComm" is what makes that layer different from the one below it--is it?So if you had to pick another adjective that elicited the essence, what would it be?

[tplooker]

@dhh1128, Im unsure what you mean by pick a different adjective? I am using DIDComm because I feel this best describes the subject of messaging standard. DIDComm is a messaging standard, when leveraged DIDComm protocols can be realised.

[dhh1128]

@tplooker "DIDComm" is not (inherently) an adjective. It's inherently a noun. You're using it as an adjective, which is fine. I get it. But in doing so, you're avoiding my deeper question, which is what the defining characteristic of the protocol layer is. Its defining characteristic can't be "didcomm"; that's just another way of saying, "everthing I label "didcomm protocols" goes here." In this discussion, I am not interested in the observation that it sits above the layer of DIDComm messaging standards as a defining characteristic. I'm interesting in other essential qualities.

Like I said, I'm not saying we can't call it that eventually. I'm just saying I want to see if we can clarify what is driving our mental model. The fact that we can't come up with anything is (to me) proving out my concern, which is that we don't have anything crisp.

[dhh1128]

Let me try to ask my question another way.

Suppose I gave you a list of things and claimed they were all protocols. My list might include stuff like TCP, IP, SMTP, HTTP, the credential issuance protocol, a non-software protocol to buy a hamburger, the protocol to file an insurance claim, a protocol used on a custom bus with embedded hardware, Bluetooth, and the "protocol" that specifies how to encrypt and route messages in DIDComm. Set aside for a minute your overwhelming desire not to call the last item a "protocol" (which I sympathize with).

Now, with that list in front of you, what rule can you give me that will help me separate the items into two categories--those that are what you're calling "DIDComm protocols", and everything else. And dont use a rule that says "sits just above DIDComm messaging standards in the stack". What I want to know is: can we articulate any such rule? If so, what essential qualities would it use to decide?

[talltree]

Now that I've caught up on this thread, I want to more clearly make the point I tried to make on last week's Aries call, which is that what we're talking about here with DIDComm is a protocol stack, and all the components of a protocol stack are—guess what?—protocols. End of story.

You don't have to look very far for an example of a protocol stack: Take a look at this sidebar from the Wikipedia page on the Internet Protocol Suite (aka TCP/IP stack):

Every single one of those is a protocol. They are all arranged in layers. That's what we're building with DIDComm. (John Jordan coined the term "Trust over IP (ToIP) stack" because of the clear analogy with the VoIP protocol stack that adapted voice communications to the Internet.)

[kdenhartog]

@tplooker "DIDComm" is not (inherently) an adjective. It's inherently a noun. You're using it as an adjective, which is fine. I get it. But in doing so, you're avoiding my deeper question, which is what the defining characteristic of the protocol layer is. Its defining characteristic can't be "didcomm"; that's just another way of saying, "everthing I label "didcomm protocols" goes here." In this discussion, I am not interested in the observation that it sits above the layer of DIDComm messaging standards as a defining characteristic. I'm interesting in other essential qualities.

Like I said, I'm not saying we can't call it that eventually. I'm just saying I want to see if we can clarify what is driving our mental model. The fact that we can't come up with anything is (to me) proving out my concern, which is that we don't have anything crisp.

I like the idea of calling them "application" protocols or "business" protocols or "business-logic" protocols.

To @talltree point, I agree this is a stack of protocols, but we can't refer to everything as "DIDComm". This turns into a messy language problem when I am referring to the cryptographic layer, where as someone else in the conversation is referring to the routing layer, and another person is referring to the semantic messaging layer. We need distinct language for these different layers because they all have different protocols operating on each layer. For example, the cryptographic layer requires the use of a JWE and can be self contained. However, at the semantic layer, we can have complex protocols with 3 or 4 different message formats which can be organized in numerous ways depending on the protocol flow. For example, the credential-offer protocol has branching where it's possible for the responder to provide a message format to continue negotiating the protocol, or an accept message format to accept the offer and complete the issuance protocol.

[talltree]

@kdenhartog Sorry if I wasn't clear—I thought the nomenclature issue was whether to call all of these "protocols". I completely agree that we need to classify them into layers. And not artificially—we need to architecturally determine which ones layer on which others. In other words, we need to draw the same diagram for the "DIDComm protocol stack" as the Wikipedia page diagram for the "Internet protocol stack/suite".

In fact I believe we should publish that diagram in—what else?—an Aries RFC, which we should constantly update as new protocols are developed for the stack. That would give us one place for developers and architects to read about the whole stack and follow links off to the RFCs describing any specific protocol in the stack.

I'll go so far as to volunteer to work on that RFC as long as the key folks working on those protocols agree to help me with it. (I just won't be able to start it until August due to my current writing backlog.)

[tplooker]

On further reflection, Im happy to concede they are all in-fact protocols and the only way we can promote a better understanding is through documentation in this domain. @talltree happy to help with this when your ready.

[talltree]

@tplooker I am very happy to collaborate on this. I'm in Utah this week and will be spending some quality time with @dhh1128 so let me discuss it with him and see if we can come up with a plan of attack for this action item.

[swcurran]

Terms I have heard recently in the community is "the DIDComm Envelope Protocol", "DIDComm Content Protocols" and "Transport Protocols" for the 3-layers that @tplooker talks about in the initial message. Can we go with those?

[dhh1128]

I'm cool with "Transport Protocols."

I don't think the envelope is a protocol. It's just a data format. Forwarding is a true protocol, but it sits above the envelope (and is in fact just one more of the highest level protocols, a peer of DID exchange, cred issuance, etc). So I vote against any term that combines "envelope" and "protocol" for the thing that sits above transports.

I don't like "content protocols" because the thing we need to describe with that term isn't about content. It's about workflow. How about "Workflow protocols" for that layer?

[TelegramSam]

Continue issue here: decentralized-identity/didcomm-messaging#21