path: root/standards/draft-dold-payto.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!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">
]>
<?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" ?>

<rfc category="info"
     docName="draft-dold-payto-07"
     ipr="trust200902">

  <front>
    <title abbrev="The 'payto' URI scheme">
      The 'payto' URI scheme for payments
    </title>

    <author fullname="Florian Dold" initials="F.D." 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>
        </postal>
        <email>dold@taler.net</email>
      </address>
    </author>

    <author fullname="Christian Grothoff" initials="C.G." surname="Grothoff">
      <organization>BFH</organization>
      <address>
        <postal>
          <street>H&ouml;heweg 80</street>
          <street></street>
          <city>Biel/Bienne</city>
	  <code>CH-2501</code>
          <country>CH</country>
        </postal>
        <email>christian.grothoff@bfh.ch</email>
      </address>
    </author>

    <date day="17" month="July" year="2019" />

    <!-- Meta-data Declarations -->
    <area>General</area>
    <workgroup>Independent Stream</workgroup>
    <keyword>payments</keyword>

    <abstract>

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

    </abstract>

  </front>

  <middle>

<section anchor="introduction" title="Introduction">
<t>
  This document defines the 'payto' Uniform Resource Identifier (URI) <xref target="RFC3986" /> scheme
  for designating transfer form data for payments.  In particular, it always identifies the target of a payment.
  A 'payto' URL consists of a payment target type, a target identifier and optional parameters
  such as an amount or a payment reference.
</t>
<t>
  The interpretation of the target identifier is defined by the payment target type, and typically
  represents either a bank account or an (unsettled) 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>
<t>

</t>
</section>

<section anchor="syntax"
  title="Syntax of a 'payto' URL">
  <t>
  This document uses the Augmented Backus-Naur Form (ABNF) of <xref target="RFC5234"/>.
  </t>
  <figure>
  <artwork type="abnf"><![CDATA[
  payto-URI = "payto" "://" authority path-abempty [ "?" opts ]
  opts = opt *( "&" opt )
  opt = (generic-opt / authority-specific-opt) "=" *( pchar )
  generic-opt = "amount" / "receiver-name" / "sender-name" /
                "message" / "instruction"
  authority = ALPHA *( ALPHA / DIGIT / "-" / "." )
  path-abempty = <path-abempty, see [RFC3986], Section 3.3>
  pchar = <pchar, see [RFC3986], Appendix A.>
]]>
  </artwork>
</figure>
</section>

<section anchor="semantics" title="Semantics">
<t>
  The authority component of a payment URI identifies the payment target type.  The
  payment target types are defined in the "Payment Target Types" registry, see <xref
  target="payto-registry" />.

  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 method SHOULD accept the options defined in generic-opt.

  The default operation of applications that invoke a URI with the payto scheme
  SHOULD 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 be able to choose which application to launch.
  This allows users with multiple bank accounts (each accessed the respective bank's
  banking application) to choose which account to pay with.

  An application SHOULD allow dereferencing a payto URI even
  if the payment target type of that URI is not registered in the "Payment Target Types" registry.

  Details of the payment MUST be taken
  from the path and options given in the URI.  The user SHOULD be allowed to
  modify these details before confirming a payment.
</t>
</section>

<section anchor="examples" title="Examples">
<figure>
  <artwork><![CDATA[
  payto://iban/DE75512108001245126199?amount=EUR:200.0&message=hello

  INVALID (authority missing):  payto:iban/12345
]]>
  </artwork>
</figure>

</section>

<section anchor="generic-options" title="Generic Options">
<t>
  Applications MUST accept URIs with options in any order.  The
  "amount" option MUST only occur at most once.  Other options MAY be
  allowed multiple times, with further restrictions depending on the
  payment method.

  The following options SHOULD be understood by every payment method.
</t>
<t>

  amount:  The amount to transfer, including currency information if applicable. The format MUST be:
<figure>
  <artwork><![CDATA[
  amount = [ currency ":" ] unit [ "." fraction ]
  currency = 1*ALPHA
  unit = 1*(DIGIT / ",")
  fraction = 1*(DIGIT / ",")
 ]]>
  </artwork>
</figure>
The unit value MUST be smaller than 2^53.
If present, the fraction MUST consist of no more than 8 decimal digits.
The use of commas is optional for readability and they MUST be ignored.
</t>

<t>
  receiver-name:  Name of the entity that receives the payment (creditor).
</t>

<t>
  sender-name:  Name of the entity that makes the payment (debtor).
</t>

<t>
  message:  A short message to identify the purpose of the payment, which MAY
  be subject to lossy conversions (for example, due to character set encoding
  limitations).
</t>

<t>
  instruction:  A short message giving instructions to the recipient, which
  MUST NOT be subject to lossy conversions.  Character set limitations allowed
  for such instructions depend on the payment method.
</t>
</section>


<section anchor="encoding" title="Internationalization and Character Encoding">
<t>
  Various payment systems use restricted character sets.
  An application that processes 'payto' URIs MUST convert
  characters that are not allowed by the respective payment systems
  into allowable character using either an encoding or a replacement table.
  This conversion process MAY be lossy, except for the instruction field.
