idnits 2.17.1 draft-dold-payto-08.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 109: '... SHOULD accept the options defined i...' RFC 2119 keyword, line 111: '... SHOULD be to launch an application ...' RFC 2119 keyword, line 114: '... SHOULD be able to choose which appl...' RFC 2119 keyword, line 117: '... application SHOULD allow dereferenc...' RFC 2119 keyword, line 119: '... Details of the payment MUST be taken...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 27, 2019) is 1671 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Independent Stream F. Dold 3 Internet-Draft Taler Systems SA 4 Intended status: Informational C. Grothoff 5 Expires: March 30, 2020 BFH 6 September 27, 2019 8 The 'payto' URI scheme for payments 9 draft-dold-payto-08 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 March 30, 2020. 33 Copyright Notice 35 Copyright (c) 2019 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' URI . . . . . . . . . . . . . . . . . . . 2 52 3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 5. Generic Options . . . . . . . . . . . . . . . . . . . . . . . 3 55 6. Internationalization and Character Encoding . . . . . . . . . 4 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 8.1. URI Scheme Registration . . . . . . . . . . . . . . . . . 5 59 8.2. Payment Target Type Sub-Registry . . . . . . . . . . . . 5 60 8.2.1. ACH Bank Account . . . . . . . . . . . . . . . . . . 6 61 8.2.2. Business Identifier Code . . . . . . . . . . . . . . 7 62 8.2.3. International Bank Account Number . . . . . . . . . . 7 63 8.2.4. Unified Payments Interface . . . . . . . . . . . . . 7 64 8.2.5. Bitcoin Address . . . . . . . . . . . . . . . . . . . 8 65 8.2.6. Interledger Protocol Address . . . . . . . . . . . . 8 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 9.2. Informational References . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 This document defines the 'payto' Uniform Resource Identifier (URI) 74 [RFC3986] scheme for designating transfer form data for payments. In 75 particular, it always identifies the target of a payment. A 'payto' 76 URI consists of a payment target type, a target identifier and 77 optional parameters such as an amount or a payment reference. 79 The interpretation of the target identifier is defined by the payment 80 target type, and typically represents either a bank account or an 81 (unsettled) transaction. 83 A unified URI scheme for all payment target types allows applications 84 to offer user interactions with URIs that represent payment targets, 85 simplifying the introduction of new payment systems and applications. 87 2. Syntax of a 'payto' URI 89 This document uses the Augmented Backus-Naur Form (ABNF) of 90 [RFC5234]. 92 payto-URI = "payto" "://" authority path-abempty [ "?" opts ] 93 opts = opt *( "&" opt ) 94 opt = (generic-opt / authority-specific-opt) "=" *( pchar ) 95 generic-opt = "amount" / "receiver-name" / "sender-name" / 96 "message" / "instruction" 97 authority = ALPHA *( ALPHA / DIGIT / "-" / "." ) 98 path-abempty = 99 pchar = 101 3. Semantics 103 The authority component of a payment URI identifies the payment 104 target type. The payment target types are defined in the "Payment 105 Target Types" sub-registry, see Section 8.2. The path component of 106 the URI identifies the target for a payment as interpreted by the 107 respective payment target type. The query component of the URI can 108 provide additional parameters for a payment. Every payment method 109 SHOULD accept the options defined in generic-opt. The default 110 operation of applications that invoke a URI with the payto scheme 111 SHOULD be to launch an application (if available) associated with the 112 payment target type that can initiate a payment. If multiple 113 handlers are registered for the same payment target type, the user 114 SHOULD be able to choose which application to launch. This allows 115 users with multiple bank accounts (each accessed the respective 116 bank's banking application) to choose which account to pay with. An 117 application SHOULD allow dereferencing a payto URI even if the 118 payment target type of that URI is not registered in the "Payment 119 Target Types" sub-registry. Details of the payment MUST be taken 120 from the path and options given in the URI. The user SHOULD be 121 allowed to modify these details before confirming a payment. 123 4. Examples 125 payto://iban/DE75512108001245126199?amount=EUR:200.0&message=hello 127 INVALID (authority missing): payto:iban/12345 129 5. Generic Options 131 Applications MUST accept URIs with options in any order. The 132 "amount" option MUST only occur at most once. Other options MAY be 133 allowed multiple times, with further restrictions depending on the 134 payment method. The following options SHOULD be understood by every 135 payment method. 137 amount: The amount to transfer, including currency information if 138 applicable. The format MUST be: 140 amount = [ currency ":" ] unit [ "." fraction ] 141 currency = 1*ALPHA 142 unit = 1*(DIGIT / ",") 143 fraction = 1*(DIGIT / ",") 145 The unit value MUST be smaller than 2^53. If present, the fraction 146 MUST consist of no more than 8 decimal digits. The use of commas is 147 optional for readability and they MUST be ignored. 149 receiver-name: Name of the entity that receives the payment 150 (creditor). 152 sender-name: Name of the entity that makes the payment (debtor). 154 message: A short message to identify the purpose of the payment, 155 which MAY be subject to lossy conversions (for example, due to 156 character set encoding limitations). 158 instruction: A short message giving instructions to the recipient, 159 which MUST NOT be subject to lossy conversions. Character set 160 limitations allowed for such instructions depend on the payment 161 method. 163 6. Internationalization and Character Encoding 165 Various payment systems use restricted character sets. An 166 application that processes 'payto' URIs MUST convert characters that 167 are not allowed by the respective payment systems into allowable 168 character using either an encoding or a replacement table. This 169 conversion process MAY be lossy, except for the instruction field. 171 To avoid special encoding rules for the payment target identifier, 172 the userinfo component [RFC3986] is disallowed in payto URIs. 173 Instead, the payment target identifier is given as an option, where 174 encoding rules are uniform for all options. 176 7. Security Considerations 178 Interactive applications handling the payto URI scheme MUST NOT 179 initiate any financial transactions without prior review and 180 confirmation from the user, and MUST take measures to prevent 181 clickjacking [HMW12]. 183 Unless a payto URI is received over a trusted, authenticated channel, 184 a user might not be able to identify the target of a payment. In 185 particular due to homographs [unicode-tr36], a payment target type 186 SHOULD NOT use human-readable names in combination with unicode in 187 the target account specification, as it could give the user the 188 illusion of being able to identify the target account from the URI. 190 To avoid unnecessary data collection, payment target types SHOULD NOT 191 include personally identifying information about the sender of a 192 payment that is not essential for an application to conduct a 193 payment. 195 8. IANA Considerations 197 IANA maintains a registry called the "Uniform Resource Identifier 198 (URI) Schemes" registry. 200 8.1. URI Scheme Registration 202 IANA maintains a sub-registry of the "Uniform Resource Identifier 203 (URI) Schemes" registry also called the "Uniform Resource Identifier 204 (URI) Schemes" registry. The "payto" URI scheme is already 205 registered in this sub-registry with status set to "provisional" 206 [RFC7595]. IANA is requested to update the reference for the "payto" 207 URI scheme to reference the RFC number of this document when it is 208 published as an RFC. 210 8.2. Payment Target Type Sub-Registry 212 IANA is requested to create a new sub-registry of the "Uniform 213 Resource Identifier (URI) Schemes" registry called the "Payment 214 Target Types" registry with this document as the reference. 216 The sub-registry shall record for each entry: 218 o Name: The name of the payment target type (case insensitive ASCII 219 string, restricted to alphanumeric characters, dots and dashes) 221 o Description: A description of the payment target type, including 222 the semantics of the path in the URI if applicable. 224 o Example: At least one example URI to illustrate the payment target 225 type. 227 o Contact: The contact information of a person to contact for 228 further information 230 o References: Optionally, references describing the payment method 231 (such as an RFC) and method-specific options, or references 232 describing the payment system underlying the payment target type. 234 The registration policy for this sub-registry is "First Come First 235 Served", as described in [RFC5226]. When requesting new entries, 236 careful consideration of the following criteria is strongly advised: 238 1. The description clearly defines the syntax and semantics of the 239 payment target and optional parameters if applicable. 241 2. Relevant references are provided if they are available. 243 3. The chosen name is appropriate for the payment target type, does 244 not conflict with well-known payment systems, and avoids 245 potential to confuse users. 247 4. The payment system underlying the payment target type is not 248 fundamentally incompatible with the general options (such as 249 positive decimal amounts) in this specification. 251 5. The payment target type is not a vendor-specific version of a 252 payment target type that could be described more generally by a 253 vendor-neutral payment target type. 255 6. The specification of the new payment target type remains within 256 the scope of payment transfer form data. In particular 257 specifying complete invoices is not in scope. Neither are 258 processing instructions to the payment processor or bank beyond a 259 simple payment. 261 7. The payment target and the options do not contain the payment 262 sender's account details. 264 IANA is requested to populate the new sub-registry with the entries 265 documented in the following sub-sections. 267 8.2.1. ACH Bank Account 269 o Name: ach 271 o Description: Automated Clearing House. The path consist of two 272 components, the routing number and the account number. 274 o Example: payto://ach/122000661/1234 276 o Contact: N/A 277 o References: [NACHA], [this.I-D] 279 8.2.2. Business Identifier Code 281 o Name: bic 283 o Description: Business Identifier Code. The path consist of just a 284 BIC. This is used for wire transfers between banks. The registry 285 for BICs is provided by SWIFT. The path does not allow specifying 286 a bank account number. 288 o Example: payto://bic/SOGEDEFFXXX 290 o Contact: N/A 292 o References: [BIC], [this.I-D] 294 8.2.3. International Bank Account Number 296 o Name: iban 298 o Description: International Bank Account Number (IBAN). Generally 299 the IBAN allows to unambiguously derive the the associated 300 Business Identifier Code (BIC). However, some legacy applications 301 process payments to the same IBAN differently based on the 302 specified BIC. Thus the path can either consist of a single 303 component (the IBAN) or two components (BIC and IBAN). 305 o Example: payto://iban/DE75512108001245126199 306 payto://iban/SOGEDEFFXXX/DE75512108001245126199 308 o Contact: N/A 310 o References: [ISO20022], [this.I-D] 312 8.2.4. Unified Payments Interface 314 o Name: upi 316 o Description: Unified Payment Interface. The path is an account 317 alias. The amount and receiver-name options are mandatory for 318 this payment target. 320 o Example: payto://upi/alice@example.com?receiver- 321 name=Alice&amount=INR:200 323 o Contact: N/A 324 o References: [UPILinking], [this.I-D] 326 8.2.5. Bitcoin Address 328 o Name: bitcoin 330 o Description: Bitcoin protocol. The path is a "bitcoinaddress" as 331 per [BIP0021]. 333 o Example: payto://bitcoin/12A1MyfXbW6RhdRAZEqofac5jCQQjwEPBu 335 o Contact: N/A 337 o References: [BIP0021], [this.I-D] 339 8.2.6. Interledger Protocol Address 341 o Name: ilp 343 o Description: Interledger protocol. The path is an ILP address as 344 per [ILP-ADDR]. 346 o Example: payto://ilp/g.acme.bob 348 o Contact: N/A 350 o References: [ILP-ADDR], [this.I-D] 352 9. References 354 9.1. Normative References 356 [ISO20022] 357 International Organization for Standardization, "ISO 20022 358 Financial Services - Universal financial industry message 359 scheme", May 2013. 361 [NACHA] NACHA, "NACHA Operating Rules & Guidelines", January 2017. 363 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 364 Resource Identifier (URI): Generic Syntax", STD 66, 365 RFC 3986, DOI 10.17487/RFC3986, January 2005, 366 . 368 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 369 IANA Considerations Section in RFCs", RFC 5226, 370 DOI 10.17487/RFC5226, May 2008, 371 . 373 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 374 Specifications: ABNF", STD 68, RFC 5234, January 2008. 376 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 377 and Registration Procedures for URI Schemes", BCP 35, 378 RFC 7595, DOI 10.17487/RFC7595, June 2015, 379 . 381 [unicode-tr36] 382 Davis, M., Ed. and M. Suignard, "Unicode Technical Report 383 #36: Unicode Security Considerations", September 2014. 385 9.2. Informational References 387 [BIC] International Organization for Standardization, "ISO 388 9362:2014 Business Identifier Code (BIC)", March 2019, 389 . 391 [BIP0021] Schneider, N. and M. Corallo, "Bitcoin Improvement 392 Proposal 21", January 2012, 393 . 395 [HMW12] Huang, L., Moshchuk, A., Wang, H., Schecter, S., and C. 396 Jackson, "Clickjacking: Attacks and Defenses", January 397 2012, . 400 [ILP-ADDR] 401 Interledger Team, "ILP Addresses - v2.0.0", September 402 2018, . 404 [UPILinking] 405 National Payment Corporation of India, "Unified Payment 406 Interface - Common URL Specifications For Deep Linking And 407 Proximity Integration", May 2016, 408 . 411 Authors' Addresses 413 Florian Dold 414 Taler Systems SA 415 7, rue de Mondorf 416 Erpeldange L-5421 417 LU 419 Email: dold@taler.net 420 Christian Grothoff 421 BFH 422 Hoeheweg 80 423 Biel/Bienne CH-2501 424 CH 426 Email: christian.grothoff@bfh.ch