Network Working Group J. DiMare Internet-Draft DNS of Money Intended status: Informational 27 July 2026 Expires: 28 January 2027 The 'pay' URI Scheme for Rail-Neutral Payment Aliases draft-dimare-pay-uri-00 Abstract This document defines the "pay" Uniform Resource Identifier (URI) scheme, a rail-neutral, human- and agent-friendly name for a payment payee that resolves, through a resolution protocol, to one or more concrete payment endpoints. Unlike a URI that names a specific account on a specific payment method, a "pay" URI names a payee independently of any settlement rail; a resolver deterministically maps the name to the rail(s), endpoint(s), and metadata a payer needs to construct a payment. This document specifies the scheme syntax and semantics, the resolution mechanism and its discovery, the deterministic resolution property, and requests provisional registration of the scheme with IANA per RFC 7595. It does not define a settlement protocol and takes no custody of funds; it composes with agent-payment protocols such as x402 for the actual money movement. 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 28 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. DiMare Expires 28 January 2027 [Page 1] Internet-Draft The pay URI Scheme July 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. The "pay" URI Scheme . . . . . . . . . . . . . . . . . . . . 3 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Comparison with the "payto" URI scheme . . . . . . . . . 4 4. Resolution . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Resolver discovery . . . . . . . . . . . . . . . . . . . 5 4.2. Resolution request . . . . . . . . . . . . . . . . . . . 5 4.3. Resolution response . . . . . . . . . . . . . . . . . . . 5 4.4. Deterministic resolution . . . . . . . . . . . . . . . . 6 5. Composition with Agent-Payment Protocols . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Reference deployment wire format . . . . . . . . . . 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction AI agents and their operators increasingly need to pay one another without prior knowledge of each other's banking or on-ledger details. Today a payer must know a specific account on a specific rail (an IBAN, an on-ledger address, a card token) before value can move. That couples the payee's identity to a rail and leaks sensitive routing information to anyone who wants to pay. The "pay" URI scheme decouples the two. A "pay" URI - for example pay:acme or pay:agent.example - names a payee in a rail-neutral way. To pay it, a payer submits the name to a resolver, which returns the payment endpoint(s) the payee accepts, the preferred rail, and the metadata needed to construct a compliant payment. The intelligence - rail selection, endpoint ordering - lives in the resolver and is deterministic (see Section 4.4); the payer receives a verifiable answer, not a probabilistic one. DiMare Expires 28 January 2027 [Page 2] Internet-Draft The pay URI Scheme July 2026 This scheme is a naming and resolution layer only. It defines no settlement protocol, holds no funds, and is not a payment method in the sense of [RFC8905]. It is designed to compose with agent-payment protocols - notably x402 [X402], Agent2Agent [A2A], and agent- discovery systems such as [ANS] - which carry out the actual payment once a "pay" URI has been resolved. This document specifies the reference resolution wire format used by the first deployed registry in an informative appendix (Appendix A). The normative content - the scheme syntax, the resolution mechanism, resolver discovery, and the deterministic property - is deliberately operator-neutral: nothing here requires any particular registry, and multiple independent resolvers can serve the scheme. 2. Conventions and Terminology 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. The following terms are used: alias: The rail-neutral payee name carried in a "pay" URI, i.e. the portion after the pay: prefix. registry: A service that records the mapping from an alias to a payee and its payment endpoints. resolver: A service that answers resolution requests for aliases, returning payment endpoints and metadata. A registry typically operates a resolver; the roles are logically distinct. rail: A settlement network or payment method (for example, a specific ledger or a bank-transfer scheme) over which value ultimately moves. resolution: The act of mapping an alias to payment endpoint(s) and metadata. 3. The "pay" URI Scheme 3.1. Syntax The "pay" URI syntax is defined by the following ABNF [RFC5234], and is a restricted profile consistent with the generic syntax of [RFC3986]: DiMare Expires 28 January 2027 [Page 3] Internet-Draft The pay URI Scheme July 2026 pay-URI = "pay:" alias alias = label *( "." label ) label = alnum *62( alnum / "-" ) alnum = DIGIT / lc-alpha lc-alpha = %x61-7A ; a-z (lowercase only) Additional constraints: * The entire "pay" URI, including the pay: prefix, is at least 5 and at most 128 octets in length. * Each label is 1 to 63 octets and begins with an alphanumeric character. * Only lowercase ASCII letters, digits, and the hyphen appear in a label. No percent-encoding, uppercase letters, Unicode, userinfo, host, port, query, or fragment components are permitted. This restriction is deliberate: it eliminates homograph and normalization ambiguity (see Section 7). A "pay" URI has no authority, path, query, or fragment component; the entire scheme-specific part is the alias. 3.2. Semantics A "pay" URI identifies a payee independently of any settlement rail. It does not identify an account, a wallet, a ledger address, or a transaction. Dereferencing a "pay" URI means submitting its alias to a resolver (Section 4) and receiving the payment endpoint(s) and metadata the payee accepts. The mapping from alias to payee is stable; the set of endpoints returned MAY vary over time and MAY be tailored to the resolution context (for example, an amount or currency hint). 3.3. Comparison with the "payto" URI scheme The "payto" scheme [RFC8905] identifies a _payment target on a specific method_: payto://iban/DE75... names an account reachable over a named payment method. The "pay" scheme, by contrast, names a _rail-neutral payee_ whose concrete account(s)/endpoint(s) are discovered only at resolution time and MAY span several rails. The two are complementary, not competing: * A "payto" URI is a fully-qualified destination; a "pay" URI is a name that _resolves to_ one or more destinations. * A resolver MAY represent one of a payee's resolved endpoints as a "payto" URI where the target rail has a "payto" method registered. DiMare Expires 28 January 2027 [Page 4] Internet-Draft The pay URI Scheme July 2026 * "pay" adds rail selection and endpoint discovery above the destination layer that "payto" occupies. 4. Resolution 4.1. Resolver discovery A payer MUST determine a resolver for an alias before resolving it. Two mechanisms are defined; a payer that supports both SHOULD prefer a locally configured resolver. 1. Configured resolver: A payer MAY be configured with a default resolver origin (an "https" origin). This is the simplest deployment and matches the reference deployment (Appendix A). 2. DNS-based discovery: A resolver for a given operator domain MAY be discovered via a Service Binding (SVCB) record [RFC9460] published at the name _pay._agents., following the DNS-AID conventions [DNSAID]. The SVCB TargetName gives the resolver host; ALPN and port parameters give the transport. When DNS-based discovery is used, the zone SHOULD be signed with DNSSEC and a payer SHOULD NOT act on unsigned discovery data (see Section 7). The _pay._agents label composes with the other _._agents service labels defined by [DNSAID] (for example _mcp and _a2a), allowing an operator to publish payment-resolver discovery alongside agent-protocol discovery in one zone. This mechanism keeps the scheme operator-neutral: any operator publishing the record becomes discoverable in the standards-track way, with no central registry required. 4.2. Resolution request A resolver exposes resolution over HTTP. A payer resolves an alias by issuing an HTTP GET whose final path segment is the alias, or an HTTP POST carrying the alias and optional context (an amount, a currency, or a preferred rail) that the resolver MAY use to tailor the response. The reference request and response shapes are given in Appendix A. 4.3. Resolution response A resolution response conveys, at minimum, the alias, a resolution status, and - on success - the payment endpoint(s) and preferred rail. The status is one of: DiMare Expires 28 January 2027 [Page 5] Internet-Draft The pay URI Scheme July 2026 +====================+===============================+ | status | meaning | +====================+===============================+ | resolved | the alias resolved to at | | | least one payment endpoint | +--------------------+-------------------------------+ | not_found | no payee is registered for | | | the alias | +--------------------+-------------------------------+ | compliance_pending | resolution is held pending | | | compliance review | +--------------------+-------------------------------+ | blocked | resolution is refused (for | | | example, a sanctions match) | +--------------------+-------------------------------+ | degraded | resolved, but with reduced | | | confidence or a fallback path | +--------------------+-------------------------------+ Table 1 A resolver MAY disclose different levels of detail to different callers (for example, returning only status to unauthenticated callers and full routing metadata only to authorized ones). Such tiering is a resolver policy matter and is not constrained by this document, except that a resolver MUST NOT disclose payee routing metadata (account numbers, ledger addresses) to an unauthenticated caller. 4.4. Deterministic resolution Resolution MUST be deterministic: for a given alias and resolution context, a resolver MUST return the same routing decision. No probabilistic model, heuristic scorer, or machine-learning system is permitted in the resolution path. This is a verifiable protocol property: a payer, an auditor, or a compliance system can reproduce and check any resolution. Intelligence, if any, belongs in the _calling_ agent that decides whether and how much to pay - never in the mapping from name to endpoint. 5. Composition with Agent-Payment Protocols The "pay" scheme names and locates a payee; other protocols move the money. DiMare Expires 28 January 2027 [Page 6] Internet-Draft The pay URI Scheme July 2026 * x402 [X402]: after resolving pay:name, a payer MAY obtain HTTP 402 payment requirements for the alias and settle over x402. The resolved endpoint and the x402 "accepts" block describe the same payee. * Agent2Agent [A2A] and agent discovery [ANS]: an A2A Agent Card MAY advertise the ability to resolve or be paid via a "pay" URI; an ANS endpoint's metadata URL MAY point at such a card. In these compositions "pay" supplies the payee-naming and resolution layer that the discovery and messaging protocols lack. In all cases the "pay" scheme remains off the settlement path: it answers "who is this payee and where can I pay them", not "move value now". 6. IANA Considerations This document requests *provisional* registration of the "pay" URI scheme in the "Uniform Resource Identifier (URI) Schemes" registry, per the procedure in Section 7.2 of [RFC7595]: Scheme name: pay Status: Provisional Applications/protocols that use this scheme name: Rail-neutral naming and resolution of payment payees for human- and agent- initiated payments; composition with agent-payment protocols (for example x402) that carry out settlement. Contact: J. DiMare jdimare@pm.me (mailto:jdimare@pm.me) Change controller: J. DiMare jdimare@pm.me (mailto:jdimare@pm.me) References: This document. 7. Security Considerations Resolution integrity: A payer relies on the resolver to map an alias to the correct payee. Payers MUST resolve over TLS. When a resolver is discovered via DNS (Section 4), the zone SHOULD be DNSSEC-signed and payers SHOULD reject unsigned discovery data, to prevent an attacker from substituting a hostile resolver. Homograph and normalization safety: The alias grammar admits only DiMare Expires 28 January 2027 [Page 7] Internet-Draft The pay URI Scheme July 2026 lowercase ASCII letters, digits, and the hyphen. There is no Unicode, no percent-encoding, and no case variation, so two distinct aliases cannot be visually confused through homograph or normalization tricks that affect internationalized identifiers. Routing-metadata disclosure: Payee routing metadata (account numbers, ledger addresses) is sensitive. A resolver MUST NOT return such metadata to unauthenticated callers, and SHOULD apply least-disclosure by caller authorization. No custody, deterministic path: A resolver holds no funds and does not settle. The deterministic-resolution requirement (Section 4.4) prevents a resolver from covertly steering payments through model-driven or non-reproducible logic, and makes every resolution auditable. Amount and replay binding: This scheme does not bind an amount or prevent replay; those properties belong to the settlement protocol (for example x402) invoked after resolution. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . DiMare Expires 28 January 2027 [Page 8] Internet-Draft The pay URI Scheme July 2026 [RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, . 8.2. Informative References [A2A] "Agent2Agent (A2A) Protocol - Agent Card", 2026, . [ANS] "Agent Name Service (ANS)", 2026, . [DNSAID] Mozley-Williams, et al, "DNS-Based Agent Information Discovery (DNS-AID)", 2026, . [RFC8905] Dold, F. and C. Grothoff, "The 'payto' URI Scheme for Payments", RFC 8905, DOI 10.17487/RFC8905, October 2020, . [X402] "x402: An HTTP-native protocol for agent payments (HTTP 402 Payment Required)", 2026, . Appendix A. Reference deployment wire format This appendix is informative. It documents the resolution wire format of the first deployed "pay" resolver, as an illustration of the mechanism in Section 4. It is not normative; other resolvers MAY use other encodings. The reference resolver serves resolution at an "https" origin under /api/v1: * GET /api/v1/resolve/{alias} - resolve by path. * POST /api/v1/resolve - resolve with a JSON body { "alias_name": "...", "amount": "...", "currency": "...", "preferred_rail": "..." }, of which only alias_name is required. Responses carry an X-Resolved-From header with value origin, cache, or negative_cache, and a JSON envelope: DiMare Expires 28 January 2027 [Page 9] Internet-Draft The pay URI Scheme July 2026 { "success": true, "data": { "...": "resolution object" }, "error_code": null, "message": null, "timestamp": "2026-07-27T00:00:00Z" } The resolution object (fully disclosed) contains: resolution_id, message_id, alias, status, resolved_at, resolved_from, and - on success - preferred_rail, preferred_endpoint, fallback_endpoints, and optional iso20022_hint, compliance, and agent_commerce blocks. Each endpoint carries a rail_type, currency, priority, and (only to sufficiently authorized callers) routing_metadata. An unauthenticated caller receives only { alias, status, resolution_id, message_id, resolved_at }, consistent with the disclosure rule in Section 4. Acknowledgements Thanks to the maintainers of the DNS-AID, ANS, and x402 efforts, whose adjacent work this scheme is designed to compose with. Author's Address J. DiMare DNS of Money Email: jdimare@pm.me DiMare Expires 28 January 2027 [Page 10]