Skip to main content

The 'payto' URI Scheme for Payments
draft-dold-payto-14

Revision differences

Document history

Date Rev. By Action
2020-10-14
14 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-09-09
14 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-05-29
14 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-05-01
14 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2020-05-01
14 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2020-05-01
14 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-05-01
14 (System) RFC Editor state changed to EDIT
2020-05-01
14 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-05-01
14 (System) IANA Action state changed to In Progress
2020-05-01
14 Adrian Farrel ISE state changed to Sent to the RFC Editor from In ISE Review
2020-05-01
14 Adrian Farrel Sent request for publication to the RFC Editor
2020-05-01
14 Florian Dold New version available: draft-dold-payto-14.txt
2020-05-01
14 (System) New version approved
2020-05-01
14 (System) Request for posting confirmation emailed to previous authors: Christian Grothoff , Florian Dold
2020-05-01
14 Florian Dold Uploaded new revision
2020-04-28
13 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-04-28
13 Florian Dold New version available: draft-dold-payto-13.txt
2020-04-28
13 (System) New version approved
2020-04-28
13 (System) Request for posting confirmation emailed to previous authors: Christian Grothoff , Florian Dold
2020-04-28
13 Florian Dold Uploaded new revision
2020-04-21
12 Michelle Cotton
(Via drafts-eval-comment@iana.org): IESG/Authors/ISE:

The IANA Functions Operator has completed its review of draft-dold-payto-12. If any part of this review is inaccurate, please let us …
(Via drafts-eval-comment@iana.org): IESG/Authors/ISE:

The IANA Functions Operator has completed its review of draft-dold-payto-12. If any part of this review is inaccurate, please let us know.

We understand that when this document is sent to us for processing, we will perform
1 registry action.

Update the reference for the payto uri scheme to point to this document.

Thank you,

Michelle Cotton
Protocol Parameters Engagement Sr. Manager
IANA Services
2020-04-21
12 (System) IANA Review state changed to IANA OK - Actions Needed
2020-04-06
12 Florian Dold New version available: draft-dold-payto-12.txt
2020-04-06
12 (System) New version approved
2020-04-06
12 (System) Request for posting confirmation emailed to previous authors: Christian Grothoff , Florian Dold
2020-04-06
12 Florian Dold Uploaded new revision
2020-03-23
11 Florian Dold New version available: draft-dold-payto-11.txt
2020-03-23
11 (System) New version approved
2020-03-23
11 (System) Request for posting confirmation emailed to previous authors: Christian Grothoff , Florian Dold
2020-03-23
11 Florian Dold Uploaded new revision
2020-01-28
10 Adrian Farrel ISE state changed to In IESG Review from In ISE Review
2020-01-27
10 Adrian Farrel
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 …
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 =
    pchar =

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]


2020-01-26
10 Adrian Farrel IETF conflict review initiated - see conflict-review-dold-payto
2020-01-26
10 Adrian Farrel
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 …
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.
It is rumoured that this approach may be in use in some SWIFT work, but
no confirmation is available.

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 =
    pchar =

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]


2020-01-26
10 Adrian Farrel
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 …
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.

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 =
    pchar =

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]


