One document matched: draft-ietf-trade-iotp-http-00.txt

INTERNET-DRAFT                                      IOTP HTTP Supplement
                                                           November 1998
                                                        Expires May 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, 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-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-Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts 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).

















D. Eastlake, C. Smith                                           [Page 1]


INTERNET-DRAFT            IOTP HTTP Supplement             November 1998


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

      References.................................................7
      Authors Addresses..........................................7
      Expiration and File Name...................................7




















D. Eastlake, C. Smith                                           [Page 2]


INTERNET-DRAFT            IOTP HTTP Supplement             November 1998


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].



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. Any secure channel that both the HTTP Server and Client support
   may be used. For example SSL version 3 or TLS [xxx].



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.


D. Eastlake, C. Smith                                           [Page 3]


INTERNET-DRAFT            IOTP HTTP Supplement             November 1998


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 message is a stand-in for a request
   message of some form, and the Merchant Server will respond with the
   first OTP 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 should also be recognized.

   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 other HTTP clients. This cab be neglected on SSL/TLS
   secured connections which are not cached.



4.2 Ongoing IOTP Messages

   Data from earlier IOTP Messages must be retained by the IOTP Client
   so that it may be copied to make up part of later IOTP Messages, used
   in caculations to verify signatures in later IOTP message, be resent,
   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.






D. Eastlake, C. Smith                                           [Page 4]


INTERNET-DRAFT            IOTP HTTP Supplement             November 1998


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 Component

   -- does not complete successfully, because it has received some Fail
      Trading Block must display the information in the Fail Message,
      stop the transaction, then pass control to the browser to await a
      response to the message

   -- 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

   -- is in error because an IOTP Message does not conform to this
      specification, sends an IOTP Message containing a Fail Trading
      Block to the ErrorNetLocn contained in the Protocol Options
      Component, stops the IOTP Transaction, and hands control to the
      browser

   -- has a "time out" must display a message describing the time out
      and then pass control to the HTML browser.

   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.








D. Eastlake, C. Smith                                           [Page 5]


INTERNET-DRAFT            IOTP HTTP Supplement             November 1998


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].

   Note that the security of payment protocols transported by IOTP is
   the responsibility of those payment protocols.

































D. Eastlake, C. Smith                                           [Page 6]


INTERNET-DRAFT            IOTP HTTP Supplement             November 1998


References

   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.

   draft-ietf-trade-iotp-v1.0-protocol-*.txt - David Burdett

   draft-ietf-trade-xml-sig-*.txt - Richard Brown



Authors Addresses

   Donald E. Eastlake 3rd
   IBM
   318 Acton Street
   Carlisle, MA 01741 USA

   Telephone:   +1 978-287-4877
                +1 914-784-7913
   FAX:         +1 978-371-7148
   email:       dee3@us.ibm.com


   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:     chris.smith@royalbank.com



Expiration and File Name

   This draft expires May 1999.

   Its file name is draft-ietf-trade-iotp-http-00.txt.









D. Eastlake, C. Smith                                           [Page 7]