Can Agentic AI Avoid the Tower of OAuth Babel?

Most Agent to Agent (A2A) interactions these days are cooperative, or subservient. Like employees of a single company, the different agents work together toward a common goal.

Wiring these agents together - and specifically having them authenticate - has followed a common pattern used for wiring traditional API based services, by using shared secrets usually conveyed with HTTP Authorization headers. Using a shared secret is a quick and easy way to authenticate, but it has a wide range of drawbacks. More recent efforts have added support for the much more secure OAuth protocol.

While OAuth is a very mature standard used extensively for authenticating humans, it suffers from a few critical drawbacks with autonomous agents.

First, both parties must agree on an authentication service (e.g. Google, or Auth0). This negotiation for people usually works by the person looking at a web page and pressing a "Login with Google" or "Login with Apple" button. If the person doesn't have a Google account they can quickly create one. How will agents create an account for an authentication service they are not registered with?

Companies providing authentication services will not merge the OAuth business units to serve a common good (e.g. Google+Apple+Auth0) but instead will continue to compete to preserve or grow market share - they are a business with the express purpose of making money for their investors.

If OAuth becomes the de facto way of agents authenticating then it's likely the number of OAuth companies will grow, creating a veritable Tower of OAuth Babel that agents will have to navigate.

Secondly, the authentication service does not provide a canonical identifier for the person, but instead uses an identifier unique within the authentication service. While an email is a commonly used identifier, there is no guarantee this is the one people want to be known by - the person may have several personal email accounts and a work account. Without a canonical identifier, then how do we know who the agent represents?

Thirdly, having an authentication service increases the attack surface. If the authentication service is compromised, then every agent's authentication and communication can be hacked. Large companies like Google and Apple spend enormous resources to avoid these attacks, but the mere presence of this risk should be seriously considered when there are alternatives without it.

A Few Years Ago Concensys Took a Fresh Look at These Authentication Problems

The blockchain community united over the abilities of public key cryptography. More specifically for our agentic use case, the ability to allow anyone to generate a globally unique public key which that same person could prove ownership of without disclosing a secret which only they know.

Public key cryptography is widely used in the JSON Web Token standard - a foundation of many authentication systems.

The blockchain community has also long strived for decentralized identity, and a few years ago Concensys along with Digital Bazaar and other contributors developed Decentralized Identifiers (DIDs) along with DID Documents.

DID documents provide a well thought through definition of web services that are authenticated in a variety of ways, including public key cryptography - and do not require authentication services.

Bingo! (And let's not reinvent the wheel)

For peer-to-peer agentic interactions, we can leverage the DID document standard and free ourselves of the need for centralized authentication services. Every agent can decide how they want to manage their private keys, while providing a uniform and decentralized way to authenticate. No more Tower of OAuth Babel, with a huge bonus that agents can have canonical ids which pave the way for much easier agent interactions and development of essential services like reputation.

Finally, a DID document can properly encapsulate the relationship between an entity such as a person or a business, and all the agents operating on behalf of that entity.

Yes, There is a Prototype

I've created an open source set of libraries to demonstrate DID documents powering agents in a decentralized ecosystem. These are currently in Typescript and are running in the cloud for you to try. I've also migrated the Matchwise business and social networking app to use DIDs and DID documents to orchestrate presence and agentic matching systems.

I'd love to hear your thoughts about this. Please connect with me, Mike Prince, on LinkedIn