tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2801

 
 
 

Internet Open Trading Protocol - IOTP Version 1.0

Part 7 of 9, p. 201 to 240
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 201 
9.1.2.4 TPO Selection IOTP Message

   The TPO Selection IOTP Message is only used with a Brand Dependent
   Offer Document Exchange. Apart from a Transaction Reference Block
   (see section 3.3), this message consists of just a TPO Selection
   Block (see section 8.1) which is described below.

   TPO SELECTION BLOCK

   The TPO Selection Block (see section 8.2) contains:

   o  one Brand Selection Component (see section 7.8) for use in a
      later Payment Exchange. It contains the results of the consumer
      selecting a Payment Brand, Payment Protocol and currency/amount
      from the list provided in the Brand List Component.

9.1.2.5 Offer Response IOTP Message

   The Offer Response IOTP Message is only used with a Brand Dependent
   Offer Document Exchange. Apart from a Transaction Reference Block
   (see section 3.3), this message consists of:

   o  an Offer Response Block (see section 8.1) and

   o  an optional Signature Block (see section 8.16).

   OFFER RESPONSE BLOCK

   The Offer Response Block (see section 8.3) contains the following
   components:

   o  one Status Component (see section 7.16) which indicates the status
      of the Offer Response. The ProcessState attribute should be set to
      CompletedOk

   o  one Order Component (see section 7.5) which contains details about
      the goods and services which are being purchased or the financial
      transaction which is taking place

   o  one or more Payment Component(s) (see section 7.9) for each
      payment which is to be made

   o  zero or one Delivery Components (see section 7.13) containing
      details of the delivery to be made if the IOTP Transaction
      includes a delivery

   o  zero or more Trading Role Data Components (see section 7.17) if
      required by the Merchant.

Top      Up      ToC       Page 202 
   SIGNATURE BLOCK (OFFER RESPONSE)

   If the Authentication Status Block is being digitally signed then a
   Signature Block must be included that contains a Signature Component
   (see section 7.19) with Digest Elements for the following XML
   elements:

   If the Offer Response is being digitally signed then a Signature
   Block must be included that contains a Signature Component (see
   section 7.19) with Digest Elements for the following XML elements:

   o  the Transaction Reference Block (see section 3.3) for the IOTP
      Message that contains information that describes the IOTP Message
      and IOTP Transaction

   o  the Transaction Id Component (see section 3.3.1) which globally
      uniquely identifies the IOTP Transaction

   o  the following components of the TPO Block :

      -  the Protocol Options Component, and

      -  the Brand List Component

      -  all the Organisation Components present

   o  the following components of the Offer Response Block:

      -  the Order Component

      -  all the Payment Components present

      -  the Delivery Component if present

      -  any Trading Role Data Components present

9.1.2.6 TPO and Offer Response IOTP Message

   The TPO and Offer Response IOTP Message is only used with a Brand
   Independent Offer Document Exchange. Apart from a Transaction
   Reference Block (see section 3.3), this message consists of:

   o  a Trading Protocol Options Block (see section 8.1)

   o  an Offer Response Block (see section 8.1) and

   o  an optional Signature Block (see section 8.16).

Top      Up      ToC       Page 203 
   TPO (TRADING PROTOCOL OPTIONS) BLOCK

   This is the same as the Trading Protocol Options Block described in
   TPO IOTP Message (see section 9.1.2.3).

   OFFER RESPONSE BLOCK

   This the same as the Offer Response Block in the Offer Response IOTP
   Message (see section 9.1.2.5).

   AUTHENTICATION STATUS

   If the Offer Document Exchange was preceded by an Authentication
   Document Exchange, then the TPO and Offer Response IOTP Message may
   also contain an Authentication Status Block (see section 8.6).

   SIGNATURE BLOCK

   This is the same as the Signature Block in the Offer Response IOTP
   Message (see section 9.1.2.5) with the addition that:

   o  if the Offer Document Exchange is Brand Dependent then the
      Signature Component in the Signature Block additionally contains a
      Digest Element for the Brand Selection Component contained in the
      TPO Selection Block

   o  if the Offer Document Exchange was preceded by an Authentication
      Document Exchange then the Signature Component in the Signature
      Block additionally contains a Digest Element for the
      Authentication Status Block.

9.1.3 Payment Document Exchange

   The Payment Document Exchange is a direct implementation of the last
   part of a Payment Trading Exchange (see section 2.2.2) after the
   Brand has been selected by the Consumer. A Payment Exchange consists
   of:

   o  the Consumer requesting that a payment starts by generating
      Payment Request IOTP Message using information from previous IOTP
      Messages in the Transaction and then sending it to the Payment
      Handler

   o  the Payment Handler and the Consumer then swapping Payment
      Exchange IOTP Messages encapsulating payment protocol messages
      until the payment is complete, and finally

Top      Up      ToC       Page 204 
   o  the Payment Handler sending a Payment Response IOTP Message to the
      Consumer containing a receipt for the payment.

   The IOTP Messages which are involved are illustrated by the diagram
   below.

 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Consumer
     |  Payment
     |  Handler
STEP |     |
 1.          Consumer generates Pay Request Block encapsulating a
             payment protocol message if required and sends to Payment
             Handler with the Signature Block if present

     C --> P PAYMENT REQUEST. IotpMsg: Trans Ref Block; Signature
             Block (optional); Pay Request Block

 2.          Payment Handler processes Pay Request Block, checks
             optional signature and starts exchanging payment protocol
             messages encapsulated in a Pay Exchange Block, with the
             Consumer

     C <-> P PAYMENT EXCHANGE. IotpMsg: Trans Ref Block; Pay Exchange
             Block

 3.          Consumer and Payment Handler keep on exchanging Payment
             Exchange blocks until eventually payment protocol
             messages finish so Payment Handler creates a Pay Receipt
             Component inside a Pay Response Block, and an optional
             Signature Component inside a Signature Block, sends them
             to the Consumer and stops.

     C <-- P PAYMENT RESPONSE. IotpMsg: Trans Ref Block; Signature
             Block (optional); Pay Response Block

 4.          Consumer checks Payment Response is OK. Optionally keeps
             information on IOTP Transaction for record keeping
             purposes and either stops or creates the next IOTP
             message for the Transaction and sends it together with
             the Signature Block, if present, to the required Trading
             Role

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

                     Figure 21 Payment Document Exchange

Top      Up      ToC       Page 205 
9.1.3.1 Message Processing Guidelines

   On receiving a Payment Request IOTP Message, the Payment Handler
   should check that they are authorised to carry out the Payment (see
   section 6 Digital Signatures). They may then either:

   o  generate and send a Payment Exchange IOTP Message back to the
      Consumer, if more payment protocol messages need to be exchanged,
      or

   o  generate and send a Payment Response IOTP Message if the exchange
      of payment protocol messages is complete, or

   o  indicate failure to continue with the Payment by sending a Cancel
      Block back to the Consumer containing a Status Component with a
      StatusType of Payment, a ProcessState of Failed and the
      CompletionCode (see section 7.16.4) set to either: BrandNotSupp,
      CurrNotSupp, PaymtCancelled, AuthError, InsuffFunds,
      InstBrandInvalid, InstNotValid, BadInstrument or Unspecified.

   On receiving a Payment Exchange IOTP Message, the Consumer may
   either:

   o  generate and send a Payment Exchange Message back to the Payment
      Handler or

   o  indicate failure to continue with the Payment by sending a Cancel
      Block back to the Payment Handler containing a Status Component
      with a StatusType of Payment, a ProcessState of Failed and the
      CompletionCode (see section 7.16.2) set to either: ConsCancelled
      or Unspecified.

   On receiving a Payment Exchange IOTP Message, the Payment Handler may
   either:

   o  generate and send a Payment Exchange IOTP Message back to the
      Consumer, if more payment protocol messages need to be exchanged,
      or

   o  generate and send a Payment Response IOTP Message if the exchange
      of payment protocol messages is complete, or

   o  indicate failure to continue with the Payment by sending a Cancel
      Block back to the Consumer containing a Status Component with a
      StatusType of Payment, a ProcessState of Failed and the
      CompletionCode (see section 7.16.2) set to either: PaymtCancelled
      or Unspecified.

