idnits 2.17.1 draft-dold-payto-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 99: '... SHOULD accept the options defined i...' RFC 2119 keyword, line 101: '... SHOULD be to launch an application ...' RFC 2119 keyword, line 104: '... SHOULD be able to choose which appl...' RFC 2119 keyword, line 107: '...s of the payment MUST be taken from th...' RFC 2119 keyword, line 108: '...e URI. The user SHOULD be allowed to ...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 8, 2018) is 2020 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force F. Dold 3 Internet-Draft INRIA 4 Intended status: Informational C. Grothoff 5 Expires: April 11, 2019 BFH 6 October 8, 2018 8 The 'payto' URI scheme for payments 9 draft-dold-payto-02 11 Abstract 13 This document defines the 'payto' Uniform Resource Identifier (URI) 14 scheme for designating targets for payments. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 11, 2019. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Syntax of a 'payto' URL . . . . . . . . . . . . . . . . . . . 2 52 3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 5. Generic Options . . . . . . . . . . . . . . . . . . . . . . . 3 55 6. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 8.1. URI Scheme Registration . . . . . . . . . . . . . . . . . 4 59 9. Payto Payment Method Registry . . . . . . . . . . . . . . . . 5 60 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 62 10.2. Informational References . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 This document defines the 'payto' Uniform Resource Identifier (URI) 68 [RFC3986] scheme for designating targets for payments. In its 69 simplest form, a 'payto' URL identifies a payment target type and 70 optionally a target identifier. Additional parameters, such as an 71 amount or a payment reference, can be provided. 73 The interpretation of the target identifier is defined by the payment 74 target type, and typically represents either a bank account or an 75 (unsettled) transaction. 77 2. Syntax of a 'payto' URL 79 This document uses the Augmented Backus-Naur Form (ABNF) of 80 [RFC5234]. 82 payto-URI = "payto" "://" authority path-abempty [ "?" opts ] 83 opts = opt *( "&" opt ) 84 opt = (generic-opt / authority-specific-opt) "=" *( pchar ) 85 generic-opt = "amount" / "creditor-name" / "debitor-name" / 86 "message" / "instruction" 87 authority = 88 path-abempty = 89 pchar = 91 3. Semantics 93 The authority component of a payment URI identifies the payment 94 target type. The payment target types are defined in the Payto 95 Payment Target Type Registry, see Section 9. The path component of 96 the URI identifies the target for a payment as interpreted by the 97 respective payment target type. The query component of the URI can 98 provide additional parameters for a payment. Every payment method 99 SHOULD accept the options defined in generic-opt. The default 100 operation of applications that invoke a URI with the payto scheme 101 SHOULD be to launch an application (if available) associated with the 102 payment target type that can initiate a payment. If multiple 103 handlers are registered for the same payment target type, the user 104 SHOULD be able to choose which application to launch. This allows 105 users with multiple bank accounts (each accessed the respective 106 bank's banking application) to choose which account to pay with. 107 Details of the payment MUST be taken from the path and options given 108 in the URI. The user SHOULD be allowed to modify these details 109 before confirming a payment. 111 4. Examples 113 payto://sepa/CH9300762011623852957?amount=EUR:200.0&message=hello 115 INVALID (authority missing): payto:sepa/12345 117 5. Generic Options 119 Applications MUST accept URIs with options in any order. The 120 "amount" option MUST only occur at most once. Other options MAY be 121 allowed multiple times, with further restrictions depending on the 122 payment method. The following options SHOULD be understood by every 123 payment method. 125 amount: The amount to transfer, including currency information if 126 applicable. The format MUST be: 128 amount = [ currency ":" ] unit [ "." fraction ] 129 currency = 1*ALPHA 130 unit = 1*(DIGIT / ",") 131 fraction = 1*(DIGIT / ",") 133 The fraction MUST be smaller than 10^8. The unit value MUST be 134 smaller than 2^53. The use of commas is optional for readability and 135 they MUST be ignored. 137 creditor-name: Name of the entity that is credited (receives the 138 payment). 140 debitor-name: Name of the entity that is debited (makes the payment). 142 message: A short message to identify the purpose of the payment, 143 which MAY be subject to lossy conversions (for example, due to 144 character set encoding limitations). 146 instruction: A short message giving instructions to the recipient, 147 which MUST NOT be subject to lossy conversions. Character set 148 limitations allowed for such instructions depend on the payment 149 method. 151 6. Encoding 153 Various payment systems use restricted character sets. An 154 application that processes 'payto' URIs MUST convert characters that 155 are not allowed by the respective payment systems into allowable 156 character using either an encoding or a replacement table. This 157 conversion process MAY be lossy, except for the instruction field. 159 7. Security Considerations 161 Applications handling the payto URI scheme MUST NOT initiate any 162 financial transactions without prior review and confirmation from the 163 user, and MUST take measures to prevent clickjacking [HMW12]. 165 8. IANA Considerations 167 8.1. URI Scheme Registration 169 The "payto" URI scheme is to be registered in the "Permanent URI 170 Schemes" registry. 172 Scheme name: payto 174 Status: permanent 176 URI scheme syntax: See Section 2. 178 URI scheme semantics: See Section 3. 180 Applications/protocols that use this scheme name: payto URIs are 181 mainly used by financial software 183 Contact: grothoff@gnu.org 184 Change controller: grothoff@gnu.org 186 References: See References section of this document. 188 9. Payto Payment Method Registry 190 This document defines a registry for payment methods. The name of 191 the registry is "Payto Payment Target Type Registry". 193 The registry shall record for each entry: 195 o Name: The name of the payment target type (case insensitive ASCII 196 string) 198 o Description: A description of the payment target type, including 199 the semantics of the path in the URI if applicable. 201 o Contact: The contact information of a person to contact for 202 further information 204 o References: Optionally, references describing the payment method 205 (such as an RFC) and method-specific options 207 The registration policy for this registry is "First Come First 208 Served", as described in [RFC5226]. 210 The registry is initially populated with the following entries: 212 +---------+-------------------------------+----------+--------------+ 213 | Name | Description | Contact> | References | 214 +---------+-------------------------------+----------+--------------+ 215 | ach | Automated Clearing House. | N/A | [NACHA] | 216 | | The path is a bank account | | | 217 | | number. | | | 218 | sepa | Single European Payment Area. | N/A | [ISO20022] | 219 | | The path is an IBAN. | | | 220 | upi | Unified Payment Interface. | N/A | [UPILinking] | 221 | | The path is an account alias. | | | 222 | bitcoin | Bitcoin protocol. The path is | N/A | [BIP0021] | 223 | | a "bitcoinaddress" as per | | | 224 | | [BIP0021]. | | | 225 | ilp | Interledger protocol. The | N/A | [ILP-ADDR] | 226 | | path is an ILP address as per | | | 227 | | [ILP-ADDR]. | | | 228 +---------+-------------------------------+----------+--------------+ 230 10. References 232 10.1. Normative References 234 [ISO20022] 235 International Organization for Standardization, "ISO 20022 236 Financial Services - Universal financial industry message 237 scheme", May 2013. 239 [NACHA] NACHA, "NACHA Operating Rules & Guidelines", January 2017. 241 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 242 Resource Identifier (URI): Generic Syntax", STD 66, 243 RFC 3986, DOI 10.17487/RFC3986, January 2005, 244 . 246 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 247 IANA Considerations Section in RFCs", RFC 5226, 248 DOI 10.17487/RFC5226, May 2008, 249 . 251 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 252 Specifications: ABNF", STD 68, RFC 5234, January 2008. 254 10.2. Informational References 256 [BIP0021] Schneider, N. and M. Corallo, "Bitcoin Improvement 257 Proposal 21", January 2012, 258 . 260 [HMW12] Huang, L., Moshchuk, A., Wang, H., Schecter, S., and C. 261 Jackson, "Clickjacking: Attacks and Defenses", January 262 2012, . 265 [ILP-ADDR] 266 Interledger Team, "ILP Addresses - v2.0.0", September 267 2018, . 269 [UPILinking] 270 National Payment Corporation of India, "Unified Payment 271 Interface - Common URL Specifications For Deep Linking And 272 Proximity Integration", May 2016, 273 . 276 Authors' Addresses 278 Florian Dold 279 INRIA 280 Equipe TAMIS 281 INRIA Rennes Bretagne Atlantique 282 263 avenue du General Leclerc 283 Campus Universitaire de Beaulieu 284 Rennes, Bretagne F-35042 285 FR 287 Email: florian@dold.me 289 Christian Grothoff 290 BFH 291 Hoeheweg 80 292 Biel/Bienne CH-2501 293 CH 295 Email: christian.grothoff@bfh.ch