<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?> "rfc2629-xhtml.ent">

<rfc category="info" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-dold-payto-14"
     ipr="trust200902">
     number="8905" ipr="trust200902" obsoletes="" updates=""
     submissionType="independent" category="info" xml:lang="en"
     tocInclude="true" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="The 'payto' URI scheme"> Scheme">
      The 'payto' URI scheme Scheme for payments Payments
    </title>
    <seriesInfo name="RFC" value="8905"/>
    <author fullname="Florian Dold" initials="F.D." initials="F." surname="Dold">
      <organization>Taler Systems SA</organization>
      <address>
        <postal>
          <street>7, rue de Mondorf</street>
          <city>Erpeldange</city>
          <code>L-5421</code>
          <country>LU</country>
          <code>5421</code>
          <country>Luxembourg</country>
        </postal>
        <email>dold@taler.net</email>
      </address>
    </author>
    <author fullname="Christian Grothoff" initials="C.G." initials="C." surname="Grothoff">
      <organization>BFH</organization>
      <organization>Bern University of Applied Sciences</organization>
      <address>
        <postal>
          <street>H&ouml;heweg 80</street>
          <street></street>
          <street>Quellgasse 21</street>
          <street/>
          <city>Biel/Bienne</city>
	  <code>CH-2501</code>
          <country>CH</country>
          <code>2501</code>
          <country>Switzerland</country>
        </postal>
        <email>christian.grothoff@bfh.ch</email>
      </address>
    </author>
    <date day="01" month="May" year="2020" />

    <!-- Meta-data Declarations --> month="October" year="2020"/>

    <area>General</area>
    <workgroup>Independent Stream</workgroup>
    <keyword>payments</keyword>
    <abstract>

      <t>
        This
      <t>This document defines the 'payto' Uniform Resource Identifier (URI)
      scheme for designating targets for payments.
      </t>

      <t>
        A payments.</t>
      <t>A unified URI scheme for all payment target types allows applications
      to offer user interactions with URIs that represent payment targets,
      simplifying the introduction of new payment systems and applications.
      </t>
      applications.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction">
<t>
  This numbered="true" toc="default">
      <name>Introduction</name>
      <t>This document defines the 'payto' Uniform Resource Identifier (URI)
      <xref target="RFC3986" /> format="default"/> scheme for designating
      transfer form data for payments.
</t> payments.</t>
      <section title="Objective">
<t>
  A numbered="true" toc="default">
        <name>Objective</name>
        <t>A 'payto' URI always identifies the target of a payment. A 'payto'
	URI
	consists of a payment target type, a target identifier identifier, and optional
	parameters such as an amount or a payment reference.
</t>
<t>
  The reference.</t>
        <t>The interpretation of the target identifier is defined by the
	payment target type, type and typically represents either a bank account or
	an (unsettled) transaction.
</t>
<t>
  A transaction.</t>
        <t>A unified URI scheme for all payment target types allows
	applications to offer user interactions with URIs that represent
	payment targets, simplifying the introduction of new payment systems
	and applications.
</t> applications.</t>
      </section>
      <section title="Requirements Language"> numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
   "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
    </section>
    <section anchor="syntax"
  title="Syntax numbered="true" toc="default">
      <name>Syntax of a 'payto' URI">
  <t>
  This URI</name>
      <t>This document uses the Augmented Backus-Naur Form (ABNF) of <xref target="RFC5234"/>.
  </t>
  <figure>
  <artwork type="abnf"><![CDATA[
      target="RFC5234" format="default"/>.</t>
<sourcecode type="abnf" ><![CDATA[
  payto-URI = "payto://" authority path-abempty [ "?" opts ]
  opts = opt *( "&" opt )
  opt-name = generic-opt / authority-specific-opt
  opt-value = *pchar
  opt = opt-name "=" opt-value
  generic-opt = "amount" / "receiver-name" / "sender-name" /
                "message" / "instruction"
  authority-specific-opt = ALPHA *( ALPHA / DIGIT / "-" / "." )
  authority = ALPHA *( ALPHA / DIGIT / "-" / "." )
]]>
  </artwork>
  </figure>
]]></sourcecode>
      <t>
    'path-abempty' is defined in <xref target="RFC3986" /> in Section 3.3. sectionFormat="of"
    section="3.3"/>.
    'pchar' is defined in <xref target="RFC3986" />, Appendix A. sectionFormat="of"
    section="A"/>.
      </t>
    </section>
    <section anchor="semantics" title="Semantics">
