]>

zhaochj@126.com

ART A2A agent identity resolution WebFinger acct The Agent2Agent (A2A) protocol retrieves an agent's self-description (the Agent Card) from a fixed well-known URI, which resolves exactly one agent per origin and presumes the client already holds a URL. This document profiles WebFinger for A2A: an agent is named by an "acct" URI (agent@domain), and resolution of that name over WebFinger yields a link to the Agent Card of the endpoint that serves the agent -- the agent's own endpoint, or a gateway fronting it. The profile introduces no new link relation, media type, or registry: it composes three deployed standards and states how they fit.

Introduction An A2A client that holds an agent's URL can retrieve its Agent Card from "/.well-known/agent-card.json" (a well-known URI registered with IANA). Two things this does not provide:

1. A name. There is no standard identifier that turns "the reviewer agent at example.com" into a URL. Addresses are passed around out of band, and nothing ties an agent's identity to a namespace anyone administers.
2. Multiplicity. A well-known URI is one path per origin. A domain hosting many agents -- the normal condition for any organisation -- can present exactly one card there.

Both problems were solved for people a long time ago: an identifier of the form local@domain, delegated through DNS, resolved through a well-known query endpoint. WebFinger with the "acct" URI scheme is the deployed, Internet-scale version of that answer, serving the federated social web today. This document profiles it for A2A agents and defines nothing that is not already registered.

Applicability This profile answers global, name-based resolution: from an agent identifier to an Agent Card URL, across the public Internet, anchored in DNS and the Web PKI. Link-local, zero-configuration discovery of agents whose names are not yet known is a different problem, addressed by ; the two compose and do not overlap.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. "Agent Card" and "A2A Server" are used as defined by .

Agent Identifiers An agent identifier is an "acct" URI : The domain part names the administrative authority; the local part names an agent within that authority's namespace. How a domain maps local parts to agents is a deployment matter and carries no protocol semantics: the domain owner is authoritative for the mapping, exactly as a mail domain is authoritative for its mailboxes. The local part SHOULD be treated case-sensitively by servers and preserved verbatim by clients; the domain part is compared case-insensitively, per .

Resolution Procedure

Query A client resolves an agent identifier with a WebFinger query to the identifier's domain, per : All requirements of apply unmodified, including the HTTPS requirement and the handling of unknown resources.

Response For a resolvable agent, the server returns a JRD whose "links" array contains at least one link of the following form:

rel:

self -- the registered link relation; no new relation is defined.

type:

the media type identifying an Agent Card representation. At the time of writing this is application/a2a+json as used by the A2A SDKs; the A2A project is pursuing registration of a dedicated media type , and once registered, that type SHOULD be used here instead. Clients SHOULD select the link by (rel, type) pair, not by rel alone.

href:

the URL of the Agent Card of the endpoint that serves the named agent ().

A client retrieves the Agent Card from href, validates it (including signature verification where signatures are present, per Section 8.4.1), and proceeds per .

Unknown, Foreign, and Withdrawn Names A server MUST respond 404 to queries for local parts it has no mapping for, for domains it is not authoritative for, and for agents whose standing has been withdrawn (revoked credentials, deregistration). Resolution is a live claim that the domain currently stands behind this name; it is not a historical record. A malformed resource (not an "acct" URI) is a client error per .

Deployment Patterns

Direct:

each agent runs its own A2A Server; href points at that agent's own card. A domain can host many such agents at distinct URLs while their names share the one domain -- this is the multiplicity the fixed well-known path cannot provide.

Gateway:

agents are fronted by a gateway that is itself an A2A Server; href points at the gateway's card, and the named agent is reached through the gateway's own protocol surface. In this pattern the resolved claim is "this agent is served here" -- the gateway's card, identity, and signatures stand for reachability, and interaction with the named agent is subject to whatever admission and policy the gateway applies. Organisations that route agent traffic through a governed chokepoint will recognise this as the normal case.

Both patterns present the identical JRD shape; clients need not distinguish them.

Relationship to the Well-Known Agent Card URI The fixed path "/.well-known/agent-card.json" remains correct and sufficient for a single-agent origin, and this profile does not deprecate it. The two compose: a single-agent domain MAY answer both (the JRD href simply pointing at the fixed path), and a multi-agent domain MUST use WebFinger to give each name a resolution, whatever URLs the cards live at.

Security Considerations

Trust anchoring:

requires HTTPS; the resolution's integrity therefore rests on the Web PKI certificate of the queried domain. What resolution establishes is precisely "this domain asserts this mapping" -- the trust shape of mail addresses and federated social handles. It does not establish anything about the agent's behaviour or authority; Agent Card signatures ( Section 8.4.1) and the client's own admission policy operate on top, unchanged.

Enumeration:

WebFinger is a point query, and this profile adds no listing operation. Servers MUST NOT answer wildcard or prefix queries, SHOULD apply rate limiting to resolution traffic, and should be aware that the existence of an agent name is itself information: a 200 discloses that the agent exists to anyone who guesses the name. Deployments for which that disclosure is unacceptable can decline to expose resolution for those names (they become unresolvable, not secret).

Withdrawal:

because resolution is a live claim (), servers MUST stop resolving names whose agents have been revoked or withdrawn. A cached JRD in a client does not extend an agent's standing: the Agent Card fetch and its verification remain the enforcement point.

The security considerations of and apply in full.

IANA Considerations This document has no IANA actions. It deliberately introduces no new link relation ("self" is registered), no new well-known URI ( registered "webfinger"), and no new media type (the Agent Card media type belongs to the A2A project; see ).

Implementation Status [[Note to the RFC Editor: this section is to be removed before publication, per .]] One independent implementation exists as of August 2026, in a governance-gateway product for A2A agents, implementing the gateway pattern of : resolution of any admitted agent's "acct" name yields the gateway's signed Agent Card. Unknown, foreign-domain, and revoked names return 404, per . The JRD is served with the application/jrd+json media type and a permissive CORS policy, per .

References Normative References This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. This document defines the 'acct' Uniform Resource Identifier (URI) scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account. A2A Project (Linux Foundation) In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

Acknowledgments The profile borrows its trust shape wholesale from the federated social web's use of WebFinger, where a decade of deployment has demonstrated that "domain vouches for local name" scales.