idnits 2.17.1 draft-khare-jepi-uppflow-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Missing revision: the document name given in the document, 'draft-khare-jepi-uppflow', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-khare-jepi-uppflow', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-khare-jepi-uppflow', but the file name used is 'draft-khare-jepi-uppflow-00' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 513 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 48 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 145 has weird spacing: '...related to th...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 16, 1996) is 10114 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 9 errors (**), 1 flaw (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Joint Electronic Payments Initiative 2 World Wide Web Consortium 3 CommerceNet 4 Expires: February 1, 1997 August 16, 1996 6 SELECTING PAYMENT MECHANISMS OVER HTTP 7 Or, Seven Examples of UPP Over PEP (as used in JEPI) 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as "work in progress". 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. Please send comments to 28 the JEPI working group care of Jim Miller, W3C (jmiller@w3.org), Rohit 29 Khare (khare@w3.org), or Don Eastlake (dee@cybercash.com). This draft 30 is also available formatted as HTML at 31 http://www.w3.org/pub/WWW/Payments/JEPI/draft-jepi-uppflow 33 NOTE: This memo does not reflect the work of any current IETF Working 34 Groups. Discussion of this draft is intended to support the eventual 35 release of an IETF specification of the Universal Payment Preamble 36 (UPP) and the development of an HTTP Extension Protocol (PEP) in the 37 HTTP WG. 39 1. Abstract 41 The Joint Electronics Payment Initiative aims to bring key industry 42 players together to assure that multiple payment protocols can operate 43 effectively in Web applications. The concrete goal is automatable 44 payment selection over HTTP. 46 The first step towards this was Don Eastlake's development of the 47 Universal Payment Preamble, which is also available as an 48 internet-draft (draft-eastlake-universal-payment). The second is the 49 development of an HTTP Extension Protocol to embed UPP in HTTP. The 50 latter proposal is part of the chartered activities of the IETF HTTP 51 WG (draft-ietf-http-pep-03). 53 This document describes how to use UPP over PEP to support payment 54 selection between clients and merchants. It explains basic operations: 55 requesting available payment choices, presenting multiple choices, 56 demanding a selection, making a selection, and accepting and rejecting 57 choices. 59 2. Introduction 61 The JEPI project is using PEP as a vehicle for negotiating over 62 payment mechanism between a Web client and server. In order to 63 accomplish this, JEPI has adopted the Universal Payment Preamble (UPP) 64 proposed by Donald Eastlake as a particular protocol to be used over 65 PEP. This document describes a set of seven fundamental operations 66 that support payment mechanism negotiation, and shows how to use PEP 67 and UPP to accomplish each. In addition, it contains comments intended 68 for the implementation team for JEPI indicating the subset which are 69 actually needed for the JEPI demonstration. 71 2.1 THE SEVEN FUNDAMENTAL OPERATIONS OF PAYMENT MECHANISM NEGOTIATION 73 1. Request payment choices. Either end (client or server) should be 74 able to ask the other what forms of payment it supports. JEPI 75 implementors: In the demo, only the server will generate these 76 requests. 78 2. Present payment choices that it supports. Either end should be 79 able to list the forms of payment it supports. Notice that this 80 may not be a complete list, but rather a list of options that it 81 "prefers" at the current moment. This list may be presented in 82 response to a request (operation 1) or spontaneously. The latter 83 behavior is analogous to the use of "logo stickers" on a store 84 window or cash register. JEPI implementors: the demo will only 85 require this operation in response to a specific request. 87 3. Demand payment choice. The merchant (server) may demand that the 88 client choose a specific form of payment to be used to pay for 89 items. JEPI implementors: In the demo, this happens when the 90 "invoice page" is sent from the server to the client; the demand 91 indicates what components of the page will require a response with 92 payment choice (operation 4). 94 4. Make a payment choice. The cuustomer (client) can indicate the 95 payment method to be used to make a payment. This normally 96 indicates to the server that payment should actually begin, and 97 the response will either be to accept (operation 5) or reject 98 (operation 6) the chosen mechanism. 100 5. Accept a payment choice. The server, in response to a payment 101 choice (operation 4), may accept the choice and initiate an actual 102 payment operation. The payment operation itself is not part of the 103 JEPI project and may or may not use PEP to handle the payment. 105 6. Reject a payment choice. The server, in response to a payment 106 choice (operation 4), may reject the choice and request that 107 another choice be made. UPP specifies that a rejection can occur 108 either because the user canceled the transaction prior to 109 completion or because the transaction failed for other 110 (payment-system specific) reasons. They are distinguished and can 111 result in different client actions. 113 7. Do you accept payment by X? Either side can ask the other if it 114 supports payment by a particular payment mechanism. JEPI 115 implementors: This is not currently required for the 116 demonstration, but it might be a useful addition for the client to 117 ask the server this question prior to counter-offering with a 118 payment mechanism not mentioned by the server in its list of 119 supported mechanisms (operation 2). 121 3. Notation 123 Amongst other things, UPP provides a uniform vocabulary for naming 124 options common to many payment systems, and a uniform syntax for each 125 such option. It is not clear at the current time what mechanism should 126 be used to allow independent payment system designers to name options 127 so that they will not collide with the UPP namespace of shared 128 options. We will use sub-bags to separate the name spaces. That is, we 129 will assume that a bag of the form {upp {upp-parameter-name 130 upp-parameter-value} ... } will be used to hold these parameters. A 131 complete list of these common parameters and their syntax is available 132 in the UPP specification. 134 In a complete implementation of UPP using PEP, it would be possible to 135 specify these common parameters in the PEP-specified header fields 136 Protocol:, Protocol-Request:, Protocol-Query:, and Protocol-Info: as 137 well as in any payment-system specific headers. In the JEPI 138 demonstration, however, we will not be using these parameters for the 139 generic UPP protocol (they may be used in payment-specific protocols). 140 In this document we will indicate where they are syntactically 141 permitted by using the notation "upp-params." For the demonstration, 142 these will always be omitted in the examples shown here. 144 For clarity, we omit all of the HTTP headers and message body with the 145 exception of those parts directly related to the operation being 146 demonstrated. The protocol-name URLs shown here are purely for 147 example, and will be determined by the participants at a later date. 148 The URLs for the various for lists will be determined by each merchant 149 application. Because we do not expect proxy servers to participate in 150 the payment negotiation shown during the JEPI demo, the scope 151 parameters of all PEP headers have been omitted: they are defined to 152 default to {scope origin} as required for the demonstration. 153 Similarly, the strength of PEP directives defaults to optional ({str 154 opt}), so it is only shown otherwise. 156 4. Operation 1: Requesting Preferred Payment Choices 158 Either end (client or server) should be able to ask the other what 159 forms of payment it supports. 161 CLIENT ASKS SERVER 163 In order for the client to ask the server what payment choices are 164 available, the Protocol-Query: header is added to an HTTP request from 165 the client to the server. JEPI implementors: In the demo, only the 166 server will generate these requests. 168 GET URL 169 Protocol-Query: {http://www.w3.org/UPP upp-params} 171 This means "do you have UPP available at the URL specified in the HTTP 172 request that contains this header." If any of the upp-params are 173 specified then they further restrict the meaning of the query (i.e. if 174 a {upp {amount {frf}}} were specified, the query would mean "do you 175 have UPP available, for amounts denominated in French francs, at the 176 URL specified in the HTTP request that contains this header"). 178 In order to ask a more general question (such as "what payment choices 179 are available for all URLs at your site") the for option must be used: 181 GET URL 182 Protocol-Query: {http://www.w3.org/UPP {for /*} upp-params} 184 Notice that in a for, the "URLs" ending in * are actually prefix 185 strings. So the "/*" here means "any URL at your server that starts 186 with '/'," which in turn means all URLs aat your server. 188 The response to this HTTP message will fall into one of two 189 categories: 190 * No Protocol-Info: {http://www.w3.org/UPP A} header line. This 191 indicates that the server does not support all of PEP. [It is also 192 possible for a server to support PEP, but not UPP, in which case 193 it would send Protocol-Info: {http://www.w3.org/UPP {str ref}}] 194 * A header line of the form Protocol-Info: {http://www.w3.org/UPP A} 195 is included in the headers. This indicates that the server 196 supports PEP, and the response is in the form described below 197 under Operation 2. The header can also use a for list to hint 198 where on the server payments will be discussed. 200 A proper implementation of PEP requires that the protocol module 201 associated with the specified protocol will be invoked when a 202 Protocol-Query: line is encountered specifying that protocol. A proper 203 implementation of the UPP protocol module will supply one of the 204 responses indicated under Operation 2 (Present Payment Choices), 205 indicating the payment options that the server wishes to advertise. 207 SERVER ASKS CLIENT 209 In order for the server to ask the client what payment choices are 210 available, a similar mechanism is used. In this case, however, the 211 server should use the {for } to indicate the parts of its URL space 212 where payment might be discussed: 214 200 OK 215 Protocol-Query: {http://www.w3.org/UPP {for /PaymentPages/*} 216 upp-params} 218 Technically, this is a way for the server to ask the client to reveal 219 payments choices a user will consider for URLs that begin with 220 /PaymentPages/. The client will reply (at least) whether the 221 protocol can be used for the resource of the response, and 222 (optionally) whether it might be used elsewhere (the range the server 223 specified, anywhere on that server, etc). 225 A proper implementation of PEP requires that the protocol module 226 associated with the specified protocol will be invoked when a 227 Protocol-Query line is encountered specifying that protocol. A 228 proper implementation of the UPP protocol module will supply one of 229 the responses indicated under Operation 2 (Present Payment Choices), 230 indicating the payment options that the client wishes to advertise. 232 Then, the next time the client accesses any resource in the for list 233 from the query, it will include its answer(s) to the query. 235 5. Operation 2: Present Payment Choices 237 Either end should be able to list the forms of payment it supports. 238 Notice that this may not be a complete list, but rather a list of 239 options that it "prefers" at the current moment. This list may be 240 presented in response to a request (operation 1) or spontaneously. 241 The latter behavior is analogous to the use of "logo stickers" on a 242 store window or cash register. 244 JEPI implementors: the demo will only require this operation in 245 response to a specific request. 247 This operation is performed by adding one or more Protocol-Info: 248 headers to the HTTP packet. If the list is being presented in response 249 to a request (operation 1), PEP requires that it include a header in 250 the following form: 252 200 OK -or- GET ... 253 Protocol-Info: {http://www.w3.org/UPP [for] [{str strength}] 254 upp-params} 256 where the for should be the same as the for clause in the request (or 257 omitted if it wasn't in the request); and the strength (if present) 258 must be ref, req, or opt. The strength can be opt (or omitted) in any 259 case; it may be ref only if payment won't be permitted at any of the 260 URLs specified by the for clause; it may be req only if payment is 261 required at all of the URLs specified by the for clause. 263 In addition, there should be Protocol-Info: headers for each of the 264 payment systems that are to be presented to the other end.. These will 265 have the form: 267 200 OK -or- GET ... 268 Protocol-Info: {http://...payment-system... [for] [{str strength}] 269 payment-params} 271 where payment-protocol is the URL for the specific payment protocol, 272 the for and strength are as discussed above, and the payment-params 273 are additional parameters (including the UPP parameters) that are 274 specific to the payment system. 276 For example, if a client receives the request: 278 200 OK 279 Protocol-Query: {http://www.w3.org/UPP {for /PaymentPages/*} 280 upp-params} 282 and wishes to indicate that it can pay using VISA over SET and via 283 CyberCash coins it might reply as follows (details of the 284 payment-specific lines are not finalized yet): 286 HEAD ... 287 Protocol-Info: {http://www.w3.org/UPP {for /PaymentPages/*}} 288 {http://www.SET.org/PEPSpec 289 {params {upp {instrument-brand VISA}}} 290 {for /PaymentPages/*}} 291 {http://www.CyberCash.com/PEPSpec 292 {params {upp {instrument-type ECASH}}} 293 {for /PaymentPages/*}} 295 6. Operation 3: Demand Payment Choice 297 The merchant (server) may demand that the client choose a specific 298 form of payment to be used to pay for items. 300 JEPI implementors: In the demo, this happens when the "invoice page" 301 is sent from the server to the client; the demand indicates what 302 components of the page will require a response with payment choice 303 (operation 4). In the demonstration, this same invoice page will 304 carry both the operation 2 and operation 3 headers together: the 305 server will announce some of its payment options at the time it 306 issues the invoice and requires that payment be accompanied by a 307 particular payment choice. 309 As part of a standard server (successful) reply, it may deliver a page 310 that includes references that will require payment (i.e. a "Pay 311 Button" or "Pay URL"). These should be ideentified in the header of the 312 response packet by asking the client to respond by initiating a UPP 313 payment protocol sequence: 315 200 OK 316 Protocol-request: {http://www.w3.org/UPP {str req} {for /PayButton}} 318 Technically, this means that the server asks the client to use the UPP 319 protocol (operation 4) whenever it asks for retrieval of the exact URL 320 /PayButton from this same server. The {str req} is a hint to the 321 client that if it doesn't use the protocol, the request for that URL 322 will be refused. Thus, the client is not absolutely required to 323 remember that it should use UPP with the specified URL - but a network 324 roundtrip will be avoided if it does so. 326 7. Operation 4: Make a Payment Choice 328 The customer (client) can indicate the payment method to be used to 329 make a payment. This normally indicates to the server that payment 330 should actually begin, and the response will either be to accept 331 (operation 5) or reject (operation 6) the chosen mechanism. 333 In practice, this will only happen when a client replies to an 334 operation 3 request for payment method. It must then respond with 335 two headers: one indicating that it is responding to a request to use 336 the UPP protocol by choosing a compatible payment protocol, and the 337 compatible protocol header itself. For example, if the payment choice 338 is to use VISA over SET, then we might expect a response as follows: 340 GET ... 341 Protocol: {http://www.w3.org/UPP {via http://www.SET.org/PEPSpec}} 342 {http://www.SET.org/PEPSpec 343 {str req} 344 {params {upp {instrument-type CREDIT} {instrument-brand VISA}} 345 other-SET-params}} 347 The expected response is either an operation 5 (server accepts the 348 choice of SET and VISA) or operation 6 (server refuses the choice). 350 It is expected that somewhere between receiving the operation 3 and 351 issuing the operation 4 the client application will have to decide on 352 the payment mechanism. Neither PEP nor UPP specifies how this happens. 353 For the JEPI demonstration, it is assumed that the browser will 354 intercept the request to access any specified payment URLs (from the 355 for list of the required challenge) and will engage in a dialog with 356 the user if necessary to produce the desired choice. This implies that 357 what merchants might typically describe as the "Pay" button becomes 358 the "Choose a Payment Mechanism and Pay" button. 360 8. Operation 5: Accept a Payment Choice 362 The server, in response to a payment choice (operation 4), may 363 accept the choice and initiate an actual payment operation. The 364 payment operation itself is not part of the JEPI project and may or 365 may not use PEP to handle the payment. 367 At this point, operation 4 has provided enough information to the 368 server that it is willing to kick off the actual payment system. JEPI, 369 PEP, and UPP provide no information on precisely how to do this, but 370 there is one additional PEP/UPP header which can be optionally sent 371 back to the client. If a normal MIME-based helper application is 372 available to do the payment on the client side, then there is no need 373 for the following header. On the other hand, a better user interface 374 can often be produced if a helper application can be run while the 375 client (browser) waits for the application to complete. To support 376 this, UPP adds one final message from the server to the client. It 377 provides the URLs that should be shown in each of three cases: 378 * the payment is successfully completed 379 * the payment is canceled because of user intervention 380 * the payment is unable to complete because the computers are unable 381 to finish the transaction (network outage, over credit limit, 382 etc.) 384 The header is as follows: 386 200 OK 387 Protocol: {http://www.w3.org/UPP 388 {params {upp {abort abort-URL} 389 {cancel cancel-URL} 390 {success success-URL}}} 392 9. Operation 6: Reject a Payment Choice 394 The server, in response to a payment choice (operation 4), may 395 reject the choice and request that another choice be made. UPP 396 specifies that a rejection can occur either because the user 397 canceled the transaction prior to completion or because the 398 transaction failed for other (payment-system specific) reasons. They 399 are distinguished and can result in different client actions. 401 If a client proposes a payment system that is not acceptable to the 402 server, the server responds with a 400- or 500-class PEP error 403 message. The body of the message should explain what went wrong as 404 well as possible, including any explanation that the requested payment 405 system may be able to supply. It should probably include a button to 406 go back to the invoice page, if possible, but the browser's BACK 407 button will work, too. The server should include one additional header 408 on this message to reduce the chance that the same payment system will 409 be tried a second time: 411 420 Client PEP Error -or- 520 Server PEP Error 412 Protocol-Info: {http://...payment-system... 413 {str ref} payment-params} 414 Followed by an operation 3 header 416 where payment-system is the payment protocol that is being rejected, 417 payment-params are the parameters of the payment system which caused 418 the problem, and pay-URL is the URL of the item just requested (i.e. 419 the one that initiates the payment protocol on the server side). 421 The error code is distinguished mainly by whether the server has the 422 protocol and doesn't accept it and the client should know better (422 423 Protocol Extension Refused) or if the server does not have it (521 424 Protocol Extension Not Implemented) or cannot get it to work (520 425 Protocol Extension Error or 522 Protocol Extension Parameters Not 426 Acceptable). Other PEP error codes may be more specifically applicable 427 for particular payment systems. 429 10. Operation 7: Do you accept payment by X? 431 Either side can ask the other if it supports payment by a particular 432 payment mechanism. 434 JEPI implementors: This is not currently required for the 435 demonstration, but it might be a useful addition for the client to 436 ask the server this question prior to counter-offering with a 437 payment mechanism not mentioned by the server in its list of 438 supported mechanisms (operation 2). 440 The PEP header Protocol-Query can be used by either party at any time 441 to ask this question. As with operation 1, there is a technical 442 meaning for the query that requires the other end to respond with a 443 Protocol-Info response that is specific to the particular URL being 444 queried, and the {for A} construct can be used to generalize the 445 query. 447 Also as with operation 1 and 2, a proper implementation of a payment 448 system module for use with UPP should provide additional information 449 about where and with which parameters the payment system will operate 450 when it is possible to do so. That is, a request for "do you support 451 SET for VISA at URL /MerchantHomePage" must be answered "no" (unless 452 payment happens on the home page), but a more thorough response will 453 volunteer the information that such a payment is permitted elsewhere 454 at the site. 456 200 OK -or- GET ... 457 Protocol-Query: {payment-system [payment-system-params]} 459 where payment-system is the URL of the payment system protocol, and 460 payment-system-params are parameters specific to that protocol 461 (including common UPP parameters). 463 11. Security Considerations 465 None of these message headers have security protection. They should be 466 trusted only if received through a trusted medium (private channel, 467 etc). In addition, UPP makes no security claims about the contents of 468 the headers; ALL payment-related data should be recapitulated within 469 the particular (presumably cryptographically secure) payment protocol. 471 In short, this protocol only addresses payment selection in the clear. 472 Security of the overall payments process lies in other components. 474 12. Authors' Addresses 476 Donald E. Eastlake 3rd 477 CyberCash, Inc. 478 318 Acton Street 479 Carlisle, MA 01741 USA 480 Tel: +1 (508) 287 4877 (+1 703 620 4200 main office, Reston, Virginia, USA) 481 Fax: +1 (508) 371 7148 482 Email: dee@cybercash.com 484 Rohit Khare 485 Technical Staff, W3 Consortium 486 MIT Laboratory for Computer Science 487 545 Technology Square 488 Cambridge, MA 02139, U.S.A. 489 Tel: +1 (617) 253 5884 490 Fax: +1 (617) 258 5999 491 Email: khare@w3.org 493 Jim Miller 494 Technology & Society Area Leader, W3 Consortium 495 MIT Laboratory for Computer Science 496 545 Technology Square 497 Cambridge, MA 02139, U.S.A. 498 Tel: +1 (617) 253 3194 499 Fax: +1 (617) 258 5999 500 Email: jmiller@w3.org