misc

1 files changed, 241 insertions, 84 deletions

diff --git a/draft-dold-payto.raw.txt b/draft-dold-payto.raw.txt
index b0881ea..7b34655 100644
--- a/draft-dold-payto.raw.txt
+++ b/draft-dold-payto.raw.txt
@@ -1,21 +1,17 @@
-
-
-
-
-Internet Engineering Task Force                                  F. Dold
-Internet-Draft                                                     INRIA
+Independent Stream                                               F. Dold
+Internet-Draft                                          Taler Systems SA
 Intended status: Informational                               C. Grothoff
-Expires: October 9, 2018                                             BFH
-                                                           April 7, 2018
+Expires: October 19, 2019                                            BFH
+                                                          April 17, 2019
 
 
                   The 'payto' URI scheme for payments
-                            draft-dold-payto
+                          draft-dold-payto-06
 
 Abstract
 
    This document defines the 'payto' Uniform Resource Identifier (URI)
-   scheme for specifying payments.
+   scheme for designating targets for payments.
 
 Status of This Memo
 
@@ -32,11 +28,11 @@ Status of This Memo
    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 October 9, 2018.
+   This Internet-Draft will expire on October 19, 2019.
 
 Copyright Notice
 
-   Copyright (c) 2018 IETF Trust and the persons identified as the
+   Copyright (c) 2019 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
@@ -56,23 +52,37 @@ Table of Contents
    3.  Semantics
    4.  Examples
    5.  Generic Options
-   6.  Encoding
+   6.  Internationalization and Character Encoding
    7.  Security Considerations
    8.  IANA Considerations
      8.1.  URI Scheme Registration
-   9.  Payto Payment Method Registry
-   10. References
-     10.1.  Normative References
-     10.2.  Informational References
+     8.2.  Payment Target Type Registry
+       8.2.1.  ACH Bank Account
+       8.2.2.  Business Identifier Code
+       8.2.3.  International Bank Account Number
+       8.2.4.  Unified Payments Interface
+       8.2.5.  Bitcoin Address
+       8.2.6.  Interledger Protocol Address
+   9.  References
+     9.1.  Normative References
+     9.2.  Informational References
    Authors' Addresses
 
 1.  Introduction
 
    This document defines the 'payto' Uniform Resource Identifier (URI)
