idnits 2.17.1 draft-dold-payto-04.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 108: '... SHOULD accept the options defined i...' RFC 2119 keyword, line 110: '... SHOULD be to launch an application ...' RFC 2119 keyword, line 113: '... SHOULD be able to choose which appl...' RFC 2119 keyword, line 116: '...s of the payment MUST be taken from th...' RFC 2119 keyword, line 117: '...e URI. The user SHOULD be allowed to ...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 03, 2019) is 1881 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 Internet Engineering Task Force F. Dold 3 Internet-Draft Taler Systems SA 4 Intended status: Informational C. Grothoff 5 Expires: September 4, 2019 BFH 6 March 03, 2019 8 The 'payto' URI scheme for payments 9 draft-dold-payto-04 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 September 4, 2019. 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. International Bank Account Number . . . . . . . . . . 6 62 8.2.3. Unified Payments Interface . . . . . . . . . . . . . 6 63 8.2.4. Bitcoin Address . . . . . . . . . . . . . . . . . . . 7 64 8.2.5. Interledger Protocol Address . . . . . . . . . . . . 7 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 9.2. Informational References . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 This document defines the 'payto' Uniform Resource Identifier (URI) 73 [RFC3986] scheme for designating targets for payments. In its 74 simplest form, a 'payto' URL identifies a payment target type and 75 optionally a target identifier. Additional parameters, such as an 76 amount or a payment reference, can be provided. 78 The interpretation of the target identifier is defined by the payment 79 target type, and typically represents either a bank account or an 80 (unsettled) transaction. 82 A unified URI scheme for all payment target types allows applications 83 to offer user interactions with URIs that represent payment targets, 84 without delay and churn when new payment systems are introduced. 86 2. Syntax of a 'payto' URL 88 This document uses the Augmented Backus-Naur Form (ABNF) of 89 [RFC5234]. 91 payto-URI = "payto" "://" authority path-abempty [ "?" opts ] 92 opts = opt *( "&" opt ) 93 opt = (generic-opt / authority-specific-opt) "=" *( pchar ) 94 generic-opt = "amount" / "creditor-name" / "debitor-name" / 95 "message" / "instruction" 96 authority = ALPHA *( ALPHA / DIGIT / "-" / "." ) 97 path-abempty = 98 pchar = 100 3. Semantics 102 The authority component of a payment URI identifies the payment 103 target type. The payment target types are defined in the Payto 104 Payment Target Type Registry, see Section 8.2. The path component of 105 the URI identifies the target for a payment as interpreted by the 106 respective payment target type. The query component of the URI can 107 provide additional parameters for a payment. Every payment method 108 SHOULD accept the options defined in generic-opt. The default 109 operation of applications that invoke a URI with the payto scheme 110 SHOULD be to launch an application (if available) associated with the 111 payment target type that can initiate a payment. If multiple 112 handlers are registered for the same payment target type, the user 113 SHOULD be able to choose which application to launch. This allows 114 users with multiple bank accounts (each accessed the respective 115 bank's banking application) to choose which account to pay with. 116 Details of the payment MUST be taken from the path and options given 117 in the URI. The user SHOULD be allowed to modify these details 118 before confirming a payment. 120 4. Examples 122 payto://sepa/CH9300762011623852957?amount=EUR:200.0&message=hello 124 INVALID (authority missing): payto:sepa/12345 126 5. Generic Options 128 Applications MUST accept URIs with options in any order. The 129 "amount" option MUST only occur at most once. Other options MAY be 130 allowed multiple times, with further restrictions depending on the 131 payment method. The following options SHOULD be understood by every 132 payment method. 134 amount: The amount to transfer, including currency information if 135 applicable. The format MUST be: 137 amount = [ currency ":" ] unit [ "." fraction ] 138 currency = 1*ALPHA 139 unit = 1*(DIGIT / ",") 140 fraction = 1*(DIGIT / ",") 142 The unit value MUST be smaller than 2^53. If present, the fraction 143 MUST consist of no more than 8 decimal digits. The use of commas is 144 optional for readability and they MUST be ignored. 146 creditor-name: Name of the entity that is credited (receives the 147 payment). 149 debitor-name: Name of the entity that is debited (makes the payment). 151 message: A short message to identify the purpose of the payment, 152 which MAY be subject to lossy conversions (for example, due to 153 character set encoding limitations). 155 instruction: A short message giving instructions to the recipient, 156 which MUST NOT be subject to lossy conversions. Character set 157 limitations allowed for such instructions depend on the payment 158 method. 160 6. Internationalization and Character Encoding 162 Various payment systems use restricted character sets. An 163 application that processes 'payto' URIs MUST convert characters that 164 are not allowed by the respective payment systems into allowable 165 character using either an encoding or a replacement table. This 166 conversion process MAY be lossy, except for the instruction field. 168 To avoid special encoding rules for the payment target identifier, 169 the userinfo component [RFC3986] is disallowed in payto URIs. 170 Instead, the payment target identifier is given as an option, where 171 encoding rules are uniform for all options. 173 7. Security Considerations 175 Interactive applications handling the payto URI scheme MUST NOT 176 initiate any financial transactions without prior review and 177 confirmation from the user, and MUST take measures to prevent 178 clickjacking [HMW12]. 180 Unless a payto URI is received over a trusted, authenticated channel, 181 a user might not be able to identify the target of a payment. In 182 particular due to homographs [unicode-tr36], a payment target type 183 SHOULD NOT use human-readable names in combination with unicode in 184 the target account specification, as it could give the user the 185 illusion of being able to identify the target account from the URL. 187 To avoid unnecessary data collection, payment target types SHOULD NOT 188 include personally identifying information about the sender of a 189 payment that is not essential for an application to conduct a 190 payment. 192 8. IANA Considerations 194 8.1. URI Scheme Registration 196 The "payto" URI scheme is to be registered in the "Permanent URI 197 Schemes" registry. 199 Scheme name: payto 201 Status: permanent 203 URI scheme syntax: See Section 2. 205 URI scheme semantics: See Section 3. 207 Applications/protocols that use this scheme name: payto URIs are 208 mainly used by financial software, as well as by interactive 209 applications (e.g. email clients, chat applications) that detect 210 payto URIs and allow the user to interact with them (e.g. make 211 them clickable) 213 Contact: grothoff@gnu.org 215 Change controller: grothoff@gnu.org 217 References: See References section of this document. 219 8.2. Payment Target Type Registry 221 This document defines a registry for payment methods. The name of 222 the registry is "Payment Target Type Registry". 224 The registry shall record for each entry: 226 o Name: The name of the payment target type (case insensitive ASCII 227 string, restricted to alphanumeric characters, dots and dashes) 229 o Description: A description of the payment target type, including 230 the semantics of the path in the URI if applicable. 232 o Example: Example URI to illustrate the payment target type. 234 o Contact: The contact information of a person to contact for 235 further information 237 o References: Optionally, references describing the payment method 238 (such as an RFC) and method-specific options 240 The registration policy for this registry is "First Come First 241 Served", as described in [RFC5226]. 243 8.2.1. ACH Bank Account 245 o Name: ach 247 o Description: Automated Clearing House. The path consist of two 248 components, the routing number and the account number. 250 o Example: payto://ach/122000661/1234 252 o Contact: N/A 254 o References: [NACHA] 256 8.2.2. International Bank Account Number 258 o Name: iban 260 o Description: International Bank Account Number (IBAN). Generally 261 the IBAN allows to unambiguously derive the the associated BIC 262 (Bank Identifier Code). However, some legacy applications process 263 payments to the same IBAN differently based on the specified BIC. 264 Thus the path can either consist of a single component (the IBAN) 265 or two components (BIC and IBAN). 267 o Example: payto://iban/DE75512108001245126199 268 payto://iban/SOGEDEFFXXX/DE75512108001245126199 270 o Contact: N/A 272 o References: [ISO20022] 274 8.2.3. Unified Payments Interface 276 o Name: upi 277 o Description: Unified Payment Interface. The path is an account 278 alias. The amount and creditor-name options are mandatory for 279 this payment target. 281 o Example: payto://upi/alice@example.com?creditor- 282 name=Alice&amount=INR:200 284 o Contact: N/A 286 o References: [UPILinking] 288 8.2.4. Bitcoin Address 290 o Name: bitcoin 292 o Description: Bitcoin protocol. The path is a "bitcoinaddress" as 293 per [BIP0021]. 295 o Example: payto://bitcoin/12A1MyfXbW6RhdRAZEqofac5jCQQjwEPBu 297 o Contact: N/A 299 o References: [BIP0021] 301 8.2.5. Interledger Protocol Address 303 o Name: ilp 305 o Description: Interledger protocol. The path is an ILP address as 306 per [ILP-ADDR]. 308 o Example: payto://ilp/g.acme.bob 310 o Contact: N/A 312 o References: [ILP-ADDR] 314 9. References 316 9.1. Normative References 318 [ISO20022] 319 International Organization for Standardization, "ISO 20022 320 Financial Services - Universal financial industry message 321 scheme", May 2013. 323 [NACHA] NACHA, "NACHA Operating Rules & Guidelines", January 2017. 325 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 326 Resource Identifier (URI): Generic Syntax", STD 66, 327 RFC 3986, DOI 10.17487/RFC3986, January 2005, 328 . 330 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 331 IANA Considerations Section in RFCs", RFC 5226, 332 DOI 10.17487/RFC5226, May 2008, 333 . 335 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 336 Specifications: ABNF", STD 68, RFC 5234, January 2008. 338 [unicode-tr36] 339 Davis, M., Ed. and M. Suignard, "Unicode Technical Report 340 #36: Unicode Security Considerations", September 2014. 342 9.2. Informational References 344 [BIP0021] Schneider, N. and M. Corallo, "Bitcoin Improvement 345 Proposal 21", January 2012, 346 . 348 [HMW12] Huang, L., Moshchuk, A., Wang, H., Schecter, S., and C. 349 Jackson, "Clickjacking: Attacks and Defenses", January 350 2012, . 353 [ILP-ADDR] 354 Interledger Team, "ILP Addresses - v2.0.0", September 355 2018, . 357 [UPILinking] 358 National Payment Corporation of India, "Unified Payment 359 Interface - Common URL Specifications For Deep Linking And 360 Proximity Integration", May 2016, 361 . 364 Authors' Addresses 366 Florian Dold 367 Taler Systems SA 368 7, rue de Mondorf 369 Erpeldange L-5421 370 LU 372 Email: dold@taler.net 373 Christian Grothoff 374 BFH 375 Hoeheweg 80 376 Biel/Bienne CH-2501 377 CH 379 Email: christian.grothoff@bfh.ch