Universal Authentication for A2A and MCP

Abstract

A2A and MCP are two emergent standards for AI-based systems to communicate. Early work on A2A and MCP focused on services that were under the control of the developer and required little to no authentication support.

As adoption has increased, two critical needs have emerged:

1. Known Server Authentication

The ability for a program to authenticate with a known A2A or MCP server that might be remote and that there is an established authentication relationship with.

2. Unknown Server Authentication

The ability of an agent or program to authenticate with an A2A or MCP server that there is no existing authentication relationship with.

For developers using orchestration frameworks to wire together agents and MCP tools under their control the first case above, API keys and OAuth, are sufficient and well-supported solutions.

For the second case, it is (a) unlikely that every agent will be integrated with a sufficient number of OAuth authentication services to ensure that every request can be authenticated, and (b) that agents will be able to derive API keys for every other agent they might interact with. For an open ecosystem where any agent should be able to discover, authenticate, and communicate with any other agent, a more universal solution is needed.

This document proposes a solution that uses DIDs, JWT, and WWW-Authenticate to authenticate agents and MCP servers.

Network Architecture

The main components of the network architecture are:

DID document repositories - Repositories store DID documents and make them available through a variety of DID methods such as web or eth. For example the DID did:web:example.com:mike resolves to the HTTP URL https://example.com/mike/did.json
A2A server - An A2A server may host one or more programs available at different endpoints that support the A2A protocol.
MCP server - An MCP server may host one or more tools at different endpoints that support the MCP protocol.
Any networked program - Any program that can use HTTP to communicate with a service can authenticate and communicate with an A2A or MCP server.

Universal Authentication can be used between any two servers that can communicate with HTTP.

Discovery

A (user) agent discovers the DID of a peer agent and wants to communicate with the peer.
The user agent fetches the DID document of the peer from a DID document repository.
The DID document provides a list of agents in the "service" array. The DID from step #1 includes the "id" of the service to communicate with as a fragment. For example, did:web:example.com:mike#friends which indicates to communicate with the "friends" agent in the DID document at https://example.com/mike/did.json.
The user agent evaluates the service record to discover the HTTP endpoint of the peer agent and the protocol to use, such as MCP or A2A.
The user agent establishes a connection using the discovered endpoint and protocol to begin HTTP communication.

Authentication Flow

The user agent sends an HTTP request to the peer agent that does not include an Authorization header.
The peer agent requires authentication, and responds with an HTTP 401 and a WWW-Authenticate header that includes a challenge
The user agent uses a private key of the verification method that is associated with the user agent in the DID document to sign the challenge. The signed challenge is encapsulated in a JWT and sent as the Authorization header in the HTTP request to the peer agent.
The peer agent validates the signed challenge and responds with an HTTP 200 and a JWT in the response body.
The user agent validates the JWT and uses the public key in the JWT to decrypt the message.

DID Document Example

{
    "@context": [
        "https://www.w3.org/ns/did/v1",
        "https://w3id.org/security/suites/jws-2020/v1",
        "https://agenticprofile.org/ns/agentic-profile/v1"
    ],
    "id": "did:web:iamagentic.ai:15",
    "name": "Mike Prince",
    "media": {
        "images": [
            "512x512",
            "96x96"
        ]
    },
    "verificationMethod": [],
    "service": [
        {
            "id": "#connect",
            "name": "Connect",
            "type": "A2A/connect",
            "serviceEndpoint": "https://api.matchwise.ai/agents/connect",
            "capabilityInvocation": [
                "did:web:api.matchwise.ai#system-key"
            ]
        },
        {
            "id": "#presence",
            "name": "Presence",
            "type": "A2A/presence",
            "serviceEndpoint": "https://api.matchwise.ai/agents/presence",
            "capabilityInvocation": [
                "did:web:api.matchwise.ai#system-key"
            ]
        }
    ]
}

The above is a DID document for the individual/entity "Mike Prince" and has the following properties:

The following agents (under the "service" property) are described: connect, and presence
The connect agent's DID derives to did:web:iamagentic.ai:15#connect and is available at https://api.matchwise.ai/agents/connect
The connect agent uses the A2A protocol, and is of the type "connect" which is well known to facilitate business connections. Other available agent types are "friends", "dating", "venture", "vc", "voter", "politician", "buy", and "sell".
Both the connect and presence agents authenticate using the did:web:api.matchwise.ai#system-key This is a server optimization to minumize the number of keys to manage. Some agents may prefer to manage their own keys and not allow the DID document host to authenticate on their behalf.
Media for this entity is available at https://iamagentic.ai/15/media and of size 512x512 and 96x96

An important take-away from using DID documents that describe multiple agents is that the DID for this document establishes a globally unique identifier that can be used to build reputation and trust.

References

A2A Protocol

MCP Protocol

W3C Decentralized Identifiers (DIDs)

JWT

Agentic Profile Auth repository