Top      Up      ToC       Page 206 
   On receiving a Payment Response IOTP Message, the Consumer may
      either:

   o  generate and send the next IOTP Message in the IOTP transaction
      and send it to the required Trading Role. This is dependent on the
      IOTP Transaction,

   o  stop, since the IOTP Transaction has ended, or

   o  indicate failure to continue with the IOTP Transaction by sending
      a Cancel Block back to the Merchant containing a Status Component
      with a StatusType of Payment, a ProcessState of Failed and the
      CompletionCode (see section 7.16.1) set to either: ConsCancelled
      or Unspecified.

   If the Consumer receives an IOTP Message containing a Cancel block,
   then the information contained in the IOTP Message should be reported
   to the Consumer but no further action taken.

   If the Payment Handler receives an IOTP Message containing a Cancel
   block, then the Consumer is likely to go to the CancelNetLocn
   specified on the Trading Role Element in the Organisation Component
   for the Payment Handler from which any further action may take place.

   If the Merchant receives an IOTP Message containing a Cancel block,
   then the Consumer should have completed the payment but not
   continuing with the transaction for some reason. In this case the
   Consumer is likely to go to the CancelNetLocn specified on the
   Trading Role Element in the Organisation Component for the Merchant
   from which any further action may take place.

9.1.3.2 Payment Request IOTP Message

   Apart from a Transaction Reference Block (see section 3.3), this
   message consists of:

   o  a Payment Request Block, and

   o  an optional Signature Block

   PAYMENT REQUEST BLOCK

   The Payment Request Block (see section 8.7) contains:

   o  the following components copied from the Offer Response Block from
      the preceding Offer Document Exchange:

      -  the Status Component

Top      Up      ToC       Page 207 
      -  the Payment Component for the payment which is being carried
         out

   o  the following components from the TPO Block:

      -  the Organisation Components with the roles of Merchant and for
         the PaymentHandler that is being sent the Payment Request Block

      -  the Brand List Component for the payment, i.e. the Brand List
         referred to by the BrandListRef attribute on the Payment
         Component

   o  one Brand Selection Component for the Brand List, i.e. the Brand
      Selection Component where BrandListRef attribute points to the
      Brand List. This component can be either:

      -  copied from the TPO Selection Block if the payment was preceded
         by a Brand Dependent Offer Document Exchange (see section
         9.1.2.1), or

      -  created by the Consumer, containing the payment brand, payment
         protocol and currency/amount selected from the Brand List, if
         the payment was preceded by a Brand Independent Offer Document
         Exchange (see section 9.1.2.2)

   o  an optional Payment Scheme Component (see section 7.10) if
      required by the payment method used (see the Payment Method
      supplement to determine if this is needed).

   o  zero or more Trading Role Data Components (see section 7.17).

   Note that:

   o  if there is more than one Payment Components in an Offer Response
      Block, then the second payment is the one within the Offer
      Response Block that contains a StartAfter attribute (see section
      7.9) that identifies the Payment Component for the first payment

   o  the Payment Handler to include is identified by the Brand
      Selection Component (see section 7.8) for the payment. Also see
      section 6.3.1 Check Request Block sent Correct Organisation for an
      explanation on how Payment Handlers are identified

   o  the Brand List Component to include is the one identified by the
      BrandListRef attribute of the Payment Component for the identified
      payment

Top      Up      ToC       Page 208 
   o  the Brand Selection Component to include from the Offer Response
      Block is the one that contains an BrandListRef attribute (see
      section 3.5) which identifies the Brand List Component for the
      second payment.

   SIGNATURE BLOCK (PAYMENT REQUEST)

   If the either the preceding Offer Document Exchange included an Offer
   Response Signature (see section 9.1.2.5 Offer Response IOTP Message),
   or a preceding Payment Exchange included a Payment Response Signature

   (see section 9.1.3.4 Payment Response IOTP Message) then they should
   both be copied to the Signature Block in the Payment Request IOTP
   Message.

9.1.3.3 Payment Exchange IOTP Message

   Apart from a Transaction Reference Block (see section 3.3), this
   message consists of just a Payment Exchange Block.

   PAYMENT EXCHANGE BLOCK

   The Payment Exchange Block (see section 8.8) contains:

   o  one Payment Scheme Component (see section 7.10) which contains
      payment method specific data. See the Payment Method supplement
      for the payment method being used to determine what this should
      contain.

9.1.3.4 Payment Response IOTP Message

   Apart from a Transaction Reference Block (see section 3.3), this
   message consists of:

   o  a Payment Response Block, and

   o  an optional Signature Block

   PAYMENT RESPONSE BLOCK

   The Payment Response Block (see section 8.9) contains:

   o  one Payment Receipt Component (see section 7.11) which contains
      scheme specific data which can be used to verify the payment
      occurred

Top      Up      ToC       Page 209 
   o  one Payment Scheme Component (see section 7.10) if required which
      contains payment method specific data. See the Payment Method
      supplement for the payment method being used to determine what
      this should contain

   o  an optional Payment Note Component (see section 7.12)

   o  zero or more Trading Role Data Components (see section 7.17).

   SIGNATURE BLOCK (PAYMENT RESPONSE)

   If a signed Payment Receipt is being provided, indicated by the
   SignedPayReceipt attribute of the Payment Component being set to
   True, then the Signature Block should contain a Signature Component
   which contains Digest Elements for the following:

   o  the Transaction Reference Block (see section 3.3) for the IOTP
      Message which contains the first usage of the Payment Response
      Block,

   o  the Transaction Id Component (see section 3.3.1) within the
      Transaction Reference Block that globally uniquely identifies the
      IOTP Transaction,

   o  the Payment Receipt Component from the Payment Response Block,

   o  the Payment Note Component from the Payment Response Block,

   o  the other Components referenced by the PayReceiptNameRefs
      attribute (if present) of the Payment Receipt Component,

   o  the Status Component from the Payment Response Block,

   o  any Trading Role Data Components in the Payment Response Block,
      and

   o  all the Signature Components contained in the Payment Request
      Block if present.

9.1.4 Delivery Document Exchange

   The Delivery Document Exchange is a direct implementation of a
   Delivery Trading Exchange (see section 2.2.3). It consists of:

   o  the Consumer requesting a Delivery by generating Delivery Request
      IOTP Message using information from previous IOTP Messages in the
      Transaction and then sending it to the Delivery Handler