<t>
  The numbered="true" toc="default">
      <name>Semantics</name>
      <t>The authority component of a payment URI identifies the payment
      target type.  The payment target types are defined in the "Payment "Payto Payment
      Target Types" sub-registry, see registry (see <xref target="payto-registry" />.
      format="default"/>). The path component of the URI identifies the target
      for a payment as interpreted by the respective payment target type. The
      query component of the URI can provide additional parameters for a
      payment. Every payment target type SHOULD <bcp14>SHOULD</bcp14> accept the
      options defined in generic-opt. The default operation of applications
      that invoke a URI with the payto 'payto' scheme
  MUST <bcp14>MUST</bcp14> be to
      launch
      an application (if available) associated with the payment target type
      that can initiate a payment.

      If multiple handlers are registered for the
      same payment target type, the user SHOULD <bcp14>SHOULD</bcp14> be able to
      choose which application to launch. This allows users with multiple bank
      accounts (each accessed via the respective bank's banking application)
      to
      choose which account to pay with. An application SHOULD <bcp14>SHOULD</bcp14>
      allow dereferencing a payto 'payto' URI even if the payment target type of
      that
      URI is not registered in the "Payment "Payto Payment Target Types" sub-registry.
      registry. Details
      of the payment MUST <bcp14>MUST</bcp14> be taken from the path and options
      given in the URI.  The user SHOULD <bcp14>SHOULD</bcp14> be allowed to modify
      these details before confirming a payment.
</t> payment.</t>
    </section>
    <section anchor="examples" title="Examples">
<figure>
  <artwork><![CDATA[ numbered="true" toc="default">
      <name>Examples</name>

    <t>Valid Example:</t>
<sourcecode><![CDATA[
payto://iban/DE75512108001245126199?amount=EUR:200.0&message=hello

  INVALID
]]></sourcecode>
    <t>Invalid Example (authority missing): missing):</t>
<sourcecode><![CDATA[
payto:iban/12345
]]>
  </artwork>
</figure>
]]></sourcecode>
    </section>
    <section anchor="generic-options" title="Generic Options">
<t>
  Applications MUST numbered="true" toc="default">
      <name>Generic Options</name>
      <t>Applications <bcp14>MUST</bcp14> accept URIs with options in any
      order.  The "amount" option MUST NOT <bcp14>MUST NOT</bcp14> occur more than
      once.  Other options MAY <bcp14>MAY</bcp14> be allowed multiple times, with
      further restrictions depending on the payment target type. The following
      options SHOULD <bcp14>SHOULD</bcp14> be understood by every payment target type.
</t>
<t>
  amount: The
      type.</t>

<dl newline="false" spacing="normal">
  <dt>amount:</dt>
  <dd><t>The amount to transfer.  The format MUST be:
<figure>
  <artwork><![CDATA[ <bcp14>MUST</bcp14> be:</t>

<sourcecode type="abnf"><![CDATA[
  amount = currency ":" unit [ "." fraction ]
  currency = 1*ALPHA
  unit = 1*(DIGIT / ",")
  fraction = 1*(DIGIT / ",")
 ]]>
  </artwork>
</figure>
  If
]]></sourcecode>
      <t>If a 3-letter 'currency' is used, it MUST <bcp14>MUST</bcp14> be an <xref
      target="ISO4217" /> format="default"/> alphabetic code. A payment target
      type MAY <bcp14>MAY</bcp14> define semantics beyond ISO 4217 for currency
      codes that are not 3 characters. The 'unit' value MUST <bcp14>MUST</bcp14> be
      smaller than 2^53. If present, the 'fraction' MUST <bcp14>MUST</bcp14>
      consist of no more than 8 decimal digits. The use of commas is optional
      for readability readability, and they MUST <bcp14>MUST</bcp14> be ignored.
</t>

<t>
  receiver-name:  Name ignored.</t> </dd>

  <dt>receiver-name:</dt>
  <dd>Name of the entity that receives the payment (creditor). The value of
  this option MAY <bcp14>MAY</bcp14> be subject to lossy conversion, modification modification,
  and truncation (for example, due to line wrapping or character set conversion).
</t>

<t>
  sender-name:  Name
  conversion).</dd>
  <dt>sender-name:</dt>
  <dd>Name of the entity that makes the payment (debtor). The value of this
  option MAY <bcp14>MAY</bcp14> be subject to lossy conversion, modification modification, and
  truncation (for example, due to line wrapping or character set conversion).
