An IANA Registry for Agent Name Service (ANS) Protocol Identifiers

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 26 January 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

The Agent Name Service (ANS) [ANSv2] anchors an agent's identity to a DNS name of the form "ans://v{version}.{agentHost}". An agent declares the interaction protocol or protocols it speaks through a protocol identifier carried in the "p" field of the agent's "_ans" DNS record and in its Trust Card. ANSv2 Section 7.4.1 defines the values "a2a" (Agent-to-Agent), "mcp" (Model Context Protocol), and "http" (HTTP-based API); an omitted "p" field means "any protocol".¶

These values are defined by enumeration in the specification text and in reference-implementation source. ANSv2's IANA Considerations state that the document "has no IANA actions at this time" and anticipate only the future registration of the "ans" URI scheme and the "_ans" family of underscore labels. There is therefore no IANA registry for ANS protocol identifiers and no documented procedure for adding one. A new interaction protocol has no interoperable way to be named in the "p" field: an implementer must either use an unregistered value, which fragments interoperability, or wait for a revision of the base specification, which does not scale.¶

The gap is most visible for payment. The enumerated identifiers (ANSv2 Section 7.4.1) are "a2a", "mcp", and "http"; none expresses payment. Yet the motivating scenario for ANS in its own text (ANSv2 Section 1.1) is a payment agent instructed to wire fifty thousand dollars to a supplier's agent. A metadata field whose headline use case is payment cannot express a payment protocol and cannot be extended to add one.¶

This document closes the gap. It defines the syntax of a protocol identifier (Section 3), a registration procedure and the "ANS Protocol Identifiers" registry (Section 4), guidance for the Designated Expert (Section 5), the initial registry contents including the values already in use (Section 6), and the "pay" protocol identifier for agent payment (Section 7).¶

The registry, not any single value, is the contribution. Once it exists, "pay" is one entry among others and any future protocol can register on equal footing.¶

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

Protocol Identifier:

the token carried in the "p" field of an agent's "_ans" DNS record and Trust Card, naming an interaction protocol the agent speaks, as defined by [ANSv2].¶

Resolver / Verifier:

a client that reads an agent's ANS metadata, including its protocol identifiers, before connecting.¶

Designated Expert:

the reviewer role defined by [RFC8126] for the "Specification Required" policy.¶

3. Protocol Identifier Syntax

A protocol identifier MUST be a string of one or more characters from the set of lowercase ASCII letters (a-z), digits (0-9), and the hyphen ("-"), and MUST begin with a lowercase ASCII letter. A protocol identifier MUST NOT exceed 32 characters. Comparison is case-sensitive; registrants MUST register the lowercase form and consumers MUST treat a value that is not already lowercase, or that is unregistered, as an unknown protocol rather than guessing an intended one.¶

This syntax is a strict subset of the existing "a2a", "mcp", and "http" values and does not change how the "p" field is carried or parsed by [ANSv2]. It constrains only what a registrant may request.¶

4. Registration Procedure

IANA is requested to create the "ANS Protocol Identifiers" registry (Section 10). The registration policy is "Specification Required" per [RFC8126], which entails Expert Review.¶

Each registration MUST provide:¶

Protocol Identifier:

the token, conforming to Section 3.¶

Protocol Name:

the human-readable name of the interaction protocol the identifier names.¶

Reference:

a stable, publicly retrievable specification of the protocol and of how a consumer of an ANS agent's metadata is expected to interact with an endpoint declaring this identifier. An Internet-Draft, RFC, or an equivalently stable and openly licensed specification satisfies this requirement.¶

Usage Semantics:

a short statement of what a consumer does upon finding this identifier in an agent's "p" field (for example, open an MCP session, or fetch a payment-requirements document).¶

Change Controller:

the entity permitted to modify the entry.¶

Contact:

an email address for the registrant.¶

Registrations are permanent by default. A protocol identifier MUST NOT be reassigned to a different protocol once registered; an obsolete identifier is marked "deprecated" but retained, so that historical agent records remain interpretable.¶

5. Guidance for the Designated Expert

The Designated Expert SHOULD evaluate a request against the following criteria and SHOULD NOT apply criteria beyond these:¶

• Distinctness: the identifier names an interaction protocol that is meaningfully distinct from those already registered. A request that duplicates an existing protocol under a new spelling SHOULD be rejected.¶
• Specification stability: the Reference is retrievable, is stable, and specifies usage semantics precisely enough for independent interoperable implementation.¶
• Namespace hygiene: the identifier is not confusingly similar to an existing entry, and is not a generic term likely to be needed by the base protocol itself.¶