Top      Up      ToC       Page 210 
   o  the Delivery Handler sending a Delivery Response IOTP Message to
      the Consumer containing details about the Handler's response to
      the request together with an optional signature.

   The message flow is illustrated by the diagram below.

 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
 Consumer
     |  Delivery
     |  Handler
STEP |     |
 1.          Consumer generates Delivery Request Block and sends it to
             the Delivery Handler with the Signature Block if present

     C --> D DELIVERY REQUEST. IotpMsg: Trans Ref Block; Signature
             Block; Delivery Request Block

 2.          Delivery Handler checks the Status and Order Components
             in the Delivery Request and the optional Signatures,
             creates a Delivery Response Block, sends to the Consumer
             and stops.

     C <-- D DELIVERY RESPONSE. IotpMsg: Trans Ref Block; Signature
             Block; Delivery Response Block

3.           Consumer checks Delivery Response Block and optional
             Signature Block are OK. Optionally keeps information on
             IOTP Transaction for record keeping purposes and stops.

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

                    Figure 22 Delivery Document Exchange

9.1.4.1 Message Processing Guidelines

   On receiving a Delivery Request IOTP Message, the Delivery Handler
   should check that they are authorised to carry out the Delivery (see
   section 6 Digital Signatures). They may then either:

   o  generate and send a Delivery Response IOTP Message to the
      Consumer, or

   o  indicate failure to continue with the Delivery by sending a Cancel
      Block back to the Consumer containing a Status Component with a
      StatusType of Delivery, a ProcessState of Failed and the
      CompletionCode (see section 7.16.4) set to either: DelivCanceled,
      or Unspecified.

Top      Up      ToC       Page 211 
   On receiving a Delivery Response IOTP Message, the Consumer should
   just stop since the IOTP Transaction is complete.

   If the Consumer receives an IOTP Message containing a Cancel block,
   then the information contained in the IOTP Message should be reported
   to the Consumer but no further action taken.

9.1.4.2 Delivery Request IOTP Message

   The Delivery Request IOTP Message consists of:

   o  a Delivery Request Block, and

   o  an optional Signature Block

   DELIVERY REQUEST BLOCK

   The Delivery Request Block (see section 8.10) contains:

   o  the following components copied from the Offer Response Block:

      -  the Status Component (see section 7.16)

      -  the Order Component (see section 7.5)

      -  the Organisation Component (see section 7.6) with the roles of:
         Merchant, DeliveryHandler and DeliverTo

      -  the Delivery Component (see section 7.13)

   o  the following Component from the Payment Response Block:

      -  the Status Component (see section 7.16).

   o  zero or more Trading Role Data Components (see section 7.17).

   SIGNATURE BLOCK (DELIVERY REQUEST)

   If the preceding Offer Document Exchange included an Offer Response
   Signature or the Payment Document Exchange included a Payment
   Response Signature, then they should both be copied to the Signature
   Block.

9.1.4.3 Delivery Response IOTP Message

   The Delivery Response IOTP Message contains a Delivery Response Block
   and an optional Signature Block.

Top      Up      ToC       Page 212 
   DELIVERY RESPONSE BLOCK

   The Delivery Response Block contains:

   o  one Delivery Note Component (see section 7.15) which contains
      delivery instructions about the delivery of goods or services

      in3 SIGNATURE BLOCK (DELIVERY RESPONSE)

      The Signature Block should contain one Signature Component that
      contains Digest elements that refer to

   o  the Transaction Id Component (see section 3.3.1) of the IOTP
      message that contains the Delivery  Response Signature

   o  the Transaction Reference Block (see section 3.3) of the IOTP
      Message that contains the Delivery  Response Signature

   o  the Consumer Delivery Data component contained in the Delivery
      Request Block (if any)

   o  the Signature Components contained in the Delivery Request Block
      (if any)

   o  the Status Component

   o  the Delivery Note Component

9.1.5 Payment and Delivery Document Exchange

   The Payment and Delivery Document Exchange is a combination of the
   last part of the Payment Trading Exchange (see section 2.2.2) and a
   Delivery Trading Exchange (see section 2.2.3). It consists of:

   o  the Consumer requesting that a payment starts by generating
      Payment Request IOTP Message using information from previous IOTP
      Messages in the Transaction and then sending it to the Payment
      Handler

   o  the Payment Handler and the Consumer then swapping Payment
      Exchange IOTP Messages encapsulating payment protocol messages
      until the payment is complete, and finally

   o  the Payment Handler sending to the Consumer in one IOTP Message:

      -  a Payment Response Block containing a receipt for the payment,
         and

Top      Up      ToC       Page 213 
      -  a Delivery Response Block containing details of the goods or
         services to be delivered

   The IOTP Messages which are involved are illustrated by the diagram
   below.

Top      Up      ToC       Page 214 
 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
 Consumer
     |  Payment
     |  Handler
STEP |     |
 1.          Consumer generates Pay Request Block encapsulating a
             payment protocol message if required and sends to Payment
             Handler with the Signature Block if present

     C --> P PAYMENT REQUEST. IotpMsg: Trans Ref Block; Signature
             Block; Pay Request Block

 2.          Payment Handler processes Pay Request Block, checks
             optional signature and starts exchanging payment protocol
             messages encapsulated in a Pay Exchange Block, with the
             Consumer

     C <-> P PAYMENT EXCHANGE. IotpMsg: Trans Ref Block; Pay Exchange
             Block

 3.          Consumer and Payment Handler keep on exchanging Payment
             Exchange blocks until eventually payment protocol
             messages finish so Payment Handler creates a Pay Receipt
             Component inside a Pay Response Block, and an optional
             Signature Component inside a Signature Block, then uses
             information from the Offer Response Bock to create a
             Delivery Response Block and sends both to the Consumer
             and stops.

     C <-- P PAYMENT RESPONSE & DELIVERY RESPONSE. IotpMsg: Trans Ref
             Block; Signature Block; Pay Response Block; Delivery
             Response Block

 4.          Consumer checks Payment Response and Delivery Response
             Blocks are OK. Optionally keeps information on IOTP
             Transaction for record keeping purposes and either stops
             or creates the next IOTP message for the Transaction and
             sends it together with the Signature Block, if present,
             to the required Trading Role

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

              Figure 23 Payment and Delivery Document Exchange

Top      Up      ToC       Page 215 
   The Delivery Response Block and the Payment Response Block may be
   combined into the same IOTP Message only if the Payment Handler has
   the information available so that she can send the Delivery Response
   Block.  This is likely to, but will not necessarily, occur when the
   Merchant, the Payment Handler and the Delivery Handler Roles are
   combined.

   The DelivAndPayResp attribute of the Delivery Component (see section
   7.13) contained within the Offer Response Block (see section 8.3) is
   set to True if the Delivery Response Block and the Payment Response
   Block are combined into the same IOTP Message and is set to False if
   the Delivery Response Block and the Payment Response Block are sent
   in separate IOTP Messages.