</t>

<t>
  message:  A
  conversion).</dd>
  <dt>message:</dt>
  <dd>A short message to identify the purpose of the payment. The value of
  this option MAY <bcp14>MAY</bcp14> be subject to lossy conversion, modification modification,
  and truncation (for example, due to line wrapping or character set conversion).
</t>

<t>
  instruction: A
  conversion).</dd>
  <dt>instruction:</dt>
  <dd>A short message giving payment reconciliation instructions to the
  recipient. An instruction that follows the character set and length
  limitation defined by the respective payment target type SHOULD NOT <bcp14>SHOULD
  NOT</bcp14> be subject to lossy conversion.
</t> conversion.</dd>
</dl>
    </section>
    <section anchor="encoding" title="Internationalization numbered="true" toc="default">
      <name>Internationalization and Character Encoding"> Encoding</name>
      <t>
  Various payment systems use restricted character sets.
  An application that processes 'payto' URIs MUST <bcp14>MUST</bcp14> convert
  characters that are not allowed by the respective payment systems
  into allowable character characters using either an encoding or a replacement table.
  This conversion process MAY <bcp14>MAY</bcp14> be lossy, except for the
  instruction field.
  If the value of the instruction field would be subject to lossy conversion,
  modification
  modification, or truncation,
  the application SHOULD <bcp14>SHOULD</bcp14> refuse further processing of the
  payment until a
  different value for the instruction is provided.
      </t>
<t>
  To
      <t>To avoid special encoding rules for the payment target identifier,
      the userinfo component <xref target="RFC3986" /> format="default"/> is
      disallowed in payto 'payto' URIs.  Instead, the payment target identifier is
      given as an option, where encoding rules are uniform for all options.
</t>
      options.</t>
      <t>
  Defining a generic way of tagging the language of option fields containing
  natural
  language text (such as "receiver-name", "sender-name" "sender-name", and "message)
  is out of the scope of this document, as internationalization must accomodate
  accommodate the restrictions
  and requirements of the underlying banking system of the payment target
  type.

  The internationalization concerns SHOULD <bcp14>SHOULD</bcp14> be individually
  defined by each payment target type.
      </t>
    </section>
    <section anchor="tracking" title="Tracking numbered="true" toc="default">
      <name>Tracking Payment Target Types"> Types</name>
      <t> A registry of "Payto Payment Target Types Types" is described in <xref
      target="payto-registry" />. format="default"/>. The registration policy for
      this registry is "First Come First Served", as described in <xref
      target="RFC8126" />. format="default"/>. When requesting new entries,
      careful consideration of the following criteria is strongly advised:
<list style="numbers">
  <t>The advised:</t>
      <ol spacing="normal" type="1">
        <li>The description clearly defines the syntax and semantics of the
	payment target and optional parameters if applicable.</t>
  <t>Relevant applicable.</li>
        <li>Relevant references are provided if they are available.</t>
  <t>The available.</li>
        <li>The chosen name is appropriate for the payment target type, does
	not conflict with well-known payment systems, and avoids potential to
	confuse users.</t>
  <t>The users.</li>
        <li>The payment system underlying the payment target type is not
	fundamentally incompatible with the general options (such as positive
	decimal amounts) in this specification.</t>
  <t>The specification.</li>
        <li>The payment target type is not a vendor-specific version of a
	payment target type that could be described more generally by a
	vendor-neutral payment target type.</t>
  <t>The type.</li>
        <li>The specification of the new payment target type remains within
	the scope of payment transfer form data. In particular particular, specifying
	complete invoices is not in scope. Neither are processing
	instructions to the payment processor or bank beyond a simple payment.</t>
  <t>The
	payment.</li>
        <li>The payment target and the options do not contain the payment
	sender's account details.</t>
</list>
</t>
<t>
Documents details.</li>
      </ol>
      <t>Documents that support requests for new registry entries should
      provide the following information for each entry:
<list style="symbols">
<t>Name: The entry:</t>
      <dl newline="false" spacing="normal">
        <dt>Name:</dt>
	<dd>The name of the payment target type (case insensitive (case-insensitive ASCII
	string, restricted to alphanumeric characters,
dots dots, and dashes)</t>
<t>Description: A dashes).</dd>
        <dt>Description:</dt>
	<dd>A description of the payment target type, including the semantics
	of the path in the URI if applicable.</t>
<t>Example: At applicable.</dd>
        <dt>Example:</dt>
	<dd>At least one example URI to illustrate the payment target type.</t>
<t>Contact: The
	type.</dd>
        <dt>Contact:</dt>
	<dd>The contact information of a person to contact for further information</t>
<t>References: Optionally,
	information.</dd>
        <dt>References:</dt>
	<dd>Optionally, references describing the payment target type (such as
	an RFC) and target-specific options, options or references describing the
	payment system underlying the payment target type.</t>
</list>
</t>
<t>
This type.</dd>
      </dl>
      <t>This document populates the registry with six seven entries as follows
      (see
      also <xref target="payto-registry" />).
</t> format="default"/>).</t>
      <section anchor="registry-entry-ach" title="ACH numbered="true" toc="default">
        <name>ACH Bank Account">
