A WebFinger Profile for Agent2Agent (A2A) Agent Identity Resolution

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 20 February 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

An A2A [A2A] client that holds an agent's URL can retrieve its Agent Card from "/.well-known/agent-card.json" (a well-known URI [RFC8615] 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 [RFC7033] with the "acct" URI scheme [RFC7565] 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.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

"Agent Card" and "A2A Server" are used as defined by [A2A].¶

3. Agent Identifiers

An agent identifier is an "acct" URI [RFC7565]:¶

acct:reviewer@agents.example.com

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 [RFC7565].¶

4. Resolution Procedure

GET /.well-known/webfinger?resource=acct%3Areviewer%40agents.example.com
Host: agents.example.com

{
  "subject": "acct:reviewer@agents.example.com",
  "links": [
    {
      "rel": "self",
      "type": "application/a2a+json",
      "href": "https://agents.example.com/.well-known/agent-card.json"
    }
  ]
}

5. 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.¶

6. Security Considerations

Trust anchoring:

[RFC7033] 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 ([A2A] 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 (Section 4), 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 [RFC7033] and [RFC7565] apply in full.¶

7. IANA Considerations

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

8. Implementation Status

[[Note to the RFC Editor: this section is to be removed before publication, per [RFC7942].]]¶

One independent implementation exists as of August 2026, in a governance-gateway product for A2A agents, implementing the gateway pattern of Section 5: resolution of any admitted agent's "acct" name yields the gateway's signed Agent Card. Unknown, foreign-domain, and revoked names return 404, per Section 4. The JRD is served with the application/jrd+json media type and a permissive CORS policy, per [RFC7033].¶

9. References

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.¶

Author's Address