idnits 2.17.1 draft-dold-payto-07.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: '...ails of the payment MUST be taken from...' (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 (July 21, 2019) is 1740 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: January 22, 2020 BFH 6 July 21, 2019 8 The 'payto' URI scheme for payments 9 draft-dold-payto-07 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 January 22, 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' URL . . . . . . . . . . . . . . . . . . . 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 Registry . . . . . . . . . . . . . . 5 60 8.2.1. ACH Bank Account . . . . . . . . . . . . . . . . . . 6 61 8.2.2. Business Identifier Code . . . . . . . . . . . . . . 6 62 8.2.3. International Bank Account Number . . . . . . . . . . 7 63 8.2.4. Unified Payments Interface . . . . . . . . . . . . . 7 64 8.2.5. Bitcoin Address . . . . . . . . . . . . . . . . . . . 7 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 URL 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' URL 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" registry, see Section 8.2. The path component of the 106 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" registry. Details of the payment MUST be taken from 120 the path and options given in the URI. The user SHOULD be allowed to 121 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 URL. 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 8.1. URI Scheme Registration 199 The "payto" URI scheme is already registered in the "Provisional URI 200 Schemes" registry [RFC7595]. 202 8.2. Payment Target Type Registry 204 This document defines a registry for payment methods. The name of 205 the registry is "Payment Target Types". 207 The registry shall record for each entry: 209 o Name: The name of the payment target type (case insensitive ASCII 210 string, restricted to alphanumeric characters, dots and dashes) 212 o Description: A description of the payment target type, including 213 the semantics of the path in the URI if applicable. 215 o Example: At least one example URI to illustrate the payment target 216 type. 218 o Contact: The contact information of a person to contact for 219 further information 221 o References: Optionally, references describing the payment method 222 (such as an RFC) and method-specific options, or references 223 describing the payment system underlying the payment target type. 225 The registration policy for this registry is "First Come First 226 Served", as described in [RFC5226]. When requesting new entries, 227 careful consideration of the following criteria is strongly advised: 229 1. The description clearly defines the syntax and semantics of the 230 payment target and optional parameters if applicable. 232 2. Relevant references are provided if they are available. 234 3. The chosen name is appropriate for the payment target type, does 235 not conflict with well-known payment systems, and avoids 236 potential to confuse users. 238 4. The payment system underlying the payment target type is not 239 fundamentally incompatible with the general options (such as 240 positive decimal amounts) in this specification. 242 5. The payment target type is not a vendor-specific version of a 243 payment target type that could be described more generally by a 244 vendor-neutral payment target type. 246 6. The specification of the new payment target type remains within 247 the scope of payment transfer form data. In particular 248 specifying complete invoices is not in scope. Neither are 249 processing instructions to the payment processor or bank beyond a 250 simple payment. 252 7. The payment target and the options do not contain the payment 253 sender's account details. 255 8.2.1. ACH Bank Account 257 o Name: ach 259 o Description: Automated Clearing House. The path consist of two 260 components, the routing number and the account number. 262 o Example: payto://ach/122000661/1234 264 o Contact: N/A 266 o References: [NACHA] 268 8.2.2. Business Identifier Code 270 o Name: bic 272 o Description: Business Identifier Code. The path consist of just a 273 BIC. This is used for wire transfers between banks. The registry 274 for BICs is provided by SWIFT. The path does not allow specifying 275 a bank account number. 277 o Example: payto://bic/SOGEDEFFXXX 279 o Contact: N/A 280 o References: [BIC] 282 8.2.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] 300 8.2.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] 315 8.2.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] 328 8.2.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] 341 9. References 343 9.1. Normative References 345 [ISO20022] 346 International Organization for Standardization, "ISO 20022 347 Financial Services - Universal financial industry message 348 scheme", May 2013. 350 [NACHA] NACHA, "NACHA Operating Rules & Guidelines", January 2017. 352 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 353 Resource Identifier (URI): Generic Syntax", STD 66, 354 RFC 3986, DOI 10.17487/RFC3986, January 2005, 355 . 357 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 358 IANA Considerations Section in RFCs", RFC 5226, 359 DOI 10.17487/RFC5226, May 2008, 360 . 362 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 363 Specifications: ABNF", STD 68, RFC 5234, January 2008. 365 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 366 and Registration Procedures for URI Schemes", BCP 35, 367 RFC 7595, DOI 10.17487/RFC7595, June 2015, 368 . 370 [unicode-tr36] 371 Davis, M., Ed. and M. Suignard, "Unicode Technical Report 372 #36: Unicode Security Considerations", September 2014. 374 9.2. Informational References 376 [BIC] International Organization for Standardization, "ISO 377 9362:2014 Business Identifier Code (BIC)", March 2019, 378 . 380 [BIP0021] Schneider, N. and M. Corallo, "Bitcoin Improvement 381 Proposal 21", January 2012, 382 . 384 [HMW12] Huang, L., Moshchuk, A., Wang, H., Schecter, S., and C. 385 Jackson, "Clickjacking: Attacks and Defenses", January 386 2012, . 389 [ILP-ADDR] 390 Interledger Team, "ILP Addresses - v2.0.0", September 391 2018, . 393 [UPILinking] 394 National Payment Corporation of India, "Unified Payment 395 Interface - Common URL Specifications For Deep Linking And 396 Proximity Integration", May 2016, 397 . 400 Authors' Addresses 402 Florian Dold 403 Taler Systems SA 404 7, rue de Mondorf 405 Erpeldange L-5421 406 LU 408 Email: dold@taler.net 410 Christian Grothoff 411 BFH 412 Hoeheweg 80 413 Biel/Bienne CH-2501 414 CH 416 Email: christian.grothoff@bfh.ch