-   [RFC3986] scheme for specifying payments.  In its simplest form, a
-   'payto' URL identifies a payment method and optionally an account
-   identifier.  Additional parameters for a payment, such as an amount
-   or a payment reference, can be provided.
+   [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.
+
+   The interpretation of the target identifier is defined by the payment
+   target type, and typically represents either a bank account or an
+   (unsettled) transaction.
+
+   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.
 
 2.  Syntax of a 'payto' URL
 
@@ -80,11 +90,11 @@ Table of Contents
    [RFC5234].
 
      payto-URI = "payto" "://" authority path-abempty [ "?" opts ]
-     opts = opt *( "&" opt )
+     opts = opt *( "&" opt )
      opt = (generic-opt / authority-specific-opt) "=" *( pchar )
-     generic-opt = "amount" / "creditor-name" / "debitor-name" /
+     generic-opt = "amount" / "receiver-name" / "sender-name" /
                    "message" / "instruction"
-     authority = <authority, see [RFC3986], Section 3.2>
+     authority = ALPHA *( ALPHA / DIGIT / "-" / "." )
      path-abempty = <path-abempty, see [RFC3986], Section 3.3>
      pchar = <pchar, see [RFC3986], Appendix A.>
 
@@ -92,23 +102,30 @@ Table of Contents
 3.  Semantics
 
    The authority component of a payment URI identifies the payment
-   method.  The payment methods are defined in the Payto Payment Method
-   Registry, see Section 9.  The path component of the URI identifies
-   the target account for a payment as interpreted by the respective
-   payment method.  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
-   method that can initiate a payment.  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.
+   target type.  The payment target types are defined in the "Payment
+   Target Types" registry, see Section 8.2.  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.
 
 4.  Examples
 
-     payto://sepa/CH9300762011623852957?amount=EUR:200.0&message=hello
+     payto://iban/DE75512108001245126199?amount=EUR:200.0&message=hello
 
-     INVALID (authority missing):  payto:sepa/12345
+     INVALID (authority missing):  payto:iban/12345
 
 
 5.  Generic Options
@@ -128,14 +145,14 @@ Table of Contents
      fraction = 1*(DIGIT / ",")
 
 
-   The fraction MUST be smaller than 10^8.  The unit value MUST be
-   smaller than 2^53.  The use of commas is optional for readability and
-   they MUST be ignored.
+   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.
 
-   creditor-name: Name of the entity that is credited (receives the
-   payment).
+   receiver-name: Name of the entity that receives the payment
+   (creditor).
 
-   debitor-name: Name of the entity that is debited (makes the payment).
+   sender-name: Name of the entity that makes the payment (debtor).
 
    message: A short message to identify the purpose of the payment,
    which MAY be subject to lossy conversions (for example, due to
@@ -146,7 +163,7 @@ Table of Contents
    limitations allowed for such instructions depend on the payment
    method.
 
-6.  Encoding
+6.  Internationalization and Character Encoding
 
    Various payment systems use restricted character sets.  An
    application that processes 'payto' URIs MUST convert characters that
@@ -154,16 +171,35 @@ Table of Contents
    character using either an encoding or a replacement table.  This
    conversion process MAY be lossy, except for the instruction field.
 
+   To avoid special encoding rules for the payment target identifier,
+   the userinfo component [RFC3986] is disallowed in payto URIs.
+   Instead, the payment target identifier is given as an option, where
+   encoding rules are uniform for all options.
+
 7.  Security Considerations
 
-   Applications handling the payto URI scheme MUST NOT initiate any
-   transactions without prior review and confirmation from the user.
+   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 [HMW12].
+
+   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 [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.
+
+   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.
 
 8.  IANA Considerations
 
 8.1.  URI Scheme Registration
 
-   The "payto" URI scheme is to be registered in the "Permanent URI
+   The "payto" URI scheme is already registered in the "Provisional URI
    Schemes" registry.
 
       Scheme name: payto
@@ -175,7 +211,10 @@ Table of Contents
       URI scheme semantics: See Section 3.
 
       Applications/protocols that use this scheme name: payto URIs are
-      mainly used by financial software
+      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)
 
       Contact: grothoff@gnu.org
 
@@ -183,48 +222,152 @@ Table of Contents
 
       References: See References section of this document.
 
-9.  Payto Payment Method Registry
+8.2.  Payment Target Type Registry
 
    This document defines a registry for payment methods.  The name of
-   the registry is "Payto Payment Method Registry".
+   the registry is "Payment Target Types".
 
    The registry shall record for each entry:
 
-   o  Name: The name of the payment method (case insensitive ASCII
-      string)
+   o  Name: The name of the payment target type (case insensitive ASCII
+      string, restricted to alphanumeric characters, dots and dashes)
+
+   o  Description: A description of the payment target type, including
+      the semantics of the path in the URI if applicable.
 
-   o  Description: A description of the payment method, including the
-      semantics of the path in the URI if applicable.
+   o  Example: At least one example URI to illustrate the payment target
+      type.
 
    o  Contact: The contact information of a person to contact for
       further information
 
    o  References: Optionally, references describing the payment method
-      (such as an RFC) and method-specific options
+      (such as an RFC) and method-specific options, or references
+      describing the payment system underlying the payment target type.
+
+   The registration policy for this registry is "expert review", as
+   described in [RFC5226].  The expert is appointed by the IETF
+   Indenpendent Stream Editor.  The expert's review SHOULD consider the
+   following criteria:
+
+   1.  The proposed registry entry contains all mandatory information.
+
+   2.  The description clearly defines the syntax and semantics of the
+       payment target and optional parameters if applicable.
+
+   3.  Relevant references are provided if they are available.
+
+   4.  The chosen name is appropriate for the payment target type, does
+       not conflict with well-known payment systems, and avoids
+       potential to confuse users.
+
+   5.  The payment system underlying the payment target type is not
+       fundamentally incompatible with the general options (such as
+       positive decimal amounts) in this specification.
+
+   6.  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.
+
+   7.  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.
+
+   8.  The payment target and the options do not contain the payment
+       sender's account details.
+
+8.2.1.  ACH Bank Account
+
+   o  Name: ach
+
+   o  Description: Automated Clearing House.  The path consist of two
+      components, the routing number and the account number.
+
+   o  Example: payto://ach/122000661/1234
+
+   o  Contact: N/A
+
+   o  References: [NACHA]
+
+8.2.2.  Business Identifier Code
+
+   o  Name: bic
+
+   o  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.
+
+   o  Example: payto://bic/SOGEDEFFXXX
 
-   The registration policy for this registry is "First Come First
-   Served", as described in [RFC5226].
+   o  Contact: N/A
 
-   The registry is initially populated with the following entries:
+   o  References: [BIC]
 
-   +---------+-------------------------------+----------+--------------+
-   | Name    | Description                   | Contact> | References   |
-   +---------+-------------------------------+----------+--------------+
-   | ach     | Automated Clearing House.     | N/A      | [NACHA]      |
-   |         | The path is a bank account    |          |              |
-   |         | number.                       |          |              |
-   | sepa    | Single European Payment Area. | N/A      | [ISO20022]   |
-   |         | The path is an IBAN.          |          |              |
-   | upi     | Unified Payment Interface.    | N/A      | [UPILinking] |
-   |         | The path is an account alias. |          |              |
-   | bitcoin | Bitcoin protocol. The path is | N/A      | [BIP0021]    |
-   |         | a "bitcoinaddress" as per     |          |              |
-   |         | [BIP0021].                    |          |              |
-   +---------+-------------------------------+----------+--------------+
+8.2.3.  International Bank Account Number
 
-10.  References
+   o  Name: iban
 
-10.1.  Normative References
+   o  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).
+
+   o  Example: payto://iban/DE75512108001245126199
+      payto://iban/SOGEDEFFXXX/DE75512108001245126199
+
+   o  Contact: N/A
+
+   o  References: [ISO20022]
+
+8.2.4.  Unified Payments Interface
+
+   o  Name: upi
+
+   o  Description: Unified Payment Interface.  The path is an account
+      alias.  The amount and receiver-name options are mandatory for
+      this payment target.
+
+   o  Example: payto://upi/alice@example.com?receiver-
+      name=Alice&amount=INR:200
+
+   o  Contact: N/A
+
+   o  References: [UPILinking]
+
+8.2.5.  Bitcoin Address
+
+   o  Name: bitcoin
+
+   o  Description: Bitcoin protocol.  The path is a "bitcoinaddress" as
+      per [BIP0021].
+
+   o  Example: payto://bitcoin/12A1MyfXbW6RhdRAZEqofac5jCQQjwEPBu
+
+   o  Contact: N/A
+
+   o  References: [BIP0021]
+
+8.2.6.  Interledger Protocol Address
+
+   o  Name: ilp
+
+   o  Description: Interledger protocol.  The path is an ILP address as
+      per [ILP-ADDR].
+
+   o  Example: payto://ilp/g.acme.bob
+
+   o  Contact: N/A
+
+   o  References: [ILP-ADDR]
+
+9.  References
+
+9.1.  Normative References
 
    [ISO20022]
               International Organization for Standardization, "ISO 20022
@@ -246,12 +389,29 @@ Table of Contents
    [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
               Specifications: ABNF", STD 68, RFC 5234, January 2008.
 
-10.2.  Informational References
+   [unicode-tr36]
+              Davis, M., Ed. and M. Suignard, "Unicode Technical Report
+              #36: Unicode Security Considerations", September 2014.
+
+9.2.  Informational References
+
+   [BIC]      International Organization for Standardization, "ISO
+              9362:2014 Business Identifier Code (BIC)", March 2019,
+              <https://www.iso.org/standard/60390.html>.
 
    [BIP0021]  Schneider, N. and M. Corallo, "Bitcoin Improvement
               Proposal 21", January 2012,
               <https://en.bitcoin.it/wiki/BIP_0021>.
 
+   [HMW12]    Huang, L., Moshchuk, A., Wang, H., Schecter, S., and C.
+              Jackson, "Clickjacking: Attacks and Defenses", January
+              2012, <https://www.usenix.org/system/files/conference/
+              usenixsecurity12/sec12-final39.pdf>.
+
+   [ILP-ADDR]
+              Interledger Team, "ILP Addresses - v2.0.0", September
+              2018, <https://interledger.org/rfcs/0015-ilp-addresses/>.
+
    [UPILinking]
               National Payment Corporation of India, "Unified Payment
               Interface - Common URL Specifications For Deep Linking And
@@ -262,15 +422,12 @@ Table of Contents
 Authors' Addresses
 
    Florian Dold
-   INRIA
-   Equipe TAMIS
-   INRIA Rennes Bretagne Atlantique
-   263 avenue du General Leclerc
-   Campus Universitaire de Beaulieu
-   Rennes, Bretagne  F-35042
-   FR
-
-   Email: florian.dold@inria.fr
+   Taler Systems SA
+   7, rue de Mondorf
+   Erpeldange  L-5421
+   LU
+
+   Email: dold@taler.net
 
 
    Christian Grothoff