9.1.5.1 Message Processing Guidelines

   On receiving a Payment Request IOTP Message or a Payment Exchange
   IOTP Message, the Payment Handler should carry out the same actions
   as for a Payment Document Exchange (see section 9.1.3.1).

   On receiving a Payment Exchange IOTP Message, the Consumer should
   also carry out the same actions as for a Payment Document Exchange
   (see section 9.1.3.1).

   On receiving a Payment Response and Delivery Response IOTP Message
   then the IOTP Transaction is complete and should take no further
   action.

   If the Consumer receives an IOTP Message containing a Cancel block,
   then the information contained in the IOTP Message should be reported
   to the Consumer but no further action taken.

   If the Payment Handler receives an IOTP Message containing a Cancel
   block, then the Consumer is likely to go to the CancelNetLocn
   specified on the Trading Role Element in the Organisation Component
   for the Payment Handler from which any further action may take place.

   If the Merchant receives an IOTP Message containing a Cancel block,
   then the Consumer should have completed the payment but not
   continuing with the transaction for some reason. In this case the
   Consumer is likely to go to the CancelNetLocn specified on the
   Trading Role Element in the Organisation Component for the Merchant
   from which any further action may take place.

9.1.5.2 Payment Request IOTP Message

   The content of this message is the same as for a Payment Request IOTP
   Message in a Payment Document Exchange (see section 9.1.3.2).

Top      Up      ToC       Page 216 
9.1.5.3 Payment Exchange IOTP Message

   The content of this message is the same as for a Payment Exchange
   IOTP Message in a Payment Document Exchange (see section 9.1.3.3).

9.1.5.4 Payment Response and Delivery Response IOTP Message

   The content of this message consists of:

   o  a Payment Response Block,

   o  an optional Signature Block (Payment Response), and

   o  a Delivery Response Block.

   PAYMENT RESPONSE BLOCK

   The content of this block is the same as the Payment Response Block
   in the Payment Response IOTP Message associated with a Payment
   Document Exchange (see section 9.1.3.4).

   SIGNATURE BLOCK (PAYMENT RESPONSE)

   The content of this block is the same as the Signature Block (Payment
   Response) in the Payment Response IOTP Message associated with a
   Payment Document Exchange (see section 9.1.3.4).

   DELIVERY RESPONSE BLOCK

   The content of this block is the same as the Delivery Response Block
   in the Delivery Response IOTP Message associated with a Delivery
   Document Exchange (see section 9.1.4.3).

9.1.6 Baseline Authentication IOTP Transaction

   A Baseline Authentication IOTP Transaction may occur at any time
   between any of the Trading Roles involved in IOTP Transactions. This
   means it could occur:

   o  before another IOTP Transaction

   o  at the same time as another IOTP Transaction

   o  independently of any other IOTP Transaction.

   The Baseline Authentication IOTP Transaction consists of just an
   Authentication Document Exchange (see section 9.1.1) as illustrated
   by the diagram below.

Top      Up      ToC       Page 217 
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

   START -------------------------------------------------------
                                                                v
                                                       ----------------
                                                      | AUTHENTICATION |
                                                       ----------------
                                                                 |
                                                                 |
                                                                 |
                                                                 |
                  -------------------     -----------------      |
                 | BRAND INDEPENDENT |   | BRAND DEPENDENT |     |
                 |       OFFER       |   |      OFFER      |     |
                  -------------------     -----------------      |
                                                                 |
                                                                 |
                                                                 |
                                                                 |
                                                                 |
                      ---------           --------------         |
                     | PAYMENT |         | PAYMENT WITH |        |
                     | (first) |         |   DELIVERY   |        |
                      ---------           --------------         |
                                                                 |
                                                                 |
                                                                 |
         ----------        ---------                             |
        | DELIVERY |      | PAYMENT |                            |
        |          |      | {second)|                            |
         ----------        ---------                             |
                                                                 v
                                                               STOP

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

               Figure 24 Baseline Authentication IOTP Transaction

   Example uses of the Baseline Authentication IOTP Transaction include:

   o  when the Baseline Authentication IOTP Transaction takes place as
      an early part of a session where strong continuity exists. For
      example, a Financial Institution could:

      -  set up a secure channel (e.g., using [SSL/TLS]) with a customer

      -  authenticate the customer using the Baseline Authentication
         IOTP Transaction, and then

Top      Up      ToC       Page 218 
      -  provide the customer with access to account information and
         other services with the confidence that they are communicating
         with a bona fide customer.

   o  as a means of providing a Merchant role with Organisation
      Components that contain information about Consumer and DelivTo
      Trading Roles

   o  so that a Consumer may authenticate a Payment Handler before
      starting a payment.

9.1.7 Baseline Deposit IOTP Transaction

   The Baseline Deposit IOTP Transaction supports the deposit of
   electronic cash with a Financial Institution.

   Note: The Financial Institution has, in IOTP terminology, a role of
   merchant in that a service (i.e. a deposit of electronic cash) is
   being offered in return for a fee, for example bank charges of some
   kind. The term "Financial Institution" is used in the diagrams and in
   the text for clarity.

   The Baseline Deposit IOTP Transaction consists of the following
   Document Exchanges:

   o  an optional Authentication Document Exchange (see section 9.1.1)

   o  an Offer Document Exchange (see section 9.1.2), and

   o  a Payment Document Exchange (see section 9.1.3).

   The way in which these Document Exchanges may be combined together is
   illustrated by the diagram below.

Top      Up      ToC       Page 219 
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

   START -----------------------------------------------------
      |                                                       v
      |                                                ----------------
      |                                               | AUTHENTICATION |
      |                                                ----------------
       --------------------------------------               |
                       |                     |              |
                       |      -------------- | -------------
                       v      v              v      v
                  -------------------     -----------------
                 | BRAND INDEPENDENT |   | BRAND DEPENDENT |
                 |       OFFER       |   |      OFFER      |
                  -------------------     -----------------
                        |                        |
                        |                        |
                        |                        |
                        |     -------------------
                        v    v
                      ---------           --------------
                     | PAYMENT |         | PAYMENT WITH |
                     | (first) |         |   DELIVERY   |
                      ---------           --------------
                          |
                           ----------------
                                           |
         ----------        ---------       |
        | DELIVERY |      | PAYMENT |      |
        |          |      | {second)|      |
         ----------        ---------       |
                                           |
                                            -----------------> STOP

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

                   Figure 25 Baseline Deposit IOTP Transaction

   See section 9.1.12 "Valid Combinations of Document Exchanges" to
   determine which combination of document exchanges apply to a
   particular instance of an IOTP Transaction

   Note that:

   o  a Merchant (Financial Institution) may be able to accept a deposit
      in several different types of electronic cash although, since the
      Consumer role that is depositing the electronic cash usually knows
      what type of cash they want to deposit, it is usually constrained

Top      Up      ToC       Page 220 
      in practice to only one type. However, there may be several
      different protocols which may be used for the same "brand" of
      electronic cash. In this case a Brand Dependent Offer may be
      appropriate to negotiate the protocol to be used.

   o  the Merchant (Financial Institution) may use the results of the
      authentication to identify not only the consumer but also the
      account to which the payment is to be deposited. If no single
      account can be identified, then it must be obtained by other
      means. For example:

      -  the consumer could specify the account number prior to the
         Baseline Deposit IOTP Transaction starting, or

      -  the consumer could have been identified earlier, for example
         using a Baseline Authentication IOTP Transaction, and an
         account selected from a list provided by the Financial
         Institution.

   o  The Baseline Deposit IOTP Transaction without an Authentication
      Document Exchange might be used:

      -  if a previous IOTP transaction, for example a Baseline
         Withdrawal or a Baseline Authentication, authenticated the
         consumer, and a secure channel has been maintained, therefore
         the authenticity of the consumer is known

      -  if authentication is achieved as part of a proprietary payment
         protocol and is therefore included in the Payment Document
         Exchange

      -  if authentication of the consumer has been achieved by some
         other means outside of the scope of IOTP, for example, by using
         a pass phrase, or a proprietary banking software solution.

