INTERNET-DRAFT IOTP HTTP Supplement
November 1998February 1999 Expires MayAugust 1999 Internet Open Trading Protocol (IOTP) HTTP Supplement -------- ---- ------- -------- ------ ---- ---------- Donald E. Eastlake 3rd Chris J. Smith Status of This Document This draft, file name draft-ietf-trade-iotp-http-00.txt,draft-ietf-trade-iotp-http-01.txt, is intended to become a Proposed Standard RFC. Distribution of this document is unlimited. Comments should be sent to the TRADE WG mailing list <ietf-trade@eListX.com> or to the authors. This document is an Internet-Draft.Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Draftsmonths and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriateinappropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work"work in progress.'' To view the entireprogress". The list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in theInternet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).can be accessed at http://www.ietf.org/shadow.html. Abstract Internet Open Trading Protocol (IOTP) messages will be carried as XML documents. As such, the goal of mapping to the transport layer is to ensure that the underlying XML documents are carried successfully between the various parties. This documents describes that mapping for the Hyper Text Transport Protocol (HTTP), Versions 1.0 and 1.1. Table of Contents Status of This Document....................................1 Abstract...................................................2 Table of Contents..........................................2 1. Introduction............................................3 2. HTTP Servers and Clients................................3 3. HTTP Net Locations......................................3 4. Consumer Clients........................................3 4.1 Starting the IOTP Client and the Merchant IOTP Server..4 4.2 Ongoing IOTP Messages..................................4 4.3 Stopping an IOTP Transaction...........................5 5. Starting the Payment handler and Deliverer IOTP Servers.6 6. Security Considerations.................................6 7. IANA Considerations.....................................6 References.................................................7 Authors Addresses..........................................7 Expiration and File Name...................................7Name...................................8 1. Introduction Internet Open Trading Protocol (IOTP) messages will be carried as XML documents. As such, the goal of mapping to the transport layer is to ensure that the underlying XML documents are carried successfully between the various parties. This documents describes that mapping for the Hyper Text Transport Protocol (HTTP), Versions 1.0 and 1.1 [RFCs 1945, 2068]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. HTTP Servers and Clients The structure of IOTP maps on to the structure of HTTP in the following way: The merchant, payment handler, deliverer, merchant customer care, and payment customer care roles are all represented by HTTP servers. Each may be represented by a separate server, or they may be combined in any combination. The consumer role is represented by an HTTP client. Note: A Merchant, may act in the role of a consumer, for example to deposit electronic cash. In this case the Merchant, as an organisation rather than as a role, would need to be supported by an HTTP client. 3. HTTP Net Locations The Net Locations contained within the IOTP specification are all URLs. AnyURLs [RFC 1738]. If a secure connection is required or desired any secure channel that both the HTTP Server and Client support may be used. Forused, for example SSL version 3 or TLS [xxx].[RFC 2246]. 4. Consumer Clients In most environments, the consumer agent will initially be an HTML browser. However, this does not provide the needed capability to act as an agent for the consumer for an IOTP transaction. This leads to two requirements: a method of starting and passing control to the IOTP client, and a method of closing down the IOTP client cleanly and passing control back to the HTML browser once the IOTP Transaction has finished. 4.1 Starting the IOTP Client and the Merchant IOTP Server At some point, the HTTP client at the consumer will send a HTTP request that is interpreted as an "IOTP Startup Request" by the Merchant HTTP server. This might, for example, be the result of clicking on a "pay" button. This message is a stand-in for a request message of some form,form and the Merchant Server will respond with the first OTPIOTP Message in the form of an XML document. The MIME type for all IOTP messages is: "application/iotp"; however "application/x-iotp" has been in use for experimentation and development and shouldSHOULD also be recognized. Because HTTP is binary clean, no content-transfer-encoding is required. (See [RFC 2376] re the application/xml type which has some similar considerations.) This HTTP response will be interpreted by the HTML browser as a request to start the application associated with MIME type "application/iotp", and to pass the content of this message to that application. At this point, the IOTP client will be started and have the first message. IOTP messages are short-lived. Therefore, the HTTP server has to provide accurate expiration dates or to use the HTTP no-proxy pragma, such that HTTP proxy servers do not store and respond with these messages to othershould avoid having its responses cahced. In HTTP clients.V1.0, the "nocache" pragma can be used. This cabcan be neglected on SSL/TLS secured connections which are not cached and on POST HTTP request in HTTP v1.1 as in v1.1 POST responses are not cached. 4.2 Ongoing IOTP Messages Data from earlier IOTP Messages in a transaction must be retained by the IOTP Client so that it may (1) be copied to make up part of later IOTP Messages, (2) used in caculations to verify signatures in later IOTP message, (3) be resent,resent in some cases where it is a request that times out, (4) used as input to the Customer Care role in later versions of IOTP, etc. The way in which the data is copied depends on the IOTP Transaction. The IOTP Messages contain Net Locations (e.g. the PayReqNetLocn) which for HTTP will contain the URLs to which the IOTP client must ship IOTP Messages. Subsequent IOTP Messages (XML documents) will be sent using the POST function of HTTP. The HTTP client has to perform full HTTP POST requests. The XML documents will be sent in a manner compatible with the external encodings allowed by the XML specification. 4.3 Stopping an IOTP Transaction An IOTP Transaction is complete -- when an IOTP Message is received by the IOTP client with a status of "LastMsg", -- the IOTP client decides to fail the IOTP Transaction for some reason either by canceling the transaction or as a result of discovering an error in an IOTP message received, or -- a "time out" occurs or a connection fails, e.g. a response to an IOTP Message, has not been received after some user-defined period of Time (including retransmissions). An IOTP Client which processes an IOTP Transaction which: -- completes successfully i.e. it has not received any Fail Trading Block, must direct the browser to the Net Location specified in SuccessNetLocn in the Protocol Options ComponentComponent, i.e., cause it to do a GET with that URL. -- does not complete successfully, because it has received some Fail Trading BlockBloc,k must display the information in the Fail Message, stop the transaction, then pass control to the browser to awaitso that it will do a response toGET on the messageError Net Location specified for the role from which the error was received. See draft-ietf-trade-iopt- v1.0-protocol-*.txt. -- is cancelled for some reason, sends an IOTP Message containing an Error Trading Block to the CancelNetLocn contained in the Protocol Options Component, stops the IOTP Transaction, and hands control to the browser so that it will do a GET on the Cancel Net Locations specified for the role the cusomer was in communications with when the cancel occured. See draft-ietf-trade-iopt-v1.0- protocol-*.txt -- is in error because an IOTP Message does not conform to this specification, sends an IOTP Message containing a Fail Trading Block to role from which the ErrorNetLocn contained inbad message was received and the Protocol Options Component,ErrorNetLogLoc specified for that role, stops the IOTP Transaction, and hands control to the browser so that it will do a GET from the Error Net Location specified for the role from which the bad message was received. See draft-ietf-trade-iopt-v1.0- protocol-*.txt -- has a "time out"out", must display a message describing the time out and then pass control toout. May give the HTML browser.user the option of cancelling or retrying and/or may automatically retry. On failure due to time out, treat as an error above. Each implementation of an IOTP client may decide whether or not to terminate the IOTP Client application immediately upon completing an IOTP Transaction or whether to wait until it is closed down as a result of, for example, user shut down or browser shut down. 5. Starting the Payment handler and Deliverer IOTP Servers Payment Handler and Deliverer IOTP Servers are started by receiving an IOTP Message which contains: -- for a Payment handler, a Payment Request Block, and -- for a Deliverer, a Delivery Request Block 6. Security Considerations Security of Internet Open Trade Protocol messages is primarily dependent on signatures within IOTP as described in [draft-ietf- trade-iotp-v1.0-protocol-*.txt] and [draft-ietf-trade-xml-sig-*.txt].[draft-ietf-trade-iotp-v1.0- dsig-*.txt]. Note that the security of payment protocols transported by IOTP is the responsibility of those payment protocols.protocols, NOT of IOTP. 7. IANA Considerations This specification defines the application/iotp mime type which is thereby reserved. References RFC 1738 - "Uniform Resource Locators (URL)", T. Berners-Lee, L. Masinter & M. McCahill. December 1994. RFC 1945 - "Hypertext Transfer Protocol -- HTTP/1.0", T. Berners-Lee, R. Fielding & H. Frystyk. May 1996. RFC 2068 - "Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee. January 1997. RFC 2119 - S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", March 1997. RFC 2246 - "The TLS Protocol Version 1.0", T. Dierks, C. Allen. January 1999. RFC 2376 - "XML Media Types", E. Whitehead, M. Murata. July 1998. draft-ietf-trade-iotp-v1.0-protocol-*.txt - David Burdett draft-ietf-trade-xml-sig-*.txtdraft-ietf-trade-iotp-v1.0-dsig-*.txt - Richard BrownKent Davidson Authors Addresses Donald E. Eastlake 3rd IBM 318 Acton Street Carlisle, MA 0174165 Shindegan Hill Road Carmel, NY 10512 USA Telephone: +1 978-287-4877914-276-2668(h) +1 914-784-7913914-784-7913(w) FAX: +1 978-371-7148914-784-3833(w) email: firstname.lastname@example.org Chris J. Smith Royal Bank of Canada 277 Front Street West Toronto, Ontario M5V 3A4 CANADA Telephone: +1 416-348-6090 FAX: +1 416-348-2210 email: email@example.com Expiration and File Name This draft expires MayAugust 1999. Its file name is draft-ietf-trade-iotp-http-00.txt.draft-ietf-trade-iotp-http-01.txt.