APIs have transformed business by allowing completely different applications to interact and share data, DIDComm takes this and makes it available—with better functionality—to everyone
By Trevor Butterworth and Sam Curren
It is difficult to understate just how important APIs have been and are for digital interaction, and it is difficult to understate how much impact DIDComm will have in taking the purpose of an API and supercharging it.
This article unpacks this sentence.
First, API is an acronym for “Application Programming Interface,” a set of rules that allow different computer applications to communicate with each other. Think of an API as a translation protocol for simplifying interaction between different systems so that the data in one system can be accessed and used by another.
This seamless communication means that not only can thousands of different applications be integrated, the development of new products and services can be accelerated by virtue of breaking open all these silos of data. The result has been described as the “API economy.”
APIs are also the engines of third-party payments and services, such as Apple Pay; as IBM notes, the payments giant Stripe “began as an API with just seven lines of code.”
APIs can be internal (usable only by an enterprise or organization to integrate internal systems), partner (usable by a select group of organizations) or public (usable by any company or organization). The common denominator is that each API is specific to a particular server-client purpose: You can’t take the software you wrote to access Bank A and trivially change it to access Bank B (there is an open API definition, but it is an aide to development rather than a code for a universal API); you have to use or develop a specific API for each server or application you interact with.
APIs create the following architecture for information sharing:
For a variety of technical reasons, I can’t have an API; but DIDComm allows me to function as if I did and with a lot more features to optimize interaction. In short, DIDComm, a protocol for peer-to-peer communication between decentralized identifiers (DIDs) means that everyone can be a digital peer when it comes to asking for and receiving information.
This has profound implications for business.
Scale
First, it means that any client can interact with any server using the DIDComm protocol. Besides simplifying integration, a common protocol enables products and services to scale through network effects and for that scale to drive further innovation.
Ironically, this can be seen in one of the notable exceptions to APIs not being able to do this: WordPress. If you develop a client for WordPress, it can connect to any instance of WordPress, and that feature has transformed web design and e-commerce through products like Divi and WooCommerce. If every WordPress blog required a different API, this would be practically impossible.
Interaction
Second, as a fundamental architecture, DIDComm can support multiple kinds of interaction initiated by either party. These interactions are different to a client-server interaction, not just because you are now a peer but, significantly, because your mobile device is now also a peer.
This takes a little explanation: To receive information from a server, a client must repeatedly query the server via the API and wait for a response. This requires high availability, as the window for receiving a response via a webhook (a URL) is small. All this requires a lot of infrastructure. It’s inefficient and, typically, webhooks aren’t configured for security. The server sends out a private URL and hopes the recipient is the intended recipient. It doesn’t know who the API caller actually is.
A second, critical dimension to this is that cell phone carriers restrict cell phones from acting as servers. Internet traffic is outbound only. Consequently, the server response gets sent as either an email or as an SMS message. The contents of both can be read, and SMS is notoriously insecure.
Now think about this API architecture being used for payments and financial services — or any high value information or personally identifiable information. It’s a terrible idea.
A bit like email
DIDComm gets around all these problems by functioning like email. On a mobile device, I don’t receive email directly, I ping my email provider and retrieve my email from an email server.
DIDComm achieves the same goal using a mediator agent. With the appropriate software on my phone, I can tell a server where I want messages sent and I can retrieve them when I want. I don’t need to achieve the high availability required by an API; I can be offline and not miss a message; I don’t have to worry about firewalls; and my messages are encrypted so only I know how to read them.
Even if webhooks alone were transitioned to DIDComm, the messages sent in a webhook manner would use authenticated encryption, meaning they would be encrypted in transit and encrypted to the recipient identity previously and explicitly agreed to. Should the message go astray, it can’t be accepted and read because only the intended recipient has the cryptographic key to do so. Unlike an API ecosystem, you always know who you are interacting with in a DIDComm ecosystem.
So, we now have a protocol that enables secure, peer-to-peer data sharing between anything and anyone without direct integration and—boom!—which includes mobile devices. DIDComm is a better API, one that continues, so to speak, the APIs original mission to boldly go and integrate applications, but it does so in a much more powerful way.
Does this mean we need to get rid of APIs? No—or at least not yet. But we need to replace APIs where they should never have been used in the first place, which is to say for any purpose where personally identifying information and other high-value data is shared. When not replacing APIs outright, we can augment them with DIDComm powered webhook replacements and improved authentication and access verification methods.
For example, with protocols developed on DIDComm and other newer technologies like Object Capabilities, you can permission complex information flows between you, your bank, your credit card provider, and your financial planning service wherein each message doesn’t have to be verified or require an API call because each message is pre-verified by the architecture and only accessible to its intended recipient. Information flows can be monitored securely, and permission revoked easily.
What will distinguish the DIDComm economy?
DIDComm tends to get overshadowed by all the exciting things you can do with verifiable credentials to create seamless authentication and verifiable data. But as an architecture for digital interaction, DIDComm delivers:
- Secure, encrypted, peer-to-peer authentication
- No need for direct integration
- No need for high availability
- Offline functionality
- Easy permissioning on complex data flows
- Easier processing
- Accessibility
- Speed
- Low cost
- …And a significantly better security profile
The exciting thing to think about is what can be created when individuals with mobile devices have first-class status in digital interaction right at a point in time when mobile phones are the way a generation of digital natives interact with the world and expect to interact with the world in seamless ways.
We see the DIDComm economy as a compliment to and, for many use cases, a massive upgrade to the API economy, one that produces network effects on a new scale, driving waves of digital transformation, including the spatial web (DIDComm and usable machine identity/the Internet of Things is a whole other dimension to this, but that’s another story).
How to start using DIDComm? It’s really easy to begin the process of digital transformation by layering DIDComm and interoperable verifiable credentials into any system. Just ask us how.
Image: rob-hampson-cqFKhqv6Ong-unsplash.jpg