<t>
<list style="symbols">
<t>Name: ach</t>
<t>Description: Automated Account</name>
        <dl newline="false" spacing="normal">
          <dt>Name:</dt>
	    <dd>ach</dd>
          <dt>Description:</dt>
	    <dd>Automated Clearing House. House (ACH). The path consist consists of two components,
	    components:
	      the routing number and the account number. Limitations on the
	      length
	        and character set of option values are defined by the
		implementation
		  of the handler. Language tagging and internationalization of
		  options is
		    are not supported.
</t>
<t>Example: payto://ach/122000661/1234</t>
<t>Contact: N/A</t>
<t>References: <xref supported.</dd>
          <dt>Example:</dt>
	    <dd>
<sourcecode><![CDATA[
payto://ach/122000661/1234
]]></sourcecode>
	    </dd>
          <dt>Contact:</dt>
	    <dd>N/A</dd>
          <dt>References:</dt>
	    <dd><xref target="NACHA" />, [this.I-D]</t>
</list>
</t> format="default"/>, RFC 8905</dd>
        </dl>
      </section>
      <section anchor="registry-entry-bic" title="Business numbered="true" toc="default">
        <name>Business Identifier Code">
<t>
<list style="symbols">
<t>Name: bic</t>
<t>Description: Business Code</name>
        <dl newline="false" spacing="normal">
          <dt>Name:</dt>
	    <dd>bic</dd>
          <dt>Description:</dt>

  <dd>Business Identifier Code. Code (BIC). The path consist consists of just
    a BIC. This is used for wire transfers between banks. The registry
      for BICs is provided by SWIFT. the Society for Worldwide Interbank
        Financial Telecommunication (SWIFT). The path does not allow
	specifying a
	  bank account number. Limitations on the length and character set of
	    option values are defined by the implementation of the
	      handler. Language tagging and internationalization of options is
	      are not supported.
</t>
<t>Example: payto://bic/SOGEDEFFXXX</t>
<t>Contact: N/A</t>
<t>References: <xref
	        supported.</dd>
          <dt>Example:</dt>
	    <dd>
<sourcecode><![CDATA[
payto://bic/SOGEDEFFXXX
]]></sourcecode>
	    </dd>
          <dt>Contact:</dt>
	    <dd>N/A</dd>
          <dt>References:</dt>
	    <dd><xref target="BIC" />, [this.I-D]</t>
</list>
</t> format="default"/>, RFC 8905</dd>
        </dl>
      </section>
      <section anchor="registry-entry-iban" title="International numbered="true" toc="default">
        <name>International Bank Account Number">
<t>
<list style="symbols">
<t>Name: iban</t>
<t>Description: International Number</name>
        <dl newline="false" spacing="normal">
          <dt>Name:</dt>
	    <dd>iban</dd>
          <dt>Description:</dt>

  <dd>International Bank Account Number (IBAN).  Generally  Generally, the IBAN
    allows to unambiguously derive the the associated Business
      Identifier Code (BIC). (BIC) using a lookup in the respective
      proprietary translation table.  However, some legacy applications
      process
        payments to the same IBAN differently based on the specified BIC.  Thus
	  Thus, the path can either consist of either a single component (the IBAN)
	  or
	    two components (BIC followed by IBAN).  The "message" option of
	    the payto
	      'payto' URI corresponds to the "unstructured remittance
	      information"
	        of SEPA Single Euro Payments Area (SEPA) credit transfers and is
		thus
		  limited to 140 characters with
		    character set limitations that differ according to the
		    countries of
		      the banks and payment processors involved in the
		      payment. The
		        "instruction" option of the payto 'payto' URI corresponds to
			the "end to end "end-to-end
			  identifier" of SEPA credit transfers and is thus
			  limited to to, at most most,
			    35 characters that characters, which can be alphanumeric or from
			    the allowed set of
			      special characters characters, i.e., "+?/-:().,'". Language
			      tagging and
			        internationalization of options is are not supported.