The Expert SHOULD NOT reject a request on the basis of the registrant's commercial interest in the protocol, provided the Reference is open and the semantics are interoperable. The purpose of the registry is to make protocol identifiers interoperable, not to adjudicate who benefits from a protocol.¶

6. Initial Registry Contents

IANA is requested to populate the registry with the following initial entries. The first three record the values already defined by [ANSv2] Section 7.4.1 and are registered here to bring the existing set under the procedure; their Reference is [ANSv2] pending any more specific document from the base-protocol authors.¶

The Change Controller for the three pre-existing values is shown as IESG on the expectation that the base-protocol authors are the proper controllers; this document defers to their preference and the final assignment is for the responsible AD to confirm. An agent MAY list more than one identifier in its "p" field; an omitted field continues to mean "any protocol" per [ANSv2].¶

7. The "pay" Protocol Identifier

An agent whose "p" field contains "pay" declares that it speaks an agent payment protocol: a consumer that wishes to settle an obligation to the agent can obtain, from the agent's advertised endpoint, the information it needs to pay.¶

Usage Semantics: upon finding "pay" in an agent's "p" field, a consumer retrieves a payment-requirements document that identifies one or more settlement endpoints and the parameters required to pay them. The concrete shape of that document is out of scope for this registration and is specified separately; this document registers only the identifier and its usage role. A companion draft specifies the payment-requirements document and its relationship to the HTTP 402 handshake and to agent-payment protocols already deployed in the field.¶

The "pay" identifier does not itself move value, custody funds, or select a settlement rail. It marks an agent as payable and points a consumer at the information used to pay; the payment occurs by whatever protocol the advertised endpoint speaks. This keeps the identifier a discovery construct rather than a financial one and keeps this registration within the scope of a naming standard.¶

8. Relationship to Existing Work

ANS base specification: [ANSv2] anticipates future registration of the "ans" URI scheme and the "_ans" family of underscore labels. This document is orthogonal to those actions: it registers values of the "p" protocol-identifier field, not the "ans" URI scheme and not any DNS underscore label. The registry defined here and any future ANS scheme or label registration can proceed independently, and the authors of this document will coordinate with the ANS base-protocol authors.¶

payto: [RFC8905] defines the "payto" URI scheme for describing a payment target. The "pay" protocol identifier and the "payto" URI scheme operate at different layers and are complementary: "pay" marks an agent as payable in ANS discovery, while a payment-requirements document returned by a "pay" agent MAY express an individual settlement target as a "payto" URI where that target is expressible in [RFC8905] terms. The companion payment-requirements draft addresses this mapping normatively; implementers are cautioned not to treat the "pay" identifier and the "payto" scheme as interchangeable.¶

ANS trust model: [ANSv2] defines a three-layer trust framework whose Layer 3 (behavioral reputation) currently carries no populated solvency signals. A separate contribution specifies a solvency signal and its ledger-anchored verification. That work is independent of this document; the protocol-identifier registry does not depend on it.¶

9. Security Considerations

Identifier confusability: a registered identifier that is visually or semantically confusable with another can mislead a consumer into interacting with an agent under the wrong protocol. The Designated Expert's namespace-hygiene criterion (Section 5) is the primary mitigation. Consumers MUST treat an unregistered or non-lowercase value as an unknown protocol rather than guessing an intended one.¶

Field integrity: the "p" field is carried in a DNS record and in the Trust Card. Its integrity therefore depends on the mechanisms ANS already specifies for those carriers (for example, DNSSEC and Trust Card signing), not on this registry. A consumer MUST NOT rely on an unauthenticated "p" value.¶

Payment misdirection: an agent declaring "pay" points a consumer at information used to move value, and is therefore a high-value target for tampering. The integrity of the payment-requirements retrieval is the responsibility of the agent's endpoint and of the payment-requirements document format, not of this registry. Consumers SHOULD require cryptographic evidence of a settlement endpoint's authenticity and MUST NOT treat information retrieved over an unauthenticated channel as trustworthy. Registering "pay" confers no trust on any agent that declares it.¶

10. IANA Considerations

IANA is requested to create a new registry group "Agent Name Service (ANS) Parameters" containing a registry titled "ANS Protocol Identifiers".¶

Registration Procedure:

Specification Required [RFC8126].¶

Registry fields:

Protocol Identifier; Protocol Name; Reference; Usage Semantics; Change Controller; Contact.¶

Initial contents:

as given in Section 6.¶

This registry governs values of the ANS "p" protocol-identifier field only. It does not register the "ans" URI scheme or any DNS underscore label; those remain for the base-protocol authors as anticipated in [ANSv2]. IANA is requested to record this document as the defining reference for the registry and its procedure.¶

Author's Address