AgentCard vs Linked VP

[ThierryThevenet]

Hello,

In the Self-Sovereign Identity (SSI) community we use the Linked VP specification (v1.0.0) – see https://identity.foundation/linked-vp/spec/v1.0.0/
– to expose verifiable data about an identity. These VPs are exposed through the DID Document of an identity to allow discovery.

It seems quite close in spirit to an Agent Card.

Are there any existing discussions, specifications or implementations that map Linked VP → Agent Card (especially in the context of DIDs, VC/VP, wallets and oidc4vc)?

Thanks!

[darrelmiller]

The TSC have an open item to clarify the specification's position on identity in the coming weeks.

Currently agents have a HTTPS URL that provides some level of identity. Agent Cards can be signed by JWS as a way of securely binding discovery metadata to that URL.

We understand there are limitations here. Ideally we can identify ways that users can layer on additional identity mechanisms that do not put a burden on those who do not need them.

There is a related issue here #1014 Perhaps we should consider allowing a DID to be used as the id value.

[ThierryThevenet]

Thanks I move to this one.

[ThierryThevenet]

@darrelmiller

I have reformulated my proposal, incorporating reflections on the AgentCard and the resolution mechanisms inherent in the concept and implementation of identity. It clearly falls within the scope of #1014.
I believe this improvement would be extremely beneficial to the protocol because it would make it immediately compatible with a large number of existing ecosystems and therefore contribute to its deployment.

🐛 Issue: Resolution Strategy Lacks Support for Decentralized Identifiers, Trusted Frameworks, and Offline Agents

