rfc2801.txt

RFC 的详细文档！

                          Figure 3 Payment Exchange

   A Payment Exchange uses the following Trading Components that are
   passed between the Consumer, the Merchant and the Payment Handler:

   o  The Brand List Component contains a list of payment brands (for
      example, MasterCard, Visa, Mondex, GeldKarte), payment protocols
      (for example SET Version 1.0, Secure Channel Credit Debit (SCCD -
      the name used for a credit or debit card payment where



Burdett                      Informational                     [Page 22]

RFC 2801                       IOTP/1.0                       April 2000


      unauthorised access to account information is prevented through
      use of secure channel transport mechanisms such as SSL/TLS) as
      well as currencies/amounts that apply. The Merchant sends the
      Brand List to the Consumer. The consumer compares the payment
      brands, protocols and currencies/amounts on offer with those that
      the Consumer supports and makes a selection.

   o  The Brand Selection Component contains the Consumer's selection.
      Payment brand, protocol, currency/amount and possibly protocol-
      specific information is sent back to the Merchant. This
      information may be used to change information in the Offer
      Exchange. For example, a merchant could choose to offer a discount
      to encourage the use of a store card.

   o  the Status component is used to indicate to the Payment Handler
      that an earlier exchange (e.g., an Offer Exchange) has
      successfully completed and by the Payment Handler to indicate the
      completion status of the Payment Exchange.

   o  The Organisation Components are generated by the Merchant. They
      contain details of the Merchant and Payment Handler Roles:

      -  the Merchant role is required so that the Payment Handler can
         identify which Merchant initiated the payment. Typically, the
         result of the Payment Handler accepting (or making) a payment
         on behalf of the Merchant will be a credit or debit transaction
         to the Merchant's account held by the Payment Handler. These
         transactions are outside the scope of this version of IOTP

      -  the Payment Handler role is required so that the Payment
         Handler can check that it is the correct Payment Handler to be
         used for the payment

   o  The Payment Component contains details of how much to pay, the
      currency and the payment direction

   o  The "Offer Response" Signature Component, if present, digitally
      signs all of the above components to ensure their integrity. Note
      that the Brand List and Brand Selection Components are not signed
      until the payment information is created (step 4 in the diagram)

   o  the Trading Role Data component contains from other roles (e.g., a
      Merchant) that needs to be  forwarded to the Payment Handler

   o  The Payment Scheme Component contains messages from the payment
      protocol used in the Trade. For example they could be SET
      messages, Mondex messages, GeldKarte Messages or one of the other
      payment methods supported by IOTP. The content of the Payment



Burdett                      Informational                     [Page 23]

RFC 2801                       IOTP/1.0                       April 2000


      Scheme Component is defined in the supplements that describe how
      IOTP works with various payment protocols.

   o  The Payment Receipt Component contains a record of the payment.
      The content depends upon the payment protocol used.

   o  The "Payment Receipt" Signature Component provides proof of
      payment by digitally signing both the Payment Receipt Component
      and the Offer Response Signature. The signature on the offer
      digitally signs the Order, Organisation and Delivery Components
      contained in the Offer.  This signature effectively binds the
      payment to the offer.

   The example of a Payment Exchange above is the most general case.
   Simpler cases are also possible. For example, if the amount paid is
   not dependent on the payment brand and protocol selected then the
   payment information generated by step 3 can be sent to the Consumer
   at the same time as the Brand List Component generated by step 1.
   These and other variations are described in the Baseline Purchase
   IOTP Transaction (see section 9.1.8).

2.2.3 Delivery Exchange

   The goal of the Delivery Exchange is to cause purchased goods to be
   delivered to the consumer either online or via physical delivery. A
   second goal is to provide a "delivery note" to the consumer,
   providing details about the delivery, such as shipping tracking
   number. The result of the delivery may also be signed so that it can
   be used for customer care in the case of problems with physical
   delivery. The message flow is illustrated in the diagram below.

 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
  CONSUMER  DELIVERY
     |        HANDLER
     |  Merchant |
STEP |     |     |
 1.                 Consumer decides to trade and sends information
                    about what to deliver and who is to take delivery,
                    to the Merchant e.g., using HTML.

     C --> M        Information on what is being delivered (outside
                    scope of IOTP)

 2.                 Merchant checks the information provided by the
                    Consumer, adds information about how the delivery
                    will occur, information about the Organisations
                    involved in the delivery and optionally sings it
                    and sends it to the Consumer



Burdett                      Informational                     [Page 24]

RFC 2801                       IOTP/1.0                       April 2000


     C <-- M        Components: Delivery; Organisations (Delivery
                    Handler, Deliver To); Order, Optional Offer
                    Response Signature

 3.                 Consumer checks delivery information is OK,
                    obtains authorisation for the delivery, for
                    example by making a payment, and sends the
                    delivery information to the Delivery Handler

     C --------> D  DELIVERY REQUEST. Components: Status; Delivery,
                    Organisations: (Merchant, Delivery Handler,
                    DelivTo); Order, Trading Role Data (optional);
                    Optional Offer Response Signature, Optional
                    Payment Receipt Signature (from Payment Exchange)

 4.                 Delivery Handler checks information and
                    authorisation. Starts or schedules delivery and
                    creates and then sends a delivery not tot the
                    Consumer which can optionally be signed.

     C <-------- D  DELIVERY RESPONSE. Components: Status; Delivery
                    Note, Trading Role Data (optional); Optional
                    Delivery Response Signature

 5.                 Consumer checks delivery note is OK and accepts or
                    waits for delivery as described in the the Delivery
                    Note.

 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

                         Figure 4 Delivery Exchange

A Delivery Exchange uses the following Trading Components that are
passed between the Consumer, the Merchant and the Delivery Handler:

   o  the Status component is used to indicate to the Delivery Handler
      that an earlier exchange (e.g., an Offer Exchange or Payment
      Exchange) has successfully completed and by the Delivery Handler
      to indicate the completion status of the Delivery Exchange.

   o  The Organisation Component(s) contain details of the Deliver To,
      Delivery Handler and Merchant Roles:

      -  the Deliver To role indicates where the goods or services are
         to be delivered to






Burdett                      Informational                     [Page 25]

RFC 2801                       IOTP/1.0                       April 2000


      -  the Delivery Handler role is required so that the Delivery
         Handler can check that she is the correct Delivery Handler to
         do the delivery

      -  the Merchant role is required so that the Delivery Handler can
         identify which Merchant initiated the delivery

   o  The Order Component, contains information about the goods or
      services to be delivered

   o  The Delivery Component contains information about how delivery
      will occur, for example by post or using e-mail.

   o  The "Offer Response" Signature Component, if present, digitally
      signs all of the above components to ensure their integrity.

   o  The "Payment Receipt" Signature Component provides proof of
      payment by digitally signing the Payment Receipt Component and the
      Offer Signature. This is used by the Delivery Handler to check
      that delivery is authorised

   o  The Delivery Note Component contains customer care information
      related to a physical delivery, or alternatively the actual
      "electronic goods".  The Consumer's software does not interpret
      information about a physical delivery but should have the ability
      to display the information, both at the time of the delivery and
      later if the Consumer selects the Trade to which this delivery
      relates from a transaction list

   o  The "Delivery Response" Signature Component, if present, provides
      proof of the results of the Delivery by digitally signing the
      Delivery Note and any Offer Response or Payment Response
      signatures that the Delivery Handler received.

2.2.4 Authentication Exchange

   The goal of the Authentication Exchange is to allow one Organisation,
   for example a financial institution, to be able to check that another
   Organisation, for example a consumer, is who they appear to be.

   An Authentication Exchange involves:

   o  an Authenticator - the Organisation which is requesting the
      authentication, and

   o  an Authenticatee - the Organisation being authenticated.





Burdett                      Informational                     [Page 26]

RFC 2801                       IOTP/1.0                       April 2000


   This is illustrated in the diagram below.

 +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
 Organisation 1
 (Authenticatee)
     |   Organisation 2
     |  (Authenticator)
STEP |     |
 1.          First Organisation, e.g., a Consumer, takes an action (for
             example by pressing a button on an HTML page) which
             requires that the Organisation is authenticated

     1 --> 2 Need for Authentication (outside scope of IOTP)

 2.          The second Organisation generates an Authentication
             Request - including challenge data, and a list of the
             algorithms that may be used for the authentication -
             and/or a request for the Organisation information then
             sends it to the first Organisation

     1 <-- 2 AUTHENTICATION REQUEST. Components: Authentication
             Request, Trading Role Information Request

 3.          The first Organisation optionally checks any signature
             associated with the Authentication Request then uses the
             specified authentication algorithm to generate an
             Authentication Response which is sent back to the second
             Organisation together with details of any Organisation
             information requested

     1 --> 2 AUTHENTICATION RESPONSE. Component: Authentication
             Response, Organisation(s)

 4.          The Authentication Response is checked against the
             challenge data to check that the first Organisation is
             who they appear to be and the result recorded in a Status
             Component which is then sent back to the first
             Organisation.

     1 <-- 2 AUTHENTICATION STATUS. Component: Status

 5.          The first Organisation then optionally checks the results
             indicated by the Status and any associated signature and
             takes the appropriate action or stops.

 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

                      Figure 5 Authentication Exchange



Burdett                      Informational                     [Page 27]

RFC 2801                       IOTP/1.0                       April 2000


   An Authentication Exchange uses the following Trading Components that
   are passed between the two Organisations:

   o  the Authentication Request Component that requests an
      Authenticatio