</t>
<t>Example:
  supported.</dd>
          <dt>Examples:</dt>
<dd>
<sourcecode><![CDATA[
payto://iban/DE75512108001245126199
payto://iban/SOGEDEFFXXX/DE75512108001245126199
</t>
<t>Contact: N/A</t>
<t>References: <xref
]]></sourcecode>
</dd>
          <dt>Contact:</dt>
	    <dd>N/A</dd>
          <dt>References:</dt>
	    <dd><xref target="ISO20022" />, [this.I-D]</t>
</list>
</t> format="default"/>, RFC 8905</dd>
        </dl>
      </section>
      <section anchor="registry-entry-upi" title="Unified numbered="true" toc="default">
        <name>Unified Payments Interface">
<t>
<list style="symbols">
<t>Name: upi</t>
<t>Description: Unified Interface</name>
        <dl newline="false" spacing="normal">
          <dt>Name:</dt>
	    <dd>upi</dd>
          <dt>Description:</dt>
	    <dd>Unified Payment Interface. Interface (UPI). The path is an account
	    alias.  The
	      amount and receiver-name options are mandatory for this payment
	        target. Limitations on the length and character set of option
		values
		  are defined by the implementation of the handler. Language
		  tags and
		    internationalization of options are not supported.
  </t>
<t>Example: payto://upi/alice@example.com?receiver-name=Alice&amp;amount=INR:200</t>
<t>Contact: N/A</t>
<t>References: <xref supported.</dd>
          <dt>Example:</dt>
	    <dd>
<sourcecode><![CDATA[
payto://upi/alice@example.com?receiver-name=Alice&amount=INR:200
]]></sourcecode>

	    </dd>
          <dt>Contact:</dt>
	    <dd>N/A</dd>
          <dt>References:</dt>
	    <dd><xref target="UPILinking" />, [this.I-D]</t>
</list>
</t> format="default"/>, RFC 8905</dd>
        </dl>
      </section>
      <section anchor="registry-entry-bitcoin" title="Bitcoin Address">
<t>
<list style="symbols">
<t>Name: bitcoin</t>
<t>Description: Bitcoin numbered="true" toc="default">
        <name>Bitcoin Address</name>
        <dl newline="false" spacing="normal">
          <dt>Name:</dt>
	    <dd>bitcoin</dd>
          <dt>Description:</dt>
	    <dd>Bitcoin protocol. The path is a "bitcoinaddress" "bitcoinaddress", as per <xref
	      target="BIP0021" />. format="default"/>. Limitations on the length
	    and
	      character set of option values are defined by the implementation
	      of
	        the handler. Language tags and internationalization of options
		are
		  not supported.
</t>
<t>Example: payto://bitcoin/12A1MyfXbW6RhdRAZEqofac5jCQQjwEPBu</t>
<t>Contact: N/A</t>
<t>References: <xref supported.</dd>
          <dt>Example:</dt>
	    <dd>
<sourcecode><![CDATA[
payto://bitcoin/12A1MyfXbW6RhdRAZEqofac5jCQQjwEPBu
]]></sourcecode>
	    </dd>
          <dt>Contact:</dt>
	    <dd>N/A</dd>
          <dt>References:</dt>
	    <dd><xref target="BIP0021" />, [this.I-D]</t>
</list>
</t> format="default"/>, RFC 8905</dd>
        </dl>
      </section>
      <section anchor="registry-entry-ilp" title="Interledger numbered="true" toc="default">
        <name>Interledger Protocol Address">
<t>
<list style="symbols">
<t>Name: ilp</t>
<t>Description: Interledger protocol. Address</name>
        <dl newline="false" spacing="normal">
          <dt>Name:</dt>
	    <dd>ilp</dd>
          <dt>Description:</dt>
	    <dd>Interledger protocol (ILP). The path is an ILP address address, as per
	    <xref
		  target="ILP-ADDR" />. format="default"/>. Limitations on the
	    length and
	      character set of option values are defined by the implementation
	      of
	        the handler. Language tagging and internationalization of
		options is
		  are not supported.