The current A2A resolution mechanism relies solely on DNS-based resolution via a well-known URI (https://{domain}/.well-known/agent-card.json).
While this approach aligns with existing web standards (RFC 8615), it introduces major limitations for ecosystems that rely on decentralized identifiers (DIDs), trusted frameworks using their own namespaces, and offline or edge agents (e.g., AI agents running locally on a smartphone).

Problem Description

The resolution model assumes that every agent:

• Has a DNS-resolvable domain name, and
• Publishes its agent-card.json via HTTPS.

This design works in centralized or enterprise environments but breaks down in several modern contexts:

1. Non-URL Identifiers

Many ecosystems are using non-URL identifiers:

• Decentralized Identifiers (DIDs) – e.g., did:example:123456789abcdef
• Trust Registry Identifiers – e.g., tr:ebsi:org:bank-xyz
• Blockchain or ledger-based IDs – e.g., eth:0xABC123...

These cannot be resolved using DNS and therefore cannot use .well-known/agent-card.json.

2. Trusted Frameworks and Federated Registries

Trusted frameworks such as ToIP, EBSI, or GAIA-X maintain their own governed namespaces and registries.
Entities are identified by framework-specific URIs (e.g., tr:ebsi: or gaiax:provider:), resolved through trust registries or federated APIs — not DNS.
The current A2A model has no way to discover or verify such agents.

3. Offline and Edge Environments

The existing resolution strategy assumes online HTTP access.
This makes it incompatible with:

• AI agent instances running locally on devices (e.g., smartphone agents or edge IoT nodes).
• Peer-to-peer contexts where discovery occurs through local networks or shared credentials, not via the public web.

In such cases, agents cannot expose a public .well-known endpoint, yet still need to be discoverable and verifiable through local identifiers, cached Agent Cards, or peer DID mechanisms.

Impact

• Interoperability: A2A cannot integrate with DID-based, SSI, or trusted framework ecosystems.
• Offline limitations: Fails in local or disconnected environments (e.g., on-device agents).
• Trust limitations: Depends entirely on TLS and DNS instead of verifiable credentials or decentralized registries.
• Extensibility: Cannot support federated trust models or governed namespaces.

Proposed Enhancement

Introduce an extended resolution mechanism that supports identifier-based resolution alongside the existing DNS method.

Option A — DID-Based Discovery

Support DID Resolution as defined by the W3C DID Core specification
:

• Allow A2A agents to be referenced by their DID.
• Resolve the DID to a DID Document.

Include a service entry in the DID Document that points to the Agent Card endpoint (or use the existing linked VP specifications) .

Example (with a specific service endpoint type):

{
  "id": "did:example:my-agent",
  "service": [{
    "id": "#a2a",
    "type": "A2AService",
    "serviceEndpoint": "https://agent.example.com/.well-known/agent-card.json"
  }]
}

Option B — Trust-Registry or Federated Namespace Lookup

Enable resolution via trusted frameworks that maintain their own identifier namespaces.
Example:

• A Trust Registry defines entities with IDs like tr:ebsi:org:bank-xyz.
• Resolution occurs through the registry’s API or governance layer (not DNS).

The registry returns metadata including the A2A endpoint or Agent Card.
Trust is validated via verifiable credentials or framework attestations.

Option C — Offline or Peer Discovery

Support resolution in local or disconnected environments:

• Allow agents to exchange signed Agent Cards directly (e.g., QR codes, local P2P exchange).
• Allow DIDComm-based discovery between peer agents without DNS.
• Support caching and verification of known agents using verifiable credentials.

Option D — Hybrid Model

Maintain backward compatibility:

• Attempt DID, trust-registry, or local discovery first when the identifier is non-URL.
• Fall back to .well-known/agent-card.json when a URL is available.

How to improve the protocol: Agent Identity and Schema Evolution

Currently, the Agent Card implicitly uses its URL as its identifier.
To support decentralized, federated, and offline resolution, each Agent Card should define an explicit id property.

• the id MAY be a URL (for centralized deployments),
• the id MAY be a DID,
• or a Trust Framework Identifier for federated ecosystems.

If the id is a DID:

• Resolution begins with DID Resolution, returning a DID Document that references the Agent Card.
• The Agent Card acts as an operational descriptor, extending the DID Document with details like capabilities, supported protocols, and trust attestations.

If the id belongs to a trusted framework namespace:

• Resoluiton occurs through the framework’s registry or resolver, returning or referencing the Agent Card.

If the agent operates offline:

• The id remains stable and can be verified using locally stored or cryptographically signed Agent Cards.
• No dependency on DNS or public internet access is required.

Conceptually, the Agent Card acts as a bridge between:

• The identity layer (DID Document, trust-registry metadata, X509, ...), and
• The trust layer (verifiable credentials or framework attestations).

In a large number of ecosystems, these two layers are separated. This allows, for example, the persistence of identities and the integration of legitimate issuers of attributes for trust.

[darrelmiller]

The current A2A resolution mechanism relies solely on DNS-based resolution via a well-known URI (https://{domain}/.well-known/agent-card.json).

This is not the case. The well-known URL is only one of multiple ways of discovering an agent card. https://a2a-protocol.org/latest/specification/#52-discovery-mechanisms.

The resolution model assumes that every agent:
Has a DNS-resolvable domain name, and

Currently it is a MUST that agents have a URL that uses https. So, it is more than just an assumption, it is a requirement for the A2A protocol.

To support decentralized, federated, and offline resolution, each Agent Card should define an explicit id property.
the id MAY be a URL (for centralized deployments),
the id MAY be a DID,

Yep. That's sort of what I suggested.

It would be good to understand what existing ecosystem would take advantage of this. I've seen lots of projects talk about using using DIDs over the past few years and many of them have come and gone.

[ThierryThevenet]

In recent years, DIDs have become a common feature in most large ecosystems that are not strictly regulated by governments. There are over 200 implementations of DIDs, and they are supported by almost all tech providers.
Some DID ecosystem: https://w3c.github.io/did-extensions/methods/#did-methods
There are several large cross borders projects in Education (US/EU), Suply Chain (EU), Data Space (EBSI, GAIA-X, ...). Wherever there are DIDs, there are verifiable credentials, which are the true "markers" of decentralization.

But my suggestion would be to implement a URI-type identifier to also support regulated ecosystems that do not use URLs or DIDs.
It's likely that the resolution and even the implementation of the AgentCard would be specific, as for instance in a "pure" decentralized ecosystem, the current AgentCard in JSON format would likely be split into a DID Document (authentication + endpoints only) and verifiable credentials for all other data. However, the implementation acpect of the resolution could be considered "out of the scope" of the protocol in order to keep it agnostic to the ecosystem ?