9.1.8 Baseline Purchase IOTP Transaction

   The Baseline Purchase IOTP Transaction supports the purchase of goods
   or services using any payment method. It consists of the following
   Document Exchanges:

   o  an optional Authentication Document Exchange (see section 9.1.1)

   o  an Offer Document Exchange (see section 9.1.2)

   o  either:

      -  a Payment Document Exchange (see section 9.1.3) followed by

Top      Up      ToC       Page 221 
      -  a Delivery Document Exchange (see section 9.1.4)

   o  a Payment Document Exchange only, or

   o  a combined Payment and Delivery Document Exchange (see section
      9.1.5).

   The ways in which these Document Exchanges are combined is
   illustrated by the diagram below.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

   START -----------------------------------------------------
      |                                                       v
      |                                                ----------------
      |                                               | AUTHENTICATION |
      |                                                ----------------
       --------------------------------------               |    |
                       |                     |              |    |
                       |      -------------- | -------------     |
                       v      v              v      v            |
                  -------------------     -----------------      |
                 | BRAND INDEPENDENT |   | BRAND DEPENDENT |     |
                 |       OFFER       |   |      OFFER      |     |
                  -------------------     -----------------      |
                        |    |                   |   |           |
                        |     ---------------    |   |           |
                        |                    |   |   |           |
                        |     -------------- | --    |           |
                        v    v               v       v           |
                      ---------           --------------         |
                     | PAYMENT |         | PAYMENT WITH |        |
                     | (first) |         |   DELIVERY   |        |
                      ---------           --------------         |
                          |                      |               |
              -----------------------------      |               |
              v                            |     |               |
         ----------        ---------       |     |               |
        | DELIVERY |      | PAYMENT |      |     |               |
        |          |      | {second)|      |     |               |
         ----------        ---------       |     |               |
              |                            |     |               v
               ----------------------------------------------> STOP

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

                  Figure 26 Baseline Purchase IOTP Transaction

Top      Up      ToC       Page 222 
   See section 9.1.12 "Valid Combinations of Document Exchanges" to
   determine which combination of document exchanges apply to a
   particular instance of an IOTP Transaction.

9.1.9 Baseline Refund IOTP Transaction

   In business terms the refund process typically consists of:

   o  a request for a refund being made by the Consumer to the Merchant,
      typically supported by evidence to demonstrate:

      -  the original trade took place, for example by providing a
         receipt for the original transaction

      -  using some type of authentication, that the consumer requesting
         the refund is the consumer, or a representative of the
         consumer, who carried out the original trade

      -  the reason why the merchant should make the refund

   o  the merchant agreeing (or not) to the refund. This may involve
      some negotiation between the Consumer and the Merchant, and, if
      the merchant agrees,

   o  a refund payment by the Merchant to the Consumer.

   The Baseline Refund IOTP Transaction supports a subset of the above,
   specifically it supports:

   o  stand alone authentication of the Consumer using a separate
      Baseline Authentication IOTP Transaction (see section 9.1.6)

   o  a refund payment by the Merchant to the Consumer using the
      following two Trading Exchanges:

      -  an optional Authentication Document Exchange (see section
         9.1.1)

      -  an Offer Document Exchange (see section 9.1.2), and

      -  a Payment Document Exchange (see section 9.1.3).

   The ways in which these Document Exchanges are combined is
   illustrated by the diagram below.

Top      Up      ToC       Page 223 
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

   START -----------------------------------------------------
      |                                                       v
      |                                                ----------------
      |                                               | AUTHENTICATION |
      |                                                ----------------
       --------------------------------------               |
                       |                     |              |
                       |      -------------- | -------------
                       v      v              v      v
                  -------------------     -----------------
                 | BRAND INDEPENDENT |   | BRAND DEPENDENT |
                 |       OFFER       |   |      OFFER      |
                  -------------------     -----------------
                        |                        |
                        |                        |
                        |                        |
                        |     -------------------
                        v    v
                      ---------           --------------
                     | PAYMENT |         | PAYMENT WITH |
                     | (first) |         |   DELIVERY   |
                      ---------           --------------
                          |
                           ----------------
                                           |
         ----------        ---------       |
        | DELIVERY |      | PAYMENT |      |
        |          |      | {second)|      |
         ----------        ---------       |
                                           |
                                            -----------------> STOP

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

                   Figure 27 Baseline Refund IOTP Transaction

   A Baseline Refund IOTP Transaction without an Authentication Document
   Exchange might be used:

   o  when authentication of the consumer has been achieved by some
      other means, for example, the consumer has entered some previously
      supplied code in order to identify herself and the refund to which
      the code applies. The code could be supplied, for example on a web
      page or by e-mail.

Top      Up      ToC       Page 224 
   o  when a previous IOTP transaction, for example a Baseline
      Authentication, authenticated the consumer, and a secure channel
      has been maintained, therefore the authenticity of the consumer is
      known and therefore the previously agreed refund can be
      identified.

   o  when the authentication of the consumer is carried out by the
      Payment Handler using a payment scheme authentication algorithm.

9.1.10 Baseline Withdrawal IOTP Transaction

   The Baseline Withdrawal IOTP Transaction supports the withdrawal of
   electronic cash from a Financial Institution.

   Note: The Financial Institution has, in IOTP terminology, a role of
   merchant in that a service (i.e. a withdrawal of electronic cash) is
   being offered in return for a fee, for example bank charges of some
   kind. The term "Financial Institution" is used in the diagrams and in
   the text for clarity.

   The Baseline Withdrawal IOTP Transaction consists of the following
   Document Exchanges:

   o  an optional Authentication Document Exchange (see section 9.1.1)

   o  an Offer Document Exchange (see section 9.1.2), and

   o  a Payment Document Exchange (see section 9.1.3).

   The way in which these Document Exchanges may be combined together is
   illustrated by the diagram below.

Top      Up      ToC       Page 225 
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

   START -----------------------------------------------------
      |                                                       v
      |                                                ----------------
      |                                               | AUTHENTICATION |
      |                                                ----------------
       --------------------------------------               |
                       |                     |              |
                       |      -------------- | -------------
                       v      v              v      v
                  -------------------     -----------------
                 | BRAND INDEPENDENT |   | BRAND DEPENDENT |
                 |       OFFER       |   |      OFFER      |
                  -------------------     -----------------
                        |                        |
                        |                        |
                        |                        |
                        |     -------------------
                        v    v
                      ---------           --------------
                     | PAYMENT |         | PAYMENT WITH |
                     | (first) |         |   DELIVERY   |
                      ---------           --------------
                          |
                           ----------------
                                           |
         ----------        ---------       |
        | DELIVERY |      | PAYMENT |      |
        |          |      | {second)|      |
         ----------        ---------       |
                                           |
                                            -----------------> STOP

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

                 Figure 28 Baseline Withdrawal IOTP Transaction

   Note that:

   o  a Merchant (Financial Institution) may be able to offer withdrawal
      of several different types of electronic cash. In practice usually
      only one form of electronic cash may be offered. However, there
      may be several different protocols which may be used for the same
      "brand" of electronic cash.