</t>
<t>Example: payto://ilp/g.acme.bob</t>
<t>Contact: N/A</t>
<t>References: <xref supported.</dd>
          <dt>Example:</dt>
	    <dd>payto://ilp/g.acme.bob
	    </dd>
          <dt>Contact: </dt>
	    <dd>N/A</dd>
          <dt>References:</dt>
	    <dd><xref target="ILP-ADDR" />, [this.I-D]</t>
</list>
</t> format="default"/>, RFC 8905</dd>
        </dl>
      </section>
      <section anchor="registry-entry-void" title="Void numbered="true" toc="default">
        <name>Void Payment Target">
<t>
<list style="symbols">
<t>Name: void</t>
<t>
  Description: The Target</name>
        <dl newline="false" spacing="normal">
          <dt>Name:</dt>
	    <dd>void</dd>
          <dt>Description:</dt>
	    <dd>The "void" payment target type allows specifying the
	    parameters
	      of an out-of-band payment (such as cash or other types of
	      in-person
	        transactions).  The path is optional and interpreted as a
		  comment. Limitations on the length and character set of
		  option
		    values are defined by the implementation of the
		    handler. Language
		      tags and internationalization of options are not supported.
</t>
<t>Example: payto://void/?amount=EUR:10.5</t>
<t>Contact: N/A</t>
<t>References: [this.I-D]</t>
</list>
</t>
	    supported.</dd>
          <dt>Example:</dt>
	    <dd>
<sourcecode><![CDATA[
payto://void/?amount=EUR:10.5
]]></sourcecode>
	    </dd>
          <dt>Contact:</dt>
	    <dd>N/A</dd>
          <dt>References:</dt>
	    <dd>RFC 8905</dd>
        </dl>
      </section>
    </section>

</section><!-- tracking -->

<section anchor="security" title="Security Considerations">
<t>
Interactive numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Interactive applications handling the payto 'payto' URI scheme MUST NOT <bcp14>MUST
      NOT</bcp14> initiate any financial transactions without prior review and
      confirmation from the user, user and MUST <bcp14>MUST</bcp14> take measures to
      prevent clickjacking <xref target="HMW12"/>.
</t>
<t>
Unless target="HMW12" format="default"/>.</t>
      <t>Unless a payto 'payto' URI is received over a trusted, authenticated
      channel,
      a user might not be able to identify the target of a payment.  In particular
      particular, due to homographs <xref target="unicode-tr36" />,
      format="default"/>, a payment target type SHOULD NOT <bcp14>SHOULD NOT</bcp14> use
      human-readable names in combination with unicode in the target account
      specification, as it could give the user the illusion of being able to
      identify the target account from the URI.
</t>
<t>
The URI.</t>
      <t>The authentication/authorization mechanisms and transport security
      services used to process a payment encoded in a payto 'payto' URI are handled
      by
      the application and are not in scope of this document.
</t>
<t>
To document.</t>
      <t>To avoid unnecessary data collection, payment target types SHOULD NOT
      <bcp14>SHOULD NOT</bcp14> include personally identifying information
      about the sender of a payment that is not essential for an application
      to conduct a payment.
</t> payment.</t>
</section>
    <section anchor="iana" title="IANA Considerations">

<t>
IANA maintains a registry called the "Uniform Resource Identifier
(URI) Schemes" registry.
</t>

<section anchor="payto-uri" title="URI Scheme Registration"> numbered="true" toc="default">

      <name>IANA Considerations</name>
        <t>
  IANA maintains the "Uniform Resource Identifier (URI) Schemes"
  registry that registry,
  which contains an entry for the 'payto' URI scheme. scheme as follows.  IANA is
  requested to update has updated that
  entry to reference this document when
  published as an RFC.
</t>
</section> document.</t>

<dl>
  <dt>Scheme name:</dt><dd> payto</dd>

  <dt>Status:</dt><dd> provisional</dd>

  <dt>URI scheme syntax:</dt><dd>See <xref target="syntax"/> of RFC 8905.</dd>

  <dt>URI scheme semantics:</dt><dd>See <xref target="semantics"/> of RFC
  8905.
</dd>

  <dt>Applications/protocols that use this scheme name:</dt><dd> payto URIs are
  mainly used by financial software.</dd>

  <dt>Contact:</dt><dd><t><contact fullname="Christian Grothoff"/> &lt;grothoff@gnu.org&gt;</t></dd>

  <dt>Change controller:</dt><dd><t><contact fullname="Christian Grothoff"/> &lt;grothoff@gnu.org&gt;</t></dd>

  <dt>References:</dt><dd> See <xref target="refs"/> of RFC 8905.</dd>
