idnits 2.17.1 draft-dold-payto-10.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 17, 2019) is 1585 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 ---------------------------------------------------------------------------- No issues found here. Summary: 0 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: June 19, 2020 BFH 6 December 17, 2019 8 The 'payto' URI scheme for payments 9 draft-dold-payto-10 11 Abstract 13 This document defines the 'payto' Uniform Resource Identifier (URI) 14 scheme for designating targets for payments. 16 A unified URI scheme for all payment target types allows applications 17 to offer user interactions with URIs that represent payment targets, 18 simplifying the introduction of new payment systems and applications. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 19, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 2. Syntax of a 'payto' URI . . . . . . . . . . . . . . . . . . . 3 58 3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Generic Options . . . . . . . . . . . . . . . . . . . . . . . 4 61 6. Internationalization and Character Encoding . . . . . . . . . 5 62 7. Tracking Payment Target Types . . . . . . . . . . . . . . . . 5 63 7.1. ACH Bank Account . . . . . . . . . . . . . . . . . . . . 6 64 7.2. Business Identifier Code . . . . . . . . . . . . . . . . 6 65 7.3. International Bank Account Number . . . . . . . . . . . . 7 66 7.4. Unified Payments Interface . . . . . . . . . . . . . . . 7 67 7.5. Bitcoin Address . . . . . . . . . . . . . . . . . . . . . 7 68 7.6. Interledger Protocol Address . . . . . . . . . . . . . . 8 69 7.7. Void Payment Target . . . . . . . . . . . . . . . . . . . 8 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 9.1. URI Scheme Registration . . . . . . . . . . . . . . . . . 9 73 9.2. Payment Target Type Registry . . . . . . . . . . . . . . 9 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 10.2. Informational References . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 This document defines the 'payto' Uniform Resource Identifier (URI) 82 [RFC3986] scheme for designating transfer form data for payments. 84 1.1. Objective 86 A 'payto' URI always identifies the target of a payment. A 'payto' 87 URI consists of a payment target type, a target identifier and 88 optional parameters such as an amount or a payment reference. 90 The interpretation of the target identifier is defined by the payment 91 target type, and typically represents either a bank account or an 92 (unsettled) transaction. 94 A unified URI scheme for all payment target types allows applications 95 to offer user interactions with URIs that represent payment targets, 96 simplifying the introduction of new payment systems and applications. 98 1.2. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 2. Syntax of a 'payto' URI 108 This document uses the Augmented Backus-Naur Form (ABNF) of 109 [RFC5234]. 111 payto-URI = "payto://" authority path-abempty [ "?" opts ] 112 opts = opt *( "&" opt ) 113 opt = (generic-opt / authority-specific-opt) "=" *pchar 114 generic-opt = "amount" / "receiver-name" / "sender-name" / 115 "message" / "instruction" 116 authority-specific-opt = ALPHA *( ALPHA / DIGIT / "-" / "." ) 117 authority = ALPHA *( ALPHA / DIGIT / "-" / "." ) 119 'path-abempty' is defined in [RFC3986] in Section 3.3. 'pchar' is 120 defined in [RFC3986], Appendix A. 122 3. Semantics 124 The authority component of a payment URI identifies the payment 125 target type. The payment target types are defined in the "Payment 126 Target Types" sub-registry, see Section 9.2. The path component of 127 the URI identifies the target for a payment as interpreted by the 128 respective payment target type. The query component of the URI can 129 provide additional parameters for a payment. Every payment target 130 type SHOULD accept the options defined in generic-opt. The default 131 operation of applications that invoke a URI with the payto scheme 132 MUST be to launch an application (if available) associated with the 133 payment target type that can initiate a payment. If multiple 134 handlers are registered for the same payment target type, the user 135 SHOULD be able to choose which application to launch. This allows 136 users with multiple bank accounts (each accessed the respective 137 bank's banking application) to choose which account to pay with. An 138 application SHOULD allow dereferencing a payto URI even if the 139 payment target type of that URI is not registered in the "Payment 140 Target Types" sub-registry. Details of the payment MUST be taken 141 from the path and options given in the URI. The user SHOULD be 142 allowed to modify these details before confirming a payment. 144 4. Examples 146 payto://iban/DE75512108001245126199?amount=EUR:200.0&message=hello 148 INVALID (authority missing): payto:iban/12345 150 5. Generic Options 152 Applications MUST accept URIs with options in any order. The 153 "amount" option MUST NOT occur more than once. Other options MAY be 154 allowed multiple times, with further restrictions depending on the 155 payment target type. The following options SHOULD be understood by 156 every payment target type. 158 amount: The amount to transfer. The format MUST be: 160 amount = currency ":" unit [ "." fraction ] 161 currency = 1*ALPHA 162 unit = 1*(DIGIT / ",") 163 fraction = 1*(DIGIT / ",") 165 If a 3-letter 'currency' is used, it MUST be an [ISO4217] alphabetic 166 code. A payment target type MAY define semantics beyond ISO 4217 for 167 currency codes that are not 3 characters. The 'unit' value MUST be 168 smaller than 2^53. If present, the 'fraction' MUST consist of no 169 more than 8 decimal digits. The use of commas is optional for 170 readability and they MUST be ignored. 172 receiver-name: Name of the entity that receives the payment 173 (creditor). 175 sender-name: Name of the entity that makes the payment (debtor). 177 message: A short message to identify the purpose of the payment, 178 which MAY be subject to lossy conversions (for example, due to 179 character set encoding limitations). 181 instruction: A short message giving instructions to the recipient, 182 which MUST NOT be subject to lossy conversions. Character set 183 limitations allowed for such instructions depend on the payment 184 target type. 186 6. Internationalization and Character Encoding 188 Various payment systems use restricted character sets. An 189 application that processes 'payto' URIs MUST convert characters that 190 are not allowed by the respective payment systems into allowable 191 character using either an encoding or a replacement table. This 192 conversion process MAY be lossy, except for the instruction field. 194 To avoid special encoding rules for the payment target identifier, 195 the userinfo component [RFC3986] is disallowed in payto URIs. 196 Instead, the payment target identifier is given as an option, where 197 encoding rules are uniform for all options. 199 7. Tracking Payment Target Types 201 A registry of Payment Target Types is described in Section 9.2. The 202 registration policy for this registry is "First Come First Served", 203 as described in [RFC8126]. When requesting new entries, careful 204 consideration of the following criteria is strongly advised: 206 1. The description clearly defines the syntax and semantics of the 207 payment target and optional parameters if applicable. 209 2. Relevant references are provided if they are available. 211 3. The chosen name is appropriate for the payment target type, does 212 not conflict with well-known payment systems, and avoids 213 potential to confuse users. 215 4. The payment system underlying the payment target type is not 216 fundamentally incompatible with the general options (such as 217 positive decimal amounts) in this specification. 219 5. The payment target type is not a vendor-specific version of a 220 payment target type that could be described more generally by a 221 vendor-neutral payment target type. 223 6. The specification of the new payment target type remains within 224 the scope of payment transfer form data. In particular 225 specifying complete invoices is not in scope. Neither are 226 processing instructions to the payment processor or bank beyond a 227 simple payment. 229 7. The payment target and the options do not contain the payment 230 sender's account details. 232 Documents that support requests for new registry entries should 233 provide the following information for each entry: 235 o Name: The name of the payment target type (case insensitive ASCII 236 string, restricted to alphanumeric characters, dots and dashes) 238 o Description: A description of the payment target type, including 239 the semantics of the path in the URI if applicable. 241 o Example: At least one example URI to illustrate the payment target 242 type. 244 o Contact: The contact information of a person to contact for 245 further information 247 o References: Optionally, references describing the payment target 248 type (such as an RFC) and target-specific options, or references 249 describing the payment system underlying the payment target type. 251 This document populates the registry with six entries as follows (see 252 also Section 9.2). 254 7.1. ACH Bank Account 256 o Name: ach 258 o Description: Automated Clearing House. The path consist of two 259 components, the routing number and the account number. 261 o Example: payto://ach/122000661/1234 263 o Contact: N/A 265 o References: [NACHA], [this.I-D] 267 7.2. Business Identifier Code 269 o Name: bic 271 o Description: Business Identifier Code. The path consist of just a 272 BIC. This is used for wire transfers between banks. The registry 273 for BICs is provided by SWIFT. The path does not allow specifying 274 a bank account number. 276 o Example: payto://bic/SOGEDEFFXXX 278 o Contact: N/A 280 o References: [BIC], [this.I-D] 282 7.3. International Bank Account Number 284 o Name: iban 286 o Description: International Bank Account Number (IBAN). Generally 287 the IBAN allows to unambiguously derive the the associated 288 Business Identifier Code (BIC). However, some legacy applications 289 process payments to the same IBAN differently based on the 290 specified BIC. Thus the path can either consist of a single 291 component (the IBAN) or two components (BIC and IBAN). 293 o Example: payto://iban/DE75512108001245126199 294 payto://iban/SOGEDEFFXXX/DE75512108001245126199 296 o Contact: N/A 298 o References: [ISO20022], [this.I-D] 300 7.4. Unified Payments Interface 302 o Name: upi 304 o Description: Unified Payment Interface. The path is an account 305 alias. The amount and receiver-name options are mandatory for 306 this payment target. 308 o Example: payto://upi/alice@example.com?receiver- 309 name=Alice&amount=INR:200 311 o Contact: N/A 313 o References: [UPILinking], [this.I-D] 315 7.5. Bitcoin Address 317 o Name: bitcoin 319 o Description: Bitcoin protocol. The path is a "bitcoinaddress" as 320 per [BIP0021]. 322 o Example: payto://bitcoin/12A1MyfXbW6RhdRAZEqofac5jCQQjwEPBu 324 o Contact: N/A 326 o References: [BIP0021], [this.I-D] 328 7.6. Interledger Protocol Address 330 o Name: ilp 332 o Description: Interledger protocol. The path is an ILP address as 333 per [ILP-ADDR]. 335 o Example: payto://ilp/g.acme.bob 337 o Contact: N/A 339 o References: [ILP-ADDR], [this.I-D] 341 7.7. Void Payment Target 343 o Name: void 345 o Description: The "void" payment target type allows specifying the 346 parameters of an out-of-band payment (such as cash or other types 347 of in-person transactions). The path is optional and interpreted 348 as a comment. 350 o Example: payto://void/?amount=EUR:10.5 352 o Contact: N/A 354 o References: [this.I-D] 356 8. Security Considerations 358 Interactive applications handling the payto URI scheme MUST NOT 359 initiate any financial transactions without prior review and 360 confirmation from the user, and MUST take measures to prevent 361 clickjacking [HMW12]. 363 Unless a payto URI is received over a trusted, authenticated channel, 364 a user might not be able to identify the target of a payment. In 365 particular due to homographs [unicode-tr36], a payment target type 366 SHOULD NOT use human-readable names in combination with unicode in 367 the target account specification, as it could give the user the 368 illusion of being able to identify the target account from the URI. 370 To avoid unnecessary data collection, payment target types SHOULD NOT 371 include personally identifying information about the sender of a 372 payment that is not essential for an application to conduct a 373 payment. 375 9. IANA Considerations 377 IANA maintains a registry called the "Uniform Resource Identifier 378 (URI) Schemes" registry. 380 9.1. URI Scheme Registration 382 IANA maintains the "Uniform Resource Identifier (URI) Schemes" 383 registry that contains an entry for the 'payto' URI scheme. IANA is 384 requested to update that entry to reference this document when 385 published as an RFC. 387 9.2. Payment Target Type Registry 389 IANA maintains the "Uniform Resource Identifier (URI) Schemes" 390 registry. IANA is requested to create a new subregistry for payment 391 methods called the "Payment Target Types" registry. 393 The subregistry shall record for each entry: 395 o Name: The name of the payment target type (case insensitive ASCII 396 string, restricted to alphanumeric characters, dots and dashes) 398 o Contact: The contact information of a person to contact for 399 further information 401 o References: Optionally, references describing the payment target 402 type (such as an RFC) and target-specific options, or references 403 describing the payment system underlying the payment target type. 405 The registration policy for this sub-registry is "First Come First 406 Served", as described in [RFC8126]. 408 IANA is requested to populate this registry as follows: 410 Name | Contact | Reference 411 ----------+-------------------------+------------ 412 ach | N/A | [This.I-D] 413 bic | N/A | [This.I-D] 414 iban | N/A | [This.I-D] 415 upi | N/A | [This.I-D] 416 bitcoin | N/A | [This.I-D] 417 ilp | N/A | [This.I-D] 418 void | N/A | [This.I-D] 420 10. References 422 10.1. Normative References 424 [ISO20022] 425 International Organization for Standardization, "ISO 20022 426 Financial Services - Universal financial industry message 427 scheme", May 2013. 429 [ISO4217] International Organization for Standardization, "ISO 4217 430 Currency Codes", August 2018. 432 [NACHA] NACHA, "NACHA Operating Rules & Guidelines", January 2017. 434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 435 Requirement Levels", BCP 14, RFC 2119, 436 DOI 10.17487/RFC2119, March 1997, 437 . 439 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 440 Resource Identifier (URI): Generic Syntax", STD 66, 441 RFC 3986, DOI 10.17487/RFC3986, January 2005, 442 . 444 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 445 Specifications: ABNF", STD 68, RFC 5234, 446 DOI 10.17487/RFC5234, January 2008, 447 . 449 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 450 Writing an IANA Considerations Section in RFCs", BCP 26, 451 RFC 8126, DOI 10.17487/RFC8126, June 2017, 452 . 454 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 455 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 456 May 2017, . 458 [unicode-tr36] 459 Davis, M., Ed. and M. Suignard, "Unicode Technical Report 460 #36: Unicode Security Considerations", September 2014. 462 10.2. Informational References 464 [BIC] International Organization for Standardization, "ISO 465 9362:2014 Business Identifier Code (BIC)", March 2019, 466 . 468 [BIP0021] Schneider, N. and M. Corallo, "Bitcoin Improvement 469 Proposal 21", January 2012, 470 . 472 [HMW12] Huang, L., Moshchuk, A., Wang, H., Schecter, S., and C. 473 Jackson, "Clickjacking: Attacks and Defenses", January 474 2012, . 477 [ILP-ADDR] 478 Interledger Team, "ILP Addresses - v2.0.0", September 479 2018, . 481 [UPILinking] 482 National Payment Corporation of India, "Unified Payment 483 Interface - Common URL Specifications For Deep Linking And 484 Proximity Integration", May 2016, 485 . 488 Authors' Addresses 490 Florian Dold 491 Taler Systems SA 492 7, rue de Mondorf 493 Erpeldange L-5421 494 LU 496 Email: dold@taler.net 498 Christian Grothoff 499 BFH 500 Hoeheweg 80 501 Biel/Bienne CH-2501 502 CH 504 Email: christian.grothoff@bfh.ch