An IANA Registry for Agent Name Service (ANS) Protocol Identifiers
draft-dimare-ans-protocol-registry-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | J. DiMare | ||
| Last updated | 2026-07-25 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-dimare-ans-protocol-registry-00
Network Working Group J. DiMare
Internet-Draft DNS of Money
Intended status: Best Current Practice 25 July 2026
Expires: 26 January 2027
An IANA Registry for Agent Name Service (ANS) Protocol Identifiers
draft-dimare-ans-protocol-registry-00
Abstract
The Agent Name Service (ANS), described in draft-narajala-courtney-
ansv2, identifies the interaction protocol an agent speaks by a
protocol identifier carried in the "p" field of the agent's "_ans"
DNS record and Trust Card. ANS defines the values "a2a", "mcp", and
"http" by enumeration, and its IANA Considerations create no
registry, leaving no interoperable procedure for adding a new
protocol identifier. This document requests that IANA create an "ANS
Protocol Identifiers" registry, registers the values already in use,
and registers "pay" as the protocol identifier for agent payment.
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
DiMare Expires 26 January 2027 [Page 1]
Internet-Draft ANS Protocol Identifiers July 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Protocol Identifier Syntax . . . . . . . . . . . . . . . . . 3
4. Registration Procedure . . . . . . . . . . . . . . . . . . . 4
5. Guidance for the Designated Expert . . . . . . . . . . . . . 4
6. Initial Registry Contents . . . . . . . . . . . . . . . . . . 5
7. The "pay" Protocol Identifier . . . . . . . . . . . . . . . . 5
8. Relationship to Existing Work . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
11. Normative References . . . . . . . . . . . . . . . . . . . . 7
12. Informative References . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
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.
DiMare Expires 26 January 2027 [Page 2]
Internet-Draft ANS Protocol Identifiers July 2026
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.
DiMare Expires 26 January 2027 [Page 3]
Internet-Draft ANS Protocol Identifiers July 2026
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.
DiMare Expires 26 January 2027 [Page 4]
Internet-Draft ANS Protocol Identifiers July 2026
* 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.
+============+================+================+===================+
| Identifier | Protocol Name | Reference | Change Controller |
+============+================+================+===================+
| a2a | Agent-to-Agent | [ANSv2] | IESG |
+------------+----------------+----------------+-------------------+
| mcp | Model Context | [ANSv2] | IESG |
| | Protocol | | |
+------------+----------------+----------------+-------------------+
| http | HTTP-based API | [ANSv2] | IESG |
+------------+----------------+----------------+-------------------+
| pay | Agent Payment | This document, | J. DiMare |
| | | Section 7 | |
+------------+----------------+----------------+-------------------+
Table 1: Initial ANS Protocol Identifiers
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.
DiMare Expires 26 January 2027 [Page 5]
Internet-Draft ANS Protocol Identifiers July 2026
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.
DiMare Expires 26 January 2027 [Page 6]
Internet-Draft ANS Protocol Identifiers July 2026
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.
11. Normative References
DiMare Expires 26 January 2027 [Page 7]
Internet-Draft ANS Protocol Identifiers July 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
12. Informative References
[ANSv2] Courtney, S. and V. S. Narajala, "Agent Name Service v2
(ANS): A Domain-Anchored Trust Layer for Autonomous AI
Agent Identity", Work in Progress, Internet-Draft, draft-
narajala-courtney-ansv2-01, 2026,
<https://datatracker.ietf.org/doc/draft-narajala-courtney-
ansv2/>.
[RFC8905] Dold, F. and C. Grothoff, "The 'payto' URI Scheme for
Payments", RFC 8905, October 2020,
<https://www.rfc-editor.org/info/rfc8905>.
Author's Address
J. DiMare
DNS of Money
Email: jdimare@pm.me
DiMare Expires 26 January 2027 [Page 8]