2019-12-17
10 (System) Revised ID Needed tag cleared
2019-12-17
10 Florian Dold New version available: draft-dold-payto-10.txt
2019-12-17
10 (System) New version approved
2019-12-17
10 (System) Request for posting confirmation emailed to previous authors: Florian Dold , Christian Grothoff
2019-12-17
10 Florian Dold Uploaded new revision
2019-11-13
09 Adrian Farrel Tag Revised I-D Needed set.
2019-11-06
09 Adrian Farrel ISE state changed to In ISE Review from Response to Review Needed
2019-11-04
09 Florian Dold New version available: draft-dold-payto-09.txt
2019-11-04
09 (System) New version approved
2019-11-04
09 (System) Request for posting confirmation emailed to previous authors: Florian Dold , Christian Grothoff
2019-11-04
09 Florian Dold Uploaded new revision
2019-09-27
08 (System) Revised ID Needed tag cleared
2019-09-27
08 Florian Dold New version available: draft-dold-payto-08.txt
2019-09-27
08 (System) New version approved
2019-09-27
08 (System) Request for posting confirmation emailed to previous authors: Florian Dold , Christian Grothoff
2019-09-27
08 Florian Dold Uploaded new revision
2019-07-29
07 Adrian Farrel Tag Revised I-D Needed set.
2019-07-29
07 Adrian Farrel ISE state changed to Response to Review Needed from Finding Reviewers
2019-07-21
07 (System) Revised ID Needed tag cleared
2019-07-21
07 Florian Dold New version available: draft-dold-payto-07.txt
2019-07-21
07 (System) New version approved
2019-07-21
07 (System) Request for posting confirmation emailed to previous authors: Florian Dold , Christian Grothoff
2019-07-21
07 Florian Dold Uploaded new revision
2019-05-27
06 Adrian Farrel Tag Revised I-D Needed set.
2019-05-27
06 Adrian Farrel ISE state changed to Finding Reviewers
2019-05-27
06 Adrian Farrel Notification list changed to Adrian Farrel <rfc-ise@rfc-editor.org>
2019-05-27
06 Adrian Farrel Document shepherd changed to Adrian Farrel
2019-05-27
06 Adrian Farrel Intended Status changed to Informational from None
2019-05-27
06 Adrian Farrel Stream changed to ISE from None
2019-04-17
06 Florian Dold New version available: draft-dold-payto-06.txt
2019-04-17
06 (System) New version approved
2019-04-17
06 (System) Request for posting confirmation emailed to previous authors: Florian Dold , Christian Grothoff
2019-04-17
06 Florian Dold Uploaded new revision
2019-03-24
05 Florian Dold New version available: draft-dold-payto-05.txt
2019-03-24
05 (System) New version approved
2019-03-24
05 (System) Request for posting confirmation emailed to previous authors: Florian Dold , Christian Grothoff
2019-03-24
05 Florian Dold Uploaded new revision
2019-03-24
04 Aaron Falk Added to session: IETF-104: hotrfc Hot RFC Lightning Talks Sun-1800
2019-03-02
04 Florian Dold New version available: draft-dold-payto-04.txt
2019-03-02
04 (System) New version approved
2019-03-02
04 (System) Request for posting confirmation emailed to previous authors: Florian Dold , Christian Grothoff
2019-03-02
04 Florian Dold Uploaded new revision
2019-01-27
03 Florian Dold New version available: draft-dold-payto-03.txt
2019-01-27
03 (System) New version approved
2019-01-27
03 (System) Request for posting confirmation emailed to previous authors: Florian Dold , Christian Grothoff
2019-01-27
03 Florian Dold Uploaded new revision
2018-10-08
02 Florian Dold New version available: draft-dold-payto-02.txt
2018-10-08
02 (System) New version approved
2018-10-08
02 (System) Request for posting confirmation emailed to previous authors: Florian Dold , Christian Grothoff
2018-10-08
02 Florian Dold Uploaded new revision
2018-04-07
01 Florian Dold New version available: draft-dold-payto-01.txt
2018-04-07
01 (System) New version approved
2018-04-07
01 (System) Request for posting confirmation emailed to previous authors: Christian Grothoff , Florian Dold
2018-04-07
01 Florian Dold Uploaded new revision
2017-09-30
00 (System) Document has expired
2017-03-29
00 Florian Dold New version available: draft-dold-payto-00.txt
2017-03-29
00 (System) New version approved
2017-03-29
00 Florian Dold Request for posting confirmation emailed  to submitter and authors: Florian Dold , Christian Grothoff
2017-03-29
00 Florian Dold Uploaded new revision