</dl>

    </section>

    <section anchor="payto-registry" title="Payment numbered="true" toc="default">
      <name>Payto Payment Target Types"> Types</name>
      <t>
   This document specifies a list of Payment Target Types. payment target types.  It is
   possible that future work will need to specify additional payment
   target types.  The GNUnet Assigned Numbers Authority (GANA) <xref
   target="GANA" /> format="default"/>
   operates the "payto-payment-target-types" "Payto Payment Target Types" registry to track
   the following information for each payment target type:
<list style="symbols">
<t>Name:  The
      </t>
      <dl newline="false" spacing="normal">
        <dt>Name:</dt>
	<dd>The name of the payment target type (case insensitive (case-insensitive ASCII
	string, restricted to alphanumeric characters,
dots dots, and dashes)</t>
<t>Contact: The dashes)</dd>
        <dt>Contact:</dt>
	<dd>The contact information of a person to contact for further information</t>
<t>References: Optionally,
	information</dd>
        <dt>References:</dt>
	<dd>Optionally, references describing the payment target type (such as
	an RFC) and target-specific options, options or references describing the
	payment system underlying the payment target type.</t>
</list>
</t> type</dd>
      </dl>
      <t>
  The entries that have been made for in the "payto-payment-target-types" "Payto Payment Target Types" registry
  defined in this document are as follows:
      </t>
<figure>
  <artwork>
    Name      | Contact                 | Reference
    ----------+-------------------------+------------
    ach       | N/A                     | [This.I-D]
    bic       | N/A                     | [This.I-D]
    iban      | N/A                     | [This.I-D]
    upi       | N/A                     | [This.I-D]
    bitcoin   | N/A                     | [This.I-D]
    ilp       | N/A                     | [This.I-D]
    void      | N/A                     | [This.I-D]
  </artwork>
</figure>

</section><!-- payto-registry -->
<table>
  <thead>
    <tr>
      <th>Name</th>
      <th>Contact</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>ach</td>
      <td>N/A</td>
      <td>RFC 8905</td>
    </tr>
    <tr>
      <td>bic</td>
      <td>N/A</td>
      <td>RFC 8905</td>
    </tr>
    <tr>
      <td>iban</td>
      <td>N/A</td>
      <td>RFC 8905</td>
    </tr>
    <tr>
      <td>upi</td>
      <td>N/A</td>
      <td>RFC 8905</td>
    </tr>
    <tr>
      <td>bitcoin</td>
      <td>N/A</td>
      <td>RFC 8905</td>
    </tr>
    <tr>
      <td>ilp</td>
      <td>N/A</td>
      <td>RFC 8905</td>
    </tr>
    <tr>
      <td>void</td>
      <td>N/A</td>
      <td>RFC 8905</td>
    </tr>
  </tbody>
</table>
    </section>

  </middle>
  <back>
    <references title="Normative References">

    &RFC2119;

    &RFC3986;

    &RFC5234;

    &RFC8126;

    &RFC8174; anchor="refs">
      <name>References</name>
      <references>
        <name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

        <reference anchor="ISO4217"> anchor="ISO4217" target="https://www.iso.org">
          <front>
        <title>ISO 4217 Currency Codes</title>
            <title>Codes for the representation of currencies</title>
            <author>
              <organization>International Organization for
	      Standardization</organization>
          <address>
            <uri>http://www.iso.ch</uri>
          </address>
            </author>
            <date month="August" year="2018"/> year="2015"/>
          </front>
        <seriesInfo name="ISO" value="4217"/>
        </reference>

        <reference anchor="ISO20022"> anchor="ISO20022" target="https://www.iso.org">
          <front>
        <title>ISO 20022 Financial
            <title>Financial Services - Universal financial industry message
	    scheme</title>
            <author>
              <organization>International Organization for
	      Standardization</organization>
          <address>
            <uri>http://www.iso.ch</uri>
          </address>
            </author>
            <date month="May" year="2013"/>
          </front>
        <seriesInfo name="ISO" value="20022"/>
        </reference>

        <reference anchor="NACHA">
          <front>
        <title>NACHA
            <title>2020 Nacha Operating Rules &amp; Guidelines</title>
            <author>
          <organization>NACHA</organization>
              <organization>Nacha</organization>
              <address>
                <uri>https://www.nacha.org/</uri>
              </address>
            </author>
            <date month="January" year="2017"/> year="2019"/>
          </front>
        </reference>

        <reference anchor="unicode-tr36">
          <front>
            <title abbrev="Unicode Security Considerations">Unicode Technical
	        Report #36: Unicode Security Considerations</title>
            <author initials="M." surname="Davis" fullname="Mark Davis"
		    role="editor">
              <address>
                <email>markdavis@google.com</email>
              </address>
            </author>
            <author initials="M." surname="Suignard" fullname="Michael Suignard"> Suignard"
		    role="editor">
              <address>
                <email>michel@suignard.com</email>
              </address>
            </author>
            <date month="September" year="2014"/>
          </front>
        </reference>
