Intro¶
This file will work as a lightweight frequently asked questions before it grows into something unmanagable and needs to have better structure on it. For now this will offer a simple content adressing list an link to each question. We have sections of questions and questions underneath each section. They link directly to each question.
Cryptography¶
Misconceptions¶
How kosher is it to do non encrypted messages?¶
Since it is an option to not encrypt DIDComm messages, and we want to be clear on how you can reason about it
The answer to "how kosher" depends on two subquestions:
-
Are you uninterested in confidentiality because the message is intended to be public anyway (e.g., it's a message inviting anyone in the general public to send you a message)?
-
Will the message stay within trust domain boundaries? (That is, Alice sends an encrypted message to Bob; Bob decrypts and wants to send it as plaintext to 5 of his agents, but all of them are within his own sphere of control, and Bob trusts himself.)
If the answer to either of these questions is "Yes", then we think non encrypted messages are completely fine.
If the answer to both of these questions is "No", then we think messages should be encrypted, because it means confidentiality should matter. It might be tempting to say, "True. But I'm using https, which gives confidentiality anyway." This is a fallacy, because by design a sender in DIDComm doesn't actually know the full route to the target. A sender might be using HTTPS, but perhaps part of the route is not. Using channel-oriented encryption (e.g., TLS) on the part of the channel you can see is not actually secure, if someone somewhere has to take plaintext off that channel and put it somewhere else that you don't know about. The guarantee is supposed to be end-to-end. (In our question #2 above, "Bob" is the end; what he does after it gets to him is his business, not DIDComm's. That's why we are comfortable with him using plaintext in a context wholly under his own control.)
Does using DIDComm require rip-and-replace strategies?¶
This misperception seems to originate from a misunderstanding about how DIDcomm works.
Any web server capable of receiving a POST request, and sending a POST request, is capable of sending and receiving encrypted DIDComm messages. Libraries exist for message decryption, and processing inbound messages is not particularly different than processing a web request. Further libraries or software packages may add additional functionality, but the fundamentals can be enabled with very few changes to existing web properties.
DIDComm protocols also co-exist nicely with other protocols common in the Decentralized Identity space, including VC-API and OID4VCs. There is no technical reason why more than one of these protocols cannot be supported within the same system.
DIDComm builds on this basic ability to pass messages between parties to provide something deliberately different in architecture. DIDComm is a message based protocol, designed specifically to be friendly to the devices in most common use by humans. This includes built in message routing that allows human oriented devices as well as enterprise participants. This architectural model allows for interactions to be initiated be either party, allowing a much richer interaction model than API based approaches.
If native support of DIDComm isn't your goal, than you can easily use one of several codebases that support DIDComm and offer HTTP APIs for backend integration, handling not only DIDComm, but credential and other interactions as well.
In short, it easily augments any web infrastructure, provides a rich interaction model that goes beyond API approaches, and does not require removal of any existing infrastructure, systems, or protocol support.