</t>
<t>
  To avoid special encoding rules for the payment target identifier, the userinfo component
  <xref target="RFC3986" /> is disallowed in payto URIs.  Instead, the payment target identifier is
  given as an option, where encoding rules are uniform for all options.
</t>
</section>

<section anchor="security" title="Security Considerations">
<t>
Interactive applications handling the payto URI scheme MUST NOT initiate any
financial transactions without prior review and confirmation from the user,
and MUST take measures to prevent clickjacking <xref target="HMW12"/>.
</t>
<t>
Unless a payto URI is received over a trusted, authenticated channel,
a user might not be able to identify the target of a payment.  In particular
due to homographs <xref target="unicode-tr36" />, a payment target type SHOULD NOT
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 URL.
</t>
<t>
To avoid unnecessary data collection, payment target types SHOULD NOT
include personally identifying information about the sender of a payment that is not
essential for an application to conduct a payment.
</t>
</section>

<section anchor="iana" title="IANA Considerations">

<section anchor="payto-uri" title="URI Scheme Registration">
<t>
The "payto" URI scheme is already registered in the "Provisional URI Schemes" registry.
<list style="empty">
<t>Scheme name: payto</t>
<t>Status: provisional</t>
<t>URI scheme syntax: See <xref target="syntax" />.</t>
<t>URI scheme semantics: See <xref target="semantics" />.</t>
<t>Applications/protocols that use this scheme name: payto URIs are mainly used by financial software,
   as well as by interactive applications (e.g. email clients, chat applications) that detect
   payto URIs and allow the user to interact with them (e.g. make them clickable)</t>
<t>Contact: grothoff@gnu.org</t>
<t>Change controller: grothoff@gnu.org</t>
<!-- There does not seem to be a way to link to the references section! -->
<t>References: See References section of this document.</t>
</list>
</t>
</section>


<!-- see https://tools.ietf.org/html/rfc5226#section-4.1 -->
<section anchor="payto-registry" title="Payment Target Type Registry">
<t>
This document defines a registry for payment methods.  The name of the registry
is "Payment Target Types".
</t>
<t>The registry shall record for each entry:
<list style="symbols">
<t>Name:  The name of the payment target type (case insensitive ASCII string, restricted to alphanumeric characters,
dots and dashes)</t>
<t>Description: A description of the payment target type, including the semantics of the path in the URI if applicable.</t>
<t>Example: At least one example URI to illustrate the payment target type.</t>
<t>Contact: The contact information of a person to contact for further information</t>
<t>References: Optionally, references describing the payment method (such as an RFC) and method-specific options,
  or references describing the payment system underlying the payment target type.</t>
</list>
  The registration policy for this registry is "First Come First Served", as described in <xref target="RFC5226" />.

When requesting new entries, careful consideration of the following criteria is strongly advised:
<list style="numbers">
  <t>The description clearly defines the syntax and semantics of the payment target and optional parameters if applicable.</t>
  <t>Relevant references are provided if they are available.</t>
  <t>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 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 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 specification of the new payment target type remains within the scope of payment transfer form data.
    In 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 target and the options do not contain the payment sender's account details.</t>
</list>
</t>

<section anchor="registry-entry-ach" title="ACH Bank Account">
<t>
<list style="symbols">
<t>Name: ach</t>
<t>Description: Automated Clearing House.  The path consist of two components, the routing number and the account number.</t>
<t>Example: payto://ach/122000661/1234</t>
<t>Contact: N/A</t>
<t>References: <xref target="NACHA" /></t>
</list>
</t>
</section>

<section anchor="registry-entry-bic" title="Business Identifier Code">
<t>
<list style="symbols">
<t>Name: bic</t>
<t>Description: Business Identifier Code. The path consist of just a BIC. This is used for wire transfers between banks. The registry for BICs is provided by SWIFT. The path does not allow specifying a bank account number.</t>
<t>Example: payto://bic/SOGEDEFFXXX</t>
<t>Contact: N/A</t>
<t>References: <xref target="BIC" /></t>
</list>
</t>
</section>

<section anchor="registry-entry-iban" title="International Bank Account Number">
<t>
<list style="symbols">
<t>Name: iban</t>
<t>Description: International Bank Account Number (IBAN).  Generally the IBAN allows to unambiguously derive
  the the associated Business Identifier Code (BIC).  However, some legacy applications process payments to the same IBAN differently based on the
  specified BIC.  Thus the path can either consist of a single component (the IBAN) or two components
  (BIC and IBAN).
</t>
<t>Example:

  payto://iban/DE75512108001245126199

  payto://iban/SOGEDEFFXXX/DE75512108001245126199
</t>
<t>Contact: N/A</t>
<t>References: <xref target="ISO20022" /></t>
</list>
</t>
</section>