</references>

  <references title="Informational References">

      <references>
        <name>Informative References</name>

        <reference anchor="BIP0021" target="https://en.bitcoin.it/wiki/BIP_0021">
		   target="https://en.bitcoin.it/w/index.php?title=BIP_0021&amp;oldid=66778">
          <front>
            <title>Bitcoin Improvement Proposal 21</title>
            <author initials="N." surname="Schneider" fullname="Nils
								Schneider">
            </author>
            <author initials="M." surname="Corallo" fullname="Matt Corallo">
            </author>
            <date month="January" year="2012" /> month="September" year="2019"/>
          </front>
        </reference>

        <reference anchor="HMW12"
		   target="https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final39.pdf">
          <front>
            <title>Clickjacking: Attacks and Defenses</title>
            <author initials="L.S." initials="L." surname="Huang" fullname="Lin-Shung Huang">
            </author>
            <author initials="A." surname="Moshchuk"
                 fullname="Alexander, fullname="Alexander
							       Moshchuk">
            </author>
            <author initials="H.J." initials="H." surname="Wang" fullname="Helen J. Wang">
            </author>
            <author initials="S." surname="Schecter" fullname="Stuart
							       Schecter">
            </author>
            <author initials="C." surname="Jackson" fullname="Collin Jackson">
            </author>
            <date month="January" year="2012" /> year="2012"/>
          </front>
        </reference>

        <reference anchor="UPILinking"
		   target="https://www.npci.org.in/sites/default/files/UPI%20Linking%20Specs_ver%201.6.pdf">
          <front>
            <title>Unified Payment Interface - Common URL Specifications For
	    Deep
      Linking And Proximity Integration</title>
      <author><organization>National Payment
            <author>
              <organization>National Payments Corporation of
	      India</organization>
            </author>
            <date month="November" year="2017" /> year="2017"/>
          </front>
        </reference>

        <reference anchor="ILP-ADDR"
		   target="https://interledger.org/rfcs/0015-ilp-addresses/">
          <front>
            <title>ILP Addresses - v2.0.0</title>
      <author><organization>Interledger Team</organization>
            <author>
              <organization>Interledger</organization>
            </author>
       <date month="September" year="2018" />
          </front>
        </reference>

        <reference anchor="BIC" target="https://www.iso.org/standard/60390.html"> target="https://www.iso.org">
          <front>
       <title>ISO 9362:2014
            <title>Banking -- Banking telecommunication messages -- Business Identifier Code
	    identifier code (BIC)</title>
      <author><organization>International
            <author>
              <organization>International Organization for
	      Standardization</organization>
            </author>
            <date month="March" year="2019" /> month="December" year="2014"/>
          </front>
        <seriesInfo name="ISO" value="9362"/>
        </reference>

        <reference anchor="GANA" target="https://gana.gnunet.org/">
          <front>
            <title>GNUnet Assigned Numbers Authority (GANA)</title>
      <author><organization>GNUnet
            <author>
              <organization>GNUnet e.V.</organization>
            </author>
            <date month="April" year="2020" /> year="2020"/>
          </front>
        </reference>
      </references>

<!-- Change Log
v11 2020-03-23  CG   Workaround IESG/IAB/IANA/ISE discussion on who gets to create IANA registries as suggested by Adrian Farrel
v10 2019-11-14  CG   Address comments from Adrian Farrel
v09 2019-11-04  CG   Reference ISO 4217 for currency codes, clean up ENBF syntax and language (based on feedback from Matthias Heckmann)
v08 2019-09-27  CG   Clarify use of sub-registry as per draft-ise-iana-policy
v05 2019-05-20  CG   Addressing coments, preparing for independent stream submission, adding BIC
v01 2017-02-15  CG   References and formatting
v01 2017-02-13  CG   Minimal clarifications
v00 2017-01-17  FD   Initial version
  -->
    </references>

</back>
</rfc>