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/YFzsOq9kbU4Lt7IV9QWwnuVzDawhttps://mailarchive.ietf.org/arch/msg/uri-review/D_IeQiXnWzT53dCPCh13zXR6LC4https://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]