Shepherd writeup
draft-dold-payto-14

draft-dold-payto has been presented to the ISE for publication as an
Informational RFC on the Independent Submission Stream having been
directed to the ISE by a Barry and Alexey as ADs.

The document describes a mechanism already implemented in the GNU
Taler payment system (https://docs.taler.net/) to identify bank accounts.
The PEP Project (p≡p) is using this approach in some of its SWIFT work.

Various incarnations of the document received discussion on IETF mailing
lists at:
  https://mailarchive.ietf.org/arch/msg/uri-review/YFzsOq9kbU4Lt7IV9QWwnuVzDaw
  https://mailarchive.ietf.org/arch/msg/uri-review/D_IeQiXnWzT53dCPCh13zXR6LC4
  https://mailarchive.ietf.org/arch/msg/dispatch/nERmRZ8AtDQLSo1KMW-4W6zmvFo
The authors worked to address the comments they received while maintaining
the intention of their document.

The authors also approached the IANA for advice, and Amanda Baber
provided a private response.

When this document first reached me, the authors claimed they wanted to
create "a standard", and it took some discussion to establish that this
is not possible as an RFC outside the IETF Stream. But absent any home
in the IETF for this work, they decided that publication was still
desirable.

The document originally requested substantial IANA action including the
creation of a new registry with Designated Expert Review.
- The first IANA action is to update the 'payto' URI scheme that has 
  already been allocated (for this draft) so that it points to the
  published RFC. This is not contentious.
- The more substantial IANA request was to create a subregistry under
  the 'payto' URI to record the various payment types and information
  about how they are used. This registry was to need DE review. However,
  we have managed to reduce this considerably by moving the bulk of the 
  information into normal text within the document, leaving the new 
  registry to just record the names of the payment types and a pointer
  to the document that defines the payment types. This new registry is
  defined as FCFS with advice to people requesting allocatons being
  given in the main body of text in this document. Such a dependent
  subregistry with FCFS policy fits within the ISE's IANA procedures.

Starting with -06 for which publication was requested, we have had 
several review cycles resulting in us reaching -10. Reviews were 
received from:
- Anders Rundgren
- Matthias Heckmann
- me as ISE
Reviews were declined by Bruce Nikkel and Cedric Humbert stating that
they thought the idea reasonable, but the approach too simplistic.

The authors debated the reviews for some time and made some 
modifications to the draft.

The work was also discussed with Graham Kline as Designated Expert for
the URI Schemes registry and Barry as AD.

The authors have confirmed that there is no IPR to be disclosed.

== Anders Rundgren ==

Since I tinker with stuff in this space I can provide a quick review.
I've included the authors as well because there are some rather
fundamental issues involved.  I stick to high-level items here.

If I'm completely off here, please correct me. Nobody is infallible.

Use case
--------
What I lack is a one complete use case based on existing and if
needed updated user agents (email, OS, browsers).  The latter is
quite important since any such requirement is a major blocker.
Been there, done that [1,2,3] :(

Existing Payto solutions
------------------------
The ability to send somebody a "Pay Me" request is supported by
lots of systems (including PayPal) but have one thing in common:
they provide a secure environment where both the requester (Payee)
and Payer are *authenticated*. Since PayPal et al are closed eco-
systems they use proprietary solutions for achieving this
functionality.  Due to that they would not gain anything by a
standard *since they security-wise anyway are non-interoperable*.
https://www.paypal.me/

Payto Security
--------------
So one question is if payto is about creating an OPEN solution?
I don't see how you can do that without also creating a security
solution like requiring payto URIs to be signed.  Sending unsecured
payto URIs by email or SMS is something I wouldn't recommend while
sending notification URIs which in turn forces you to login into a
secure environment appears to be the current de-facto standard.

W3C
---
I've been involved from the start (as a lurker/critic) in W3C's
https://www.w3.org/TR/payment-request/ .  Although I'm not overly
impressed with the API, it is anyway implemented in Chrome and used
by at least Google Pay.  I believe this is a "challenger" to payto
that will be very difficult to beat.  In fact, I hope to replace
the UI- and security-wise inferior Android URLhandler scheme
currently used by Saturn [4] with W3C's PaymentRequest.

My conclusion FWIW is that the outlook for payto in its current
incarnation looks pretty grim.

== Matthias Heckmann ==

## Review

The draft seems to cover all aspects/information needed for 'payto' handlers to
initiate the transaction(s) as intended. The standard is flexible enough to support
a extensible range of payment methods. The standard includes very important
security/privacy aspects. Applications handling the payto URI scheme are forbidden
to execute any transaction without the review and approval of the user. The URI
should not include any personal data which isnt ultimately required to describe the
payment. Syntax of a 'payto' URI seems to be syntactically correct and makes sense
using the semantics provided.
There seem to be no fundamental  shortcomings or obvious problems with the draft.
From my perspective the draft seems to describe a concept which fits the purpose and
is neither to narrow nor too loose for a good starting point. 
IMO, there is one major weakness, which is that the currencies are not linked to a
standardized currency table e.g ISO 4217, which could lead to ambiguity.
All other suggestions are very minor. Please see all suggestions below.  
Please consider this whole review as very unauthoritative and as a best effort for
contribution.
 

### Suggestions
* Currencies possibly ambiguous, maybe would make sense to link them to e.g. the 
ISO 4217 alphabetic code.

* Authority-specific-opts are undefined, would it be better to constrain them as far
as possible, or do they need to be 100% flexible?

* 2.  Syntax of a 'payto' URI 
  * I checked the ABNF using Bill's ABNF parser, which suggest:
  * "payto://" insead of "payto" "://"
  * \*pchar instead of \*(pchar)
  * authority-specific-opt UNDEFINED

* Section 3. Semantics
  * Would it make sense to have more binding conventions using MUST instead of SHOULD?

* Terminology, disambiguation:
  * Poss. redundancy e.g: authority / payment method / payment target type
  * Reduce and unify terminology advantageous?

* RFC 2119 recommends to include
  * The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.

== ISE == 

Abstract

I think it would be helpful to include a copy of the final paragraph from
the introduction:

   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.

---

You use "MUST" etc., so you need...

1.2.  Requirements Language

   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.

---

Section 2

     path-abempty = <path-abempty, see [RFC3986], Section 3.3>
     pchar = <pchar, see [RFC3986], Appendix A.>

I am not a URI expert in any sense, but these two lines don't look right
to me. Should the reference be outside the angle brackets? And if they
are intended to be inside the angle brackets, should you not use square
brackets around the RFC numbers because outside the context of this
document, the citation would not be valid.

---

5.

OLD
   The "amount" option MUST only occur at most once.
NEW
   The "amount" option MUST occur at most once.
END

Although I prefer
   The "amount" option MUST NOT occur more than once.

---

5.

I see
     currency = 1*ALPHA
but I don't find the semantic of the field. If I want to indicate a
currency, how to I know how to set this field?

---

8.1

OLD
   The "payto" URI scheme is already registered in the "Provisional URI
   Schemes" registry [RFC7595].
NEW
   IANA maintains the "Uniform Resource Identifier (URI) Schemes"
   registry that contains an entry for the "payto" URI scheme.  IANA is
   requested to update that entry to reference this document when
   published as an RFC.
END

---

8.2

OLD
   This document defines a registry for payment methods.  The name of
   the registry is "Payment Target Types".
NEW
   IANA maintains the "Uniform Resource Identifier (URI) Schemes"
   registry.  IANA is requested to create a new subregsitry for
   payment methods called the "Payment Target Types" registry.
END

---

8.2

   The registration policy for this registry is "First Come First
   Served", as described in [RFC5226].

Should be RFC 8126

---

8.2

We need to separate the minimalist instructions to IANA and the basic
information that belongs in the registry, from the details of how to
use the registry and the codepoints it defines. The registry is intended
to be a simple log of the codepoints with references. All further
details belong in the referenced documents.

Thus, this section should reduce to the following. (See later note about
what to do with the other material.)

8.2.  Payment Target Type Registry

   IANA maintains the "Uniform Resource Identifier (URI) Schemes"
   registry.  IANA is requested to create a new subregistry for
   payment methods called the "Payment Target Types" registry.

   The registry shall record for each entry:

   o  Name
   o  Contact
   o  Reference

   The registration policy for this registry is "First Come First
   Served", as described in [RFC8126].

   IANA is requested to populate this registry as follows:

   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]

---

Now you need somewhere to put all of the other material extracted from
8.2.  I suggest you create a new section immediately before the Security
Considerations, as follows:

X. Tracking Payto URIs

   A registry of Payto URIs is described in Section 8.

   The registration policy for this registry is "First Come First
   Served", as described in [RFC8126].  When requesting new entries in
   the registry, careful consideration of the following criteria is
   strongly advised:

   1.  The description clearly defines the syntax and semantics of the
       payment target and optional parameters if applicable.

   2.  Relevant references are provided if they are available.

   3.  The chosen name is appropriate for the payment target type, does
       not conflict with well-known payment systems, and avoids
       potential to confuse users.

   4.  The payment system underlying the payment target type is not
       fundamentally incompatible with the general options (such as
       positive decimal amounts) in this specification.

   5.  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.

   6.  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.

   7.  The payment target and the options do not contain the payment
       sender's account details.

   Documents that support requests for new registry entries should
   provide the following information for each entry:

   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  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, or references
      describing the payment system underlying the payment target type.

   This document populates the registry with six entries as follows (see
   also Section 8.2).

   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]

   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

   o  Contact: N/A

   o  References: [BIC]

   International Bank Account Number

   o  Name: iban

   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]

   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]

   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]

   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]


Back