Top      Up      ToC       Page 226 
   o  the Merchant (Financial Institution) may use the results of the
      authentication to identify not only the consumer but also the
      account from which the withdrawal is to be made. If no single
      account can be identified, then it must be obtained by other
      means. For example:

      -  the consumer could specify the account number prior to the
         Baseline Withdrawal IOTP Transaction starting, or

      -  the consumer could have been identified earlier, for example
         using a Baseline Authentication IOTP Transaction, and an
         account selected from a list provided by the Financial
         Institution.

   o  a Baseline Withdrawal without an authentication might be used:

      -  if a previous IOTP transaction, for example a Baseline Deposit
         or a Baseline Authentication, authenticated the consumer, and a
         secure channel has been maintained, therefore the authenticity
         of the consumer is known

      -  if authentication is achieved as part of a proprietary payment
         protocol and is therefore included in the Payment Document
         Exchange

      -  if authentication of the consumer has been achieved by some
         other means, for example, by using a pass phrase, or a
         proprietary banking software solution.

9.1.11 Baseline Value Exchange IOTP Transaction

   The Baseline Value Exchange Transaction uses Payment Document
   Exchanges to support the exchange of value in one currency obtained
   using one payment method with value in the same or another currency
   using the same or another payment method. Examples of its use
   include:

   o  electronic cash advance on a credit card. For example the first
      payment could be a "dollar SET Payment" using a credit card with
      the second payment being a download of Visa Cash e-cash in
      dollars.

   o  foreign exchange using the same payment method. For example the
      payment could be an upload of Mondex value in British Pounds and
      the second a download of Mondex value in Euros

Top      Up      ToC       Page 227 
   o  foreign exchange using different payment methods. For example the
      first payment could be a SET payment in Canadian Dollars followed
      a download of GeldKarte in Deutchmarks.

   The Baseline Value Exchange uses the following Document Exchanges:

   o  an optional Authentication Document Exchange (see section 9.1.1)

   o  an Offer Document Exchange (see section 9.1.2), which provides
      details of what values and currencies will be exchanged, and

   o  two Payment Document Exchanges (see section 9.1.3) which carry out
      the two payments involved.

   The way in which these Document Exchanges may be combined together is
   illustrated by the diagram below.

Top      Up      ToC       Page 228 
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

   START -----------------------------------------------------
      |                                                         v
      |                                                ----------------
      |                                               | AUTHENTICATION |
      |                                                ----------------
       --------------------------------------               |
                       |                     |              |
                       |      -------------- | -------------
                       v      v              v      v
                  -------------------     -----------------
                 | BRAND INDEPENDENT |   | BRAND DEPENDENT |
                 |       OFFER       |   |      OFFER      |
                  -------------------     -----------------
                        |                        |
                        |                        |
                        |                        |
                        |     -------------------
                        v    v
                      ---------           --------------
                     | PAYMENT |         | PAYMENT WITH |
                     | (first) |         |   DELIVERY   |
                      ---------           --------------
                          |
                           ----
                               v
         ----------        ---------
        | DELIVERY |      | PAYMENT |
        |          |      | {second)|
         ----------        ---------
                               |
                                -----------------------------> STOP

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

               Figure 29 Baseline Value Exchange IOTP Transaction

Top      Up      ToC       Page 229 
   The Baseline Value Exchange IOTP Transaction occurs in two basic
   forms:

   o  Brand Dependent Value Exchange. Where the content of the offer,
      for example the rate at which one form of value is exchanged for
      another, is dependent on the payment brands and protocols selected
      by the consumer, and

   o  Brand Independent Value Exchange. Where the content of the offer
      is not dependent on the payment brands and protocols selected.

   Note: In the above the role is a Merchant even though the
   Organisation carrying out the Value Exchange may be a Bank or some
   other Financial Institution. This is because the Bank is acting as a
   merchant in that they are making an offer which the Consumer can
   either accept or decline.

   The TPO Block and Offer Response Block may only be combined into the
   same IOTP Message if the content of the Offer Response Block does not
   change as a result of selecting the payment brands and payment
   protocols to be used in the Value Exchange.

   BASELINE VALUE EXCHANGE SIGNATURES

   The use of signatures to ensure the integrity of a Baseline Value
   Exchange is illustrated by the diagram below.

Top      Up      ToC       Page 230 
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

Signature generated                  IotpMsg (TPO)
by Merchant ensures                  - Trans Ref Block
integrity of the Offer -------->  -  - Signature Block
                                 |   - TPO Block              MERCHANT
                                 |   - Offer Response Block
                                 |
Signature generated by           |
the Payment Handler of           |   IotpMsg (Pay Resp 1)
the first payment binds          |   - Trans Ref Block         PAYMENT
Pay Receipt for the first ----->  -> - Signature Block -----   HANDLER
payment to the Offer                 - Pay Response Block 1 |    1
                                                            |
Signature generated by                                      |
the Payment Handler of           IotpMsg (Pay Resp 2)       |  PAYMENT
the second payment binds           - Trans Ref Block        |  HANDLER
the second payment to the ----->   - Signature Block <------     2
first payment and therefore        - Pay Response Block 2
to the Offer

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

              Figure 30 Baseline Value Exchange Signatures

9.1.12 Valid Combinations of Document Exchanges

   The following diagram illustrates the data conditions in the various
   IOTP messages which can be used by a Consumer Trading Role to
   determine whether the combination of Document Exchanges are valid.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

   START
     |
     v
   Auth Request Block in  =TRUE
    first IOTP Message ? ---------------------------------------
      | = FALSE                                                 |
      v                                                         v
   Offer Response Block in                             ----------------
     first IOTP Message ?                             | AUTHENTICATION |
      |=TRUE         |=FALSE                           ----------------
      |              |                                        |
      |              |                                        v

Top      Up      ToC       Page 231 
      |                ----------------------       TPO & Offer Response
       -------------                         |   Blocks in last IOTP Msg
                    |                        |     |=TRUE        |=FALSE
                    |                        |     |             v
                    |          ------------- | ----    TPO Block only if
                    |         |              |         last IOTP Message
                    |         |              |         of Authentication
                    |         |              |          |=TRUE   |=FALSE
                    v         v              v          v        |
                  -------------------     -----------------      |
                 | BRAND INDEPENDENT |   | BRAND DEPENDENT |     |
                 |       OFFER       |   |      OFFER      |     |
                  -------------------     -----------------      |
                          |                   |                  |
                          v                   v                  |
                       Offer Response Block contains             |
                             Delivery Component ?                |
                            |=FALSE        |=TRUE                |
                         ---               v                     |
                        |        Value of DelivAndPayResp        |
                        |    attribute of Delivery Component ?   |
                        |    |=FALSE         |=TRUE              |
                        |    |               |                   |
                        v    v               v                   |
                      ---------           --------------         |
                     | PAYMENT |         | PAYMENT WITH |        |
                     | (first) |         |   DELIVERY   |        |
                      ---------           --------------         |
                          |                      |               |
                          v                      |               |
            Offer and Response Block contains     -------------->|
                  Delivery Component ?                           |
                  |=TRUE           |=FALSE                       |
                  |                v                             |
                  |         Two Payment Components               |
                  |      present in Offer Response Block?        |
                  |           |=TRUE             |=FALSE         |
                  v           v                  |               |
         ----------        ---------             |               |
        | DELIVERY |      | PAYMENT |            |               |
        |          |      | {second)|            |               |
         ----------        ---------             |               |
              |                |                 |               v
               ----------------------------------------------> STOP

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

               Figure 31 Valid Combinations of Document Exchanges