<section anchor="registry-entry-upi" title="Unified Payments Interface">
<t>
<list style="symbols">
<t>Name: upi</t>
<t>Description: Unified Payment Interface. The path is an account alias.  The amount and receiver-name
options are mandatory for this payment target.</t>
<t>Example: payto://upi/alice@example.com?receiver-name=Alice&amp;amount=INR:200</t>
<t>Contact: N/A</t>
<t>References: <xref target="UPILinking" /></t>
</list>
</t>
</section>

<section anchor="registry-entry-bitcoin" title="Bitcoin Address">
<t>
<list style="symbols">
<t>Name: bitcoin</t>
<t>Description: Bitcoin protocol. The path is a "bitcoinaddress" as per <xref target="BIP0021" />.</t>
<t>Example: payto://bitcoin/12A1MyfXbW6RhdRAZEqofac5jCQQjwEPBu</t>
<t>Contact: N/A</t>
<t>References: <xref target="BIP0021" /></t>
</list>
</t>
</section>

<section anchor="registry-entry-ilp" title="Interledger Protocol Address">
<t>
<list style="symbols">
<t>Name: ilp</t>
<t>Description: Interledger protocol. The path is an ILP address as per <xref target="ILP-ADDR" />.</t>
<t>Example: payto://ilp/g.acme.bob</t>
<t>Contact: N/A</t>
<t>References: <xref target="ILP-ADDR" /></t>
</list>
</t>
</section>

<!--

<t>The registry is initially populated with the following entries:</t>
<texttable>
<ttcol>Name</ttcol><ttcol>Description</ttcol><ttcol>Contact></ttcol><ttcol>References</ttcol>
<c>ach</c><c></c><c>N/A</c><c></c>
<c>iban</c><c>Single European Payment Area. The path is an IBAN. An optional BIC may preceed the IBAN.</c><c>N/A</c><c></c>
<c>upi</c><c>Unified Payment Interface. The path is an account alias.</c><c>N/A</c><c></c>
<c>bitcoin</c><c></c><c>N/A</c><c></c>
<c>ilp</c><c></c><c>N/A</c><c></c>
  </texttable>

-->

</section><!-- payto-registry -->

</section><!-- iana -->


<!-- section anchor="checksums" title="Checksums">
     <t>-
     (how should fields be sorted?  does order ever matter?)
</t>
</section -->

</middle>

<back>

  <references title="Normative References">

    &RFC3986;

    <reference anchor="ISO20022">
      <front>
        <title>ISO 20022 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>
    </reference>

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

  <reference anchor="RFC5234">
    <front>
      <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
      <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
        <organization>Brandenburg InternetWorking</organization>
        <address>
          <email>dcrocker@bbiw.net</email>
        </address>
      </author>
      <author initials="P." surname="Overell" fullname="Paul Overell">
        <organization>THUS plc.</organization>
        <address>
          <email>paul.overell@thus.net</email>
        </address>
      </author>
      <date month="January" year="2008"/>
    </front>
    <seriesInfo name="STD" value="68"/>
    <seriesInfo name="RFC" value="5234"/>
  </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">
        <address>
          <email>michel@suignard.com</email>
        </address>
      </author>
      <date month="September" year="2014"/>
    </front>
  </reference>


  <reference  anchor='RFC5226' target='https://www.rfc-editor.org/info/rfc5226'>
  <front>
  <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
  <author initials='T.' surname='Narten' fullname='T. Narten'><organization /></author>
  <author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'><organization /></author>
  <date year='2008' month='May' />
  <abstract><t>Many protocols make use of identifiers consisting of constants and other well-known values.  Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec).  To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority.  For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t>In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made.  If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role.  This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t>This document obsoletes RFC 2434.  This document specifies an Internet Best  Current Practices for the Internet Community, and requests discussion and  suggestions for improvements.</t></abstract>
  </front>
  <seriesInfo name='RFC' value='5226'/>
  <seriesInfo name='DOI' value='10.17487/RFC5226'/>
  </reference>


  </references>

  <references title="Informational References">

   <reference anchor="BIP0021" target="https://en.bitcoin.it/wiki/BIP_0021">
     <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" />
     </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." surname="Huang"
                 fullname="Lin-Shung Huang">
         </author>
         <author initials="A." surname="Moshchuk"
                 fullname="Alexander, Moshchuk">
         </author>
         <author initials="H.J." 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" />
     </front>
  </reference>

  <reference anchor="UPILinking" target="http://www.npci.org.in/documents/UPILinkingSpecificationsVersion10draft.pdf">
    <front>
      <title>Unified Payment Interface - Common URL Specifications For Deep
      Linking And Proximity Integration</title>
      <author><organization>National Payment Corporation of India</organization>
      </author>
      <date month="May" year="2016" />
    </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>
       <date month="September" year="2018" />
   </front>
 </reference>

 <reference anchor="BIC" target="https://www.iso.org/standard/60390.html">
   <front>
       <title>ISO 9362:2014 Business Identifier Code (BIC)</title>
      <author><organization>International Organization for Standardization</organization>
      </author>
       <date month="March" year="2019" />
   </front>
 </reference>

  </references>

  <!-- Change Log
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
  -->
</back>
</rfc>