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

Introduction The Agent Name Service (ANS) 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 (), a registration procedure and the "ANS Protocol Identifiers" registry (), guidance for the Designated Expert (), the initial registry contents including the values already in use (), and the "pay" protocol identifier for agent payment (). 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.

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.

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 .
Resolver / Verifier:: a client that reads an agent's ANS metadata, including its protocol identifiers, before connecting.
Designated Expert:: the reviewer role defined by for the "Specification Required" policy.

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 . It constrains only what a registrant may request.

Registration Procedure IANA is requested to create the "ANS Protocol Identifiers" registry (). The registration policy is "Specification Required" per , which entails Expert Review. Each registration MUST provide:

Protocol Identifier:: the token, conforming to .
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.

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.

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

Identifier	Protocol Name	Reference	Change Controller
a2a	Agent-to-Agent	[ANSv2]	IESG
mcp	Model Context Protocol	[ANSv2]	IESG
http	HTTP-based API	[ANSv2]	IESG
pay	Agent Payment	This document,	J. DiMare

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 .

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.

Relationship to Existing Work ANS base specification: 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: 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 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: 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.

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 () 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.

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 .
Registry fields:: Protocol Identifier; Protocol Name; Reference; Usage Semantics; Change Controller; Contact.
Initial contents:: as given in .

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 . IANA is requested to record this document as the defining reference for the registry and its procedure.