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 |