Competition

When comparing protocols for peer-to-peer Agentic AI, we are considering that each agent, in an agent-to-agent communication, needs to be able to:

  • Resolve the identity of another agent, and the person or business that agent represents
  • Verify the authenticity of the other agent
  • Establish a secure communications channel

There are many widely adopted standards that accomplish the above for both human-to-server and client-to-server interactions on the Internet. So why should we consider another standard?

Some reasons for new standards are opinionated. For example, the desire for decentralized identities that are portable. Other reasons are technical, such as the shift from human-in-the-loop protocols (e.g. Captcha, and MFA using SMS or email verification codes) to ones that are machine-to-machine.

Some Opinionated Considerations For Protocols

  • A decentralized identity that is portable and under the the control of the user
  • Challenges to "normal" end-users managing keys (e.g. blockchain and loss of a private key - James Howells)
  • Risks (and conveniences) with a trusted third-party managing authentication (e.g. Google or Facebook OAuth)
  • Delegation: The desire for an agent can act on behalf of a controlling identity such as a person or business

Some Technical Considerations For Protocols

  • Human-in-the-loop protocols require a person (Captcha), or tools only a person has access to (e.g. SMS or email)
  • Implementation complexity of the system my stifle adoption (e.g. WebID-TLS required certificate management)
  • Multi-tenancy: A single service can simultaneously represent multiple agents

Protocols

The following projects provide authentication and identity that can be applied to agent-to-agent interactions.

Dynamic authorizers Decentralized ID Delegation Requires...
Agentic-Profile Yes Available Yes DID hosting
AT Protocol Yes Yes Yes Blockchain
WebID-TLS No No Yes Certificate authority, CRL [1]
WebID-OIDC
OAuth No No Yes Centralized or Federated auth services
AZTP No No SPIRE service [2]

More protocols to consider:

| Nuggets
| Arcade.dev
| Lit Protocol
| OpenAI Assistants API
| APAC
| Model Context Protocol
| Agent Discovery Protocol
| Web Finger
| Kerberos
| Radius
| TACACS+
| LDAP
| Crew AI
| Autogen
| Bitte
| llms.txt
| AWS IAM

Columns:

  • Dynamic authorizers means a client can specify any authorization service that complies with a server compatible protocol. We consider the use of public/private keys and no external authorization service to be dynamic.

  • Decentralized ID means an identity is controlled by the user and not by another entity. For example the user can move a DID to from host A to host B without needing host A to agree.

  • Delegation means a user can delegate tasks to services, agents, etc. and have them operate on the user's behalf.

  • Requires lists services that are requires to accomplish identity management and authentication

Notes:

  1. Introduced in 2009, limited adoption was attributed to difficulties in certificate management. Configuring current cloud services for mTLS can be problematic. mTLS was also not designed for a very large number of client certificates which would be the case if every person has many agents. ↩︎

  2. Authentication is per workload/process, and does not support multi-tenancy ↩︎

Other options and the reason they are not listed above:

  • AITP - is a transaction protocol used between agents once the session (Thread) is authenticated.
  • FIDO2/WebAuthn - uses biometrics and security keys.
  • LangChain - Not an identity or authentication provider.
  • JSON Web Token (JWT) - Not an identity or authentication provider. Widely used by other services.
  • SSL/TLS - A foundation of many services above, but does not provide a convenient universal identifier for agents. WebId-TLS is a great prototype.
  • JSON Web Signature (JWS) - Not an identity or authentication provider. Widely used by other services.

Use Cases

The following are some use cases that can help qualify if an identity and authorization system can work with peer-to-peer agentic AI.

Presence Service

Requirements:

  1. User service collects user locations and notifies presence service
  2. Presence service identifies nearby people and notifies their agents
  3. Agents of nearby people communicate with each other

Detailed Steps:

  • User service authenticates with presence service as a delegate of a user, and provides the users global id, and the users geographic location
  • Presence service uses a user's global id to discover an agent to notify of nearby people
  • Presence service, acting on it's own behalf, notifies the agents of nearby people of their proximity.
  • Agents of people are able to discover the agents of nearby people, authenticate, and communicate with them.