Top      Up      ToC       Page 232 
   1) If first IOTP Message of an IOTP Transaction contains an
      Authentication Request then:

      a) IOTP Transaction includes an Authentication Document Exchange
         (see section 9.1.1). (Note 1)

      b) If the last IOTP Message of the Authentication Document
         Exchange includes a TPO Block and an Offer Response Block then:

         i) IOTP Transaction includes a Brand Independent Offer Document
            Exchange (see section 9.1.2.2). (Note 2)

      c) Otherwise, if the last IOTP Message of the Authentication
         Exchange includes a TPO Block but NO Offer Response Block,
         then:

         i) IOTP Transaction includes a Brand Dependent Offer Document
            Exchange (see section 9.1.2.1). (Note 2)

      d) Otherwise (Authentication Status IOTP Message of the
         Authentication Document Exchange contains neither a TPO Block
         but nor an Offer Response Block)

         i) IOTP Transaction consists of just an Authentication Document
            Exchange. (Note 3)

   2) Otherwise (no Authentication Request in first IOTP Message):

      e) IOTP Transaction does not include an Authentication Document
         Exchange (Note 2)

      f) If first IOTP Message contains an Offer Response Block, then:

         i) the IOTP Transaction contains a Brand Independent Offer
            Document Exchange (Note 2)

      g) Otherwise (no Offer Response Block in first IOTP Message):

         i) the IOTP Transaction includes a Brand Dependent Offer
            Document Exchange (Note 2)

   3) If an Offer Response Block exists in any IOTP message then:

      h) If the Offer Response Block contains a Delivery Component then:

         i) If the DelivAndPayResp attribute of the Delivery Component
            is set to True, then:

Top      Up      ToC       Page 233 
            (1) the IOTP Transaction consists of a Payment And Delivery
                Document Exchange (see section 9.1.5) (Note 4)

        ii) otherwise (the DelivAndPayResp attribute of the Delivery
            Component is set to False)

            (1) the IOTP Transaction consists of a Payment Document
                Exchange (see section 9.1.3) followed by a Delivery
                Document Exchange (see section 9.1.4) (Note 4)

      i) otherwise (the Offer Response Block does not contain a Delivery
         Component)

         i) if the Offer Response Block contains just one Payment
            Component, then:

            (1) the IOTP Transaction contains just one Payment Document
                Exchange (Note 5)

        ii) if the Offer Response Block contains two Payment Components,
            then:

            (1) the IOTP Transaction contains two Payment Document
                Exchanges.  The StartAfter attribute of the Payment
                Components is used to indicate which payment occurs
                first (Note 6)

       iii) if the Offer Response Block contains no or more than two
            Payment Components, then there is an error

   4) Otherwise (no Offer Response Block) there is an error.

   The following table indicates the types of IOTP Transactions which
   can validly have the conditions indicated above.

   Note                     IOTP Transaction Validity

   1. Any Payment and Authentication IOTP Transaction

   2. Any Payment and Authentication IOTP Transaction except Baseline
      Authentication

   3. Either Baseline Authentication, or a Baseline Purchase, Refund,
      Deposit, Withdrawal or Value Exchange with a failed Authentication

   4. Baseline Purchase only

   5. Baseline Purchase, Refund, Deposit or Withdrawal

Top      Up      ToC       Page 234 
   6. Baseline Value Exchange only

9.1.13 Combining Authentication Transactions with other Transactions

   In the previous sections an Authentication Document Exchange is shown
   preceding an Offer Document Exchange as part of a single IOTP
   Transaction with the same IOTP Transaction Id.

   It is also possible to run a separate Authentication Transaction at
   any point, even in parallel with another IOTP Transaction. Typically
   this will be used:

   o  by a Consumer to authenticate a Merchant, Payment Handler or a
      Delivery Handler, or

   o  by a Payment Handler or Delivery Handler to authenticate a
      Consumer.

   In outline the basic process consists of:

   o  the Trading Role that decides it wants to carry out an
      authentication of another role suspends the current IOTP
      transaction being carried out

   o  a stand-alone Authentication transaction is then carried out. This
      may, at implementer's option, be linked to the original IOTP
      Transaction using a Related To Component (see section 3.3.3) in
      the Transaction Reference Block.

   o  if the Authentication transaction is successful, then the original
      IOTP Transaction is restarted

   o  if the Authentication fails then the original IOTP Transaction is
      cancelled.

   For example, a Consumer could:

   o  authenticate the Payment Handler for a Payment between receiving
      an Offer Response from a Merchant and before sending the Payment
      Request to that Payment Handler

   o  authenticate a Delivery Handler for a Delivery between receiving
      the Payment Response from a Payment Handler and before sending the
      Delivery Request

   A Payment Handler could authenticate a Consumer after receiving the
   Payment Request and before sending the next Payment related message.

Top      Up      ToC       Page 235 
   A Delivery Handler could authenticate a Consumer after receiving the
   Delivery Request and before sending the Delivery Response.

   Note: Some Payment Methods may carry out an authentication within the
   Payment Exchange. In this case the information required to carry out
   the authentication will be included in Payment Scheme Components.

   In this instance IOTP aware application will not be aware that an
   authentication has occurred since the Payment Scheme Components that
   contain authentication request information will be indistinguishable
   from other Payment Scheme Components.

9.2 Infrastructure Transactions

   Infrastructure Transactions are designed to support inquiries about
   whether or not a transaction has succeeded or a Trading Role's
   servers are operating correctly. There are two types of transaction:

   o  a Transaction Status Inquiry Transaction which provides
      information on the status of an existing or complete IOTP
      transaction, and

   o  Ping Transaction that enables one IOTP aware application to
      determine if the IOTP aware application at another Trading Role is
      operating and verify whether or not signatures can be handled.

   Each of these is described below

9.2.1 Baseline Transaction Status Inquiry IOTP Transaction

   The Baseline IOTP Transaction Status Inquiry provides information on
   the status of an existing or complete IOTP transaction.

   The Trading Blocks used by the Baseline Transaction Status Inquiry
   Transaction are:

   o  an Inquiry Request Trading Block (see section 8.12),

   o  an Inquiry Response Trading Block (see section 8.13)

   o  an optional Signature Block (see section 8.16).

   The Inquiry IOTP Transaction can be used for a variety of reasons.
   For example:

   o  to help in resuming a suspended transaction to determine the
      current state of processing of one of the other roles,

Top      Up      ToC       Page 236 
   o  for a merchant to determine if a payment, delivery, etc., was
      completed.  For example, a Consumer might claim that payment was
      made but no signed IOTP payment receipt was available to prove it.
      If the Merchant makes an inquiry of the Payment Handler then the
      Merchant can determine whether or not payment was made.

   Note: Inquiries on Baseline Ping IOTP Transactions (see section
   9.2.2) are ignored.

   MAKING INQUIRIES OF ANOTHER TRADING ROLE

   One Trading Role may make an inquiry of any other Trading Role at any
   point in time.

   IOTP aware software that supports the Consumer Trading Role may not:

   o  digitally sign a response if requested, since it may not have the
      capability, or

   o  respond to an Inquiry Request at all since it may not be on-line,
      or may consider that the request is not reasonable since, for
      example, the Request was not digitally signed.

   As a guideline:

   o  the Consumer should send a Transaction Status Inquiry Block to a
      Trading Role only after the following events have occurred:

      - to the Merchant, after sending a TPO Selection Block,

      - to the Payment Handler, after sending a Payment Request Block,

      - to the Delivery Handler, after sending a Delivery Request Block,

   o  other Trading Roles should send a Transaction Status Inquiry Block
      to the Consumer only after receiving a message from the Consumer
      and before sending the final "Response" message to the Consumer

   o  there are no restrictions on non-Consumer Trading Roles sending
      Inquiries to other trading roles.

   TRANSACTION STATUS INQUIRY TRANSPORT SESSION

   For a Transaction Status Inquiry on an ongoing transaction a
   different transport session from the ongoing transaction is used. For
   a Transaction Status Inquiry on a past transaction, how the IOTP

Top      Up      ToC       Page 237 
   module on the software at the Trading Role is started upon the
   receipt of Inquiry Request message is defined in each Mapping to
   Transport supplement for IOTP.

   TRANSACTION STATUS INQUIRY ERROR HANDLING

   Errors in a Transaction Status Inquiry can be categorised into one of
   the following three cases:

   o  Business errors (see section 4.2) in the original (inquired)
      messages

   o  Technical errors (see section 4.1) - both IOTP and payment scheme
      specific ones - in the original IOTP (inquired) messages

   o  Technical errors in the message containing the Inquiry Request
      Block itself

   The following outlines what the software should do in each case

   BUSINESS ERRORS IN THE ORIGINAL MESSAGES

   Return an Inquiry Response Block containing the Status Component
   which was last sent to the Consumer Role.

   TECHNICAL ERRORS IN THE ORIGINAL MESSAGES

   Return an Inquiry Response Block containing a Status Component. The
   Status Component should contain a ProcessState attribute set to
   ProcessError. In this case send back an Error Block indicating where
   the error was found in the original message.

   TECHNICAL ERRORS IN THE INQUIRY REQUEST BLOCK

   Return an Error message. That is, send back an Error Block containing
   the Error Code (see section 7.21.2) which describes the nature of the
   error in the Inquiry Request message.

   INQUIRY TRANSACTION MESSAGES

   The following Figure outlines the Baseline IOTP Transaction Status
   Inquiry process.

Top      Up      ToC       Page 238 
 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

   1st Role
     |  2nd Role
STEP |     |
 1.          The first role decides to inquire on an IOTP Transaction
             by, for example, clicking on the inquiry button of an
             IOTP Aware Application. This will then generate an
             Inquiry Request Block and send it to the appropriate
             Trading Role.

     1 --> 2 INQUIRY REQUEST. IotpMsg: TransRef Block; Signature Block
             (optional); Inquiry Request Block

 2.          The Trading Role checks the digital signature (if
             present). If the recipient wants to respond, then the
             Trading Role checks the transaction status of the
             transaction that is being inquired upon by using the
             IotpTransId in the Transaction ID Component of the
             Transaction Reference Block, then generates the
             appropriate Inquiry Response Block, sends the message
             back to the 1st Role and stops

     1 <-- 2 INQUIRY RESPONSE. IotpMsg: TransRef Block; Inquiry
             Response Block; Signature Block (Optional)

3.           First role checks the Inquiry Response Block and optional
             signature, takes whatever action is appropriate or
             perhaps stops. This may include displaying status
             information to the end user.

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

                Figure 32 Baseline Transaction Status Inquiry


   The remainder of this sub-section on the Baseline Transaction Status
   Inquiry IOTP Transaction defines the contents of each Trading Block.
   Note that the term "original transaction" is the transaction which a
   trading role wants to discover some information about.

   TRANSACTION REFERENCE BLOCK

   A Trading Role making an inquiry must use a Transaction Id Component
   (see section 3.3.1) where both the IotpTransId and TransTimeStamp
   attributes are the same as in the Transaction Id Component of the
   original transaction that is being inquired upon. The IotpTransId
   attribute in this component serves as the key in querying the

Top      Up      ToC       Page 239 
   transaction logs maintained at the Trading Role's site. The value of
   the ID attribute of the Message Id Component should be different from
   those of any in the original transaction (see section 3.4.1).

   If up-to-date status information is required then the MsgId
   Component, and in particular the ID attribute for the MsgId Component
   must be different from any other IOTP Message that has been sent by
   the Trading Role. This is required because of the way that
   Idempotency is handled by IOTP (see section 4.5.2.2 Checking/Handling
   Duplicate Messages).

   INQUIRY REQUEST BLOCK

   The Inquiry Request Block (see section 8.12) contains the following
   components:

   o  one Inquiry Type Component (see section 7.18). This identifies
      whether the inquiry is on an offer, payment, or delivery.

   o  zero or one Payment Scheme Components (see section 7.10). This is
      for encapsulating payment scheme specific inquiry messages for
      inquiries on a payment.

   SIGNATURE BLOCK (INQUIRY REQUEST)

   If a signature block is present on the message containing the Inquiry
   Request Block then it may be checked to determine if the Inquiry
   Request is authorised.

   If present, the Inquiry Request Signature Block (see section 8.12)
   contains the following components:

   o  one Signature Component (see section 7.19)

   o  one or more Certificate Components, if required.

   Inquiry Response Blocks should only be generated if the Transaction
   is authorised.

   Note: Digital signatures on an Inquiry Request is only likely to
   occur if the recipient of the request expects the Inquiry Request to
   be signed. In this version of IOTP this will require some kind of
   pre-existing agreement. This means that:

   o  Consumers are unlikely to generate requests with signatures,
      although it is not an error if they do

Top      Up      ToC       Page 240 
   o  the other trading roles may agree that digital signatures are
      required. For example a Payment Handler may require that an
      Inquiry Request is digitally signed by the Merchant so that they
      can check that the request is valid.

   On the other hand if the original transaction to which the Inquiry
   relates was carried out over a secure channel (e.g., [SSL]) then it
   is probably reasonable to presume that if the sender of the Inquiry
   knows the Transaction Id component of the original message (including
   for example the timestamp) then the inquiry is likely to be genuine.

   INQUIRY RESPONSE BLOCK

   The Inquiry Response Block (see section 8.13) contains the following
   components:

   o  one Status Component (see section 7.16). This component holds the
      status information on the inquired transaction,

   o  zero or one Payment Scheme Components. These contain encapsulated
      payment scheme specific inquiry messages for inquiries on payment.

   SIGNATURE BLOCK (INQUIRY RESPONSE)

   If a signature block is present on the message containing the Inquiry
   Response Block then it may be checked by the receiver of the block to
   determine if the Inquiry Response is valid.

   If present, the Inquiry Response Signature Block (see section 8.13)
   contains the following components:

   o one Signature Component (see section 7.19)

   o one or more Certificate Components, if required.

   Note: Digital signatures on an Inquiry Response is only likely to
   occur if the recipient of the response expects the Inquiry Request to
   be signed. In this version of IOTP this will require some kind of
   pre-existing agreement. This means that:

   o  Consumers are unlikely to generate responses with signatures,
      although it is not an error if they do

   o  the other trading roles may agree that digital signatures are
      required. For example a Merchant may require that an Inquiry
      Response is digitally signed by the Payment Handler so that they
      can check that the request response is valid.


Next RFC Part