tech-invite   World Map     

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

RFC 2801

 
 
 

Internet Open Trading Protocol - IOTP Version 1.0

Part 6 of 9, p. 163 to 200
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 163 
8. Trading Blocks

   Trading Blocks are child elements of the top level IOTP Messages that
   are sent in the form of [XML] documents directly between the
   different Trading Roles that are taking part in a trade.

   Each Trading Blocks consist of one or more Trading Components (see
   section 7).  This is illustrated in the diagram below.

Top      Up      ToC       Page 164 
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

             IOTP MESSAGE  <-----------IOTP Message - an XML Document
              |                        which is transported between the
              |                        Trading Roles
              |-Trans Ref Block <----- Trans Ref Block - contains
              |  |                     information which describes the
              |  |                     IOTP Transaction and the IOTP
              |  |                     Message.
              |  |-Trans Id Comp. <--- Transaction Id Component -
              |  |                     uniquely identifies the IOTP
              |  |                     Transaction. The Trans Id
              |  |                     Components are the same across
              |  |                     all IOTP messages that comprise a
              |  |                     single IOTP transaction.
              |  |-Msg Id Comp. <----- Message Id Component - identifies
              |                        and describes an IOTP Message
              |                        within an IOTP Transaction
              |-Signature Block <----- Signature Block (optional) -
              |  |                     contains one or more Signature
              |  |                     Components and their associated
              |  |                     Certificates
              |  |-Signature Comp. <-- Signature Component - contains
              |  |                     digital signatures. Signatures
              |  |                     may sign digests of the Trans Ref
              |  |                     Block and any Trading Component
              |  |                     in any IOTP Message in the same
              |  |                     IOTP Transaction.
              |  |-Certificate Comp. <-Certificate Component. Used to
              |                        check the signature. (Optional)
      ------> |-Trading Block <--------Trading Block - an XML Element
     |        |  |-Trading Comp.       within an IOTP Message that
   Trading    |  |-Trading Comp.       contains a predefined set of
   Blocks     |  |-Trading Comp.       Trading Components
     |        |  |-Trading Comp.
     |        |  |-Trading Comp. <-----Trading Components - XML Elements
     |        |                        within a Trading Block that
      ------> |-Trading Block          contain a predefined set of XML
              |  |-Trading Comp.       elements and attributes
              |  |-Trading Comp.       containing information required
              |  |-Trading Comp.       to support a Trading Exchange
              |  |-Trading Comp.
              |  |-Trading Comp.
              |
   *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

                            Figure 16 Trading Blocks

Top      Up      ToC       Page 165 
   Trading Blocks are defined as part of the definition of an IOTP
   Message (see section 3.1.1). The definition of an IOTP Message
   element is repeated here:

   <!ELEMENT IotpMessage
      ( TransRefBlk,
        SigBlk?,
        ErrorBlk?,
        ( AuthReqBlk |
          AuthRespBlk |
          AuthStatusBlk |
          CancelBlk |
          DeliveryReqBlk |
          DeliveryRespBlk |
          InquiryReqBlk |
          InquiryRespBlk |
          OfferRespBlk |
          PayExchBlk |
          PayReqBlk |
          PayRespBlk |
          PingReqBlk |
          PingRespBlk |
          TpoBlk |
          TpoSelectionBlk
        )*
      ) >

   The remainder of this section defines the Trading Blocks in this
   version of IOTP. They are:

   o  Authentication Request Block

   o  Authentication Response Block

   o  Authentication Status Block

   o  Cancel Block

   o  Delivery Request Block

   o  Delivery Response Block

   o  Error Block

   o  Inquiry Request Block

   o  Inquiry Response Block

Top      Up      ToC       Page 166 
   o  Offer Response Block

   o  Payment Exchange Block

   o  Payment Request Block

   o  Payment Response Block

   o  Signature Block

   o  Trading Protocol Options Block

   o  TPO Selection Block

   The Transaction Reference Block is described in section 3.3.

8.1 Trading Protocol Options Block

   The TPO Trading Block contains options which apply to the IOTP
   Transaction. The definition of a TPO Trading Block is as follows.

   <!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* ) >
   <!ATTLIST TpoBlk
    ID                 ID      #REQUIRED >

   Attributes:

   ID                 An identifier which uniquely identifies the
                      Trading Protocol Options Block within the IOTP
                      Transaction (see section 3.4 ID Attributes).

   Content:

   ProtocolOptions    The Protocol Options Component (see section
                      7.1)defines the options which apply to the whole
                      IOTP Transaction (see section 9).

   BrandList          This Brand List Component contains one or more
                      payment brands and protocols which may be selected
                      (see section 7.7).

   Org                The Organisation Components (see section 7.6)
                      identify the Organisations and their roles in the
                      IOTP Transaction. The roles and Organisations
                      which must be present will depend on the
                      particular type of IOTP Transaction. See the
                      definition of each transaction in section 9.
                      Internet Open Trading Protocol Transactions.

Top      Up      ToC       Page 167 
   The TPO Block should contain:

   o  the Protocol Options Component

   o  the Organisation Component with the Trading Role of Merchant

   o  the Organisation Component with the Trading Role of Consumer

   o  optionally, the Organisation Component with the Trading Role of
      DeliverTo, if there is a Delivery included in the IOTP Transaction

   o  Brand List Components for each payment in the IOTP Transaction

   o  Organisation Components for all the Payment Handlers involved

   o  optionally, Organisation Components for the Delivery Handler (if
      any) for the transaction

   o  additional Organisation Components that the Merchant may want to
      include. For example

      -  a Customer Care Provider

      -  an Certificate Authority that offers Merchant "Credentials" or
         some other warranty on the goods or services being offered.

8.2 TPO Selection Block

   The TPO Selection Block contains the results of selections made from
   the options contained in the Trading Protocol Options Block (see
   section 8.1).The definition of a TPO Selection Block is as follows.

   <!ELEMENT TpoSelectionBlk (BrandSelection+) >
   <!ATTLIST TpoSelectionBlk
    ID                 ID      #REQUIRED >

   Attributes:

   ID                 An identifier which uniquely identifies the TPO
                      Selection Block within the IOTP Transaction.

   Content:

   BrandSelection     This identifies the choice of payment brand and
                      payment protocol to be used in a payment within
                      the IOTP Transaction. There is one Brand Selection
                      Component (see section 7.8) for each payment to be
                      made in the IOTP Transaction.

Top      Up      ToC       Page 168 
   The TPO Selection Block should contain one Brand Selection Component
   for each Brand List in the TPO Block.

8.3 Offer Response Block

   The Offer Response Block contains details of the goods, services,
   amount, delivery instructions or financial transaction which is to
   take place.  Its definition is as follows.

   <!ELEMENT OfferRespBlk (Status, Order?, Payment*,
                Delivery?, TradingRoleData*) >
   <!ATTLIST OfferRespBlk
    ID                 ID      #REQUIRED >

   Attributes:

   ID                 An identifier which uniquely identifies the Offer
                      Response Block within the IOTP Transaction.

   Content:

   Status             Contains status information about the business
                      success (see section 4.2) or failure of the
                      generation of the Offer. Note that in an Offer
                      Response Block, a ProcessState of NotYetStarted or
                      InProgress are illegal values.

   Order              The Order Component contains details about the
                      goods, services or financial transaction which is
                      taking place see section 7.5.

                      The Order Component must be present unless the
                      ProcessState attribute of the Status Component is
                      set to Failed.

   Payment            The Payment Components contain information about
                      the payments which are to be made see section 7.9.

   Delivery           The Delivery Component contains details of the
                      delivery to be made (see section 7.13).

   TradingRoleData    The Trading Role Data Component contains opaque
                      data which is needs to be communicated between the
                      Trading Roles involved in an IOTP Transaction (see
                      section 7.17).

   The Offer Response Block should contain:

Top      Up      ToC       Page 169 
   o  the Order Component for the IOTP Transaction

   o  Payment Components for each Payment in the IOTP Transaction

   o  the Delivery Component the IOTP Transaction requires (if any).

8.4 Authentication Request Block

   The Authentication Request Block contains the data which is used by
   one Trading Role to obtain information about and optionally
   authenticate another Trading Role.

   In outline it contains:

   o  information about how the authentication itself will be carried
      out, and/or

   o  a request for additional information about the Organisation being
      authenticated.

   Its definition is as follows.

   <!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?) >
   <!ATTLIST AuthReqBlk
    ID                 ID      #REQUIRED >

   Attributes:

   ID                 An identifier which uniquely identifies the
                      Authentication Request Block within the IOTP
                      Transaction.

   Content:

   AuthReq             Each Authentication Request (see section 7.2)
                       component describes an alternative way in which
                       the recipient of the Authentication Request may
                       authenticate themselves by generating an
                       Authentication Response Component (see section
                       7.3).

                       If one Authentication Request Component is
                       present then that Authentication Request
                       Component should be used.

Top      Up      ToC       Page 170 
                       If more than one Authentication Request Component
                       is present then the recipient should choose one
                       of the components based on personal preference of
                       the recipient or their software.

                       If no Authentication Request Component is present
                       it means that the Authentication Request Block is
                       requesting the return of Organisation Components
                       as specified in the Trading Role Information
                       Request Component.

   TradingRoleInfoReq  The Trading Role Information Request Component
                       (see section 7.4) contains a list of Trading
                       Roles about which information is being requested

   There must be at least one Component (either an Authentication
   Request or a Trading Role Information Request) within the
   Authentication Block otherwise it is an error.

8.5 Authentication Response Block

   The Authentication Response Block contains the response which results
   from processing the Authentication Request Block. Its definition is
   as follows.

   <!ELEMENT AuthRespBlk (AuthResp?, Org*) >
   <!ATTLIST AuthRespBlk
    ID                 ID      #REQUIRED >

   Attributes:

   ID                 An identifier which uniquely identifies the
                      Authentication Response Block within the IOTP
                      Transaction.

   Content:

   AuthResp           The optional Authentication Response Component
                      which contains the results of processing the
                      Authentication Request Component - see section
                      7.3.

   Org                Optional Organisation Components that contain
                      information corresponding to the Trading Roles as
                      requested by the TradingRoleList attribute of the
                      Trading Role Information Request component.

Top      Up      ToC       Page 171 
   The components present in the Authentication Response Block must
   match the requirement of the corresponding Authentication Request
   Block otherwise it is an error.

8.6 Authentication Status Block

   The Authentication Status Block indicates the success or failure of
   the validation of an Authentication Response Block by an
   Authenticator. Its definition is as follows.

   <!ELEMENT AuthStatusBlk (Status) >
   <!ATTLIST AuthStatusBlk
    ID                 ID      #REQUIRED >

   Attributes:

   ID                 An identifier which uniquely identifies the
                      Authentication Status Block within the IOTP
                      Transaction.

   Content:

   Status             Contains status information about the business
                      success (see section 4.2) or failure of the
                      authentication

8.7 Payment Request Block

   The Payment Request Block contains information which requests that a
   payment is started. Its definition is as follows.

   <!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection,
        Payment, PaySchemeData?, Org*, TradingRoleData*) >
   <!ATTLIST PayReqBlk
    ID                 ID      #REQUIRED >

   Attributes:

   ID                 An identifier which uniquely identifies the
                      Payment Request Block within the IOTP Transaction.

   Content:

   Status             Contains the Status Components (see section 7.13)
                      of the responses of the steps (e.g., an Offer
                      Response and/or a Payment Response) on which this

Top      Up      ToC       Page 172 
                      step depends. It is used to indicate the success
                      or failure of those steps. Payment should only
                      occur if the previous steps were successful.

   BrandList          The Brand List Component contains a list of one or
                      more payment brands and protocols which may be
                      selected (see section 7.7).

   BrandSelection     This identifies the choice of payment brand, the
                      payment protocol and the Payment Handler to be
                      used in a payment within the IOTP Transaction.
                      There is one Brand Selection Component (see
                      section 7.8) for each payment to be made in the
                      IOTP Transaction.

   Payment            The Payment Components contain information about
                      the payment which is being made see section 7.9.

   PaySchemeData      The Payment Scheme Component contains payment
                      scheme specific data see section 7.10.

   Org                The Organisation Component contains details of
                      Organisations involved in the payment (see section
                      7.6). The Organisations present are dependent on
                      the IOTP Transaction and the data which is to be
                      signed. See section 6 Digital Signatures for more
                      details.

   TradingRoleData    The Trading Role Data Component contains opaque
                      data which is needs to be communicated between the
                      Trading Roles involved in an IOTP Transaction (see
                      section 7.17).

   The Payment Request Block should contain:

   o  the Organisation Component with a Trading Role of Merchant

   o  the Organisation Component with the Trading Role of Consumer

   o  the Payment Component for the Payment

   o  the Brand List Component for the Payment

   o  the Brand Selection Component for the Brand List

   o  the Organisation Component for the Payment Handler of the Payment

Top      Up      ToC       Page 173 
   o  the Organisation Component (if any) for the Organisation which
      carried out the previous step, for example another Payment Handler

   o  the Organisation Component for the Organisation which is to carry
      out the next step, if any. This may be, for example, either a
      Delivery Handler or a Payment Handler.

   o  the Organisation Components for any additional Organisations that
      the Merchant has included in the Offer Response Block

   o  an Optional Payment Scheme Data Component, if required by the
      Payment Method as defined in the IOTP supplement for the payment
      method

   o  any Trading Role Data Components that may be required (see section
      7.17.1).

8.8 Payment Exchange Block

   The Payment Exchange Block contains payment scheme specific data
   which is exchanged between two of the roles in a trade. Its
   definition is as follows.

   <!ELEMENT PayExchBlk (PaySchemeData+) >
   <!ATTLIST PayExchBlk
    ID                 ID      #REQUIRED >

   Attributes:

   ID                 An identifier which uniquely identifies the
                      Payment Exchange Block within the IOTP
                      Transaction.

   Content:

   PaySchemeData      This Trading Component contains payment scheme
                      specific data see section 7.10 Payment Scheme
                      Component.

8.9 Payment Response Block

   This Payment Response Block contains a information about the Payment
   Status, an optional Payment Receipt, and an optional payment protocol
   message. Its definition is as follows.

Top      Up      ToC       Page 174 
   <!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,
        PaymentNote?, TradingRoleData*) >
   <!ATTLIST PayRespBlk
    ID                 ID      #REQUIRED >

   Attributes:

   ID                 An identifier which uniquely identifies the
                      Payment Response Block within the IOTP
                      Transaction.

   Content:

   Status             Contains status information about the business
                      success (see section 4.2) or failure of the
                      payment. Note that in a Pay Response Block, a
                      ProcessState of NotYetStarted or InProgress are
                      illegal values.

   PayReceipt         Contains payment scheme specific data which can be
                      used to verify the payment occurred. See section
                      7.11 Payment Receipt Component. It must be present
                      if the ProcessState attribute of the Status
                      Component is set to CompletedOk. PayReceipt is
                      optional for other values as specified by the
                      appropriate Payment Scheme supplement.

   PaySchemeData      Contains payment scheme specific data see section,
                      for example a payment protocol message. See 7.10
                      Payment Scheme Component.

   PaymentNote        Contains additional, non payment related,
                      information which the Payment Handler wants to
                      provide to the Consumer. For example, if a
                      withdrawal or deposit were being made then it
                      could contain information on the remaining balance
                      on the account after the transfer was complete.
                      See section 7.12 Payment Note Component.

   TradingRoleData    The Trading Role Data Component contains opaque
                      data which is needs to be communicated between the
                      Trading Roles involved in an IOTP Transaction (see
                      section 7.17).

Top      Up      ToC       Page 175 
8.10 Delivery Request Block

   The Delivery Request Block contains details of the goods or services
   which are to be delivered together with a signature which can be used
   to check that delivery is authorised. Its definition is as follows.

   <!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
        ConsumerDeliveryData?, TradingRoleData*) >
   <!ATTLIST DeliveryReqBlk
    ID                 ID      #REQUIRED >

   Attributes:

   ID                 An identifier which uniquely identifies the
                      Delivery Request Block within the IOTP
                      Transaction.

   Content:

   Status                Contains the Status Components (see section
                         7.13) of the responses of the steps (e.g., a
                         Payment Response) on which this step is
                         dependent. It is used to indicate the success
                         or failure of those steps. Delivery should only
                         occur if the previous steps were successful.

   Order                 The Order Component contains details about the
                         goods, services or financial transaction which
                         is taking place see section 7.5.

                         The Organisation Components (see section 7.6)
                         identify the Organisations and their roles in
   Org                   the IOTP Transaction. The roles and
                         Organisations which must be present will depend
                         on the particular type of IOTP Transaction. See
                         the definition of each transaction in section
                         9. Internet Open Trading Protocol Transactions.

   Delivery              The Delivery Component contains details of the
                         delivery to be made (see section 7.13).

   ConsumerDeliveryData  Optional. Contains an identifier specified by
                         the Consumer which, if returned by the Delivery
                         Handler will enable the Consumer to identify
                         which Delivery is being referred to.

Top      Up      ToC       Page 176 
   TradingRoleData       The Trading Role Data Component contains opaque
                         data which is needs to be communicated between
                         the Trading Roles involved in an IOTP
                         Transaction (see section 7.17).

   The Delivery Request Block contains:

   o  the Organisation Component with a Trading Role of Merchant

   o  the Organisation Component for the Consumer and DeliverTo Trading
      Roles

   o  the Delivery Component for the Delivery

   o  the Organisation Component for the Delivery Handler. Specifically
      the Organisation Component identified by the ActionOrgRef
      attribute on the Delivery Component

   o  the Organisation Component (if any) for the Organisation which
      carried out the previous step, for example a Payment Handler

   o  the Organisation Components for any additional Organisations that
      the Merchant has included in the Offer Response Block

   o  any Trading Role Data Components that may be required (see section
      7.17.1).

8.11 Delivery Response Block

   The Delivery Response Block contains a Delivery Note containing
   details on how the goods will be delivered. Its definition is as
   follows. Note that in a Delivery Response Block a Delivery Status
   Element with a DeliveryStatusCode of NotYetStarted or InProgress is
   invalid.

   <!ELEMENT DeliveryRespBlk (Status, DeliveryNote) >
   <!ATTLIST DeliveryRespBlk
    ID                 ID      #REQUIRED >

   Attributes:

   ID                 An identifier which uniquely identifies the
                      Delivery Response Block within the IOTP
                      Transaction.

   Content:

Top      Up      ToC       Page 177 
   Status             Contains status information about the business
                      success (see section 4.2) or failure of the
                      delivery.  Note that in a Delivery Response Block,
                      a ProcessState of NotYetStarted or InProgress are
                      illegal values.

   DeliveryNote       The Delivery Note Component contains details about
                      how the goods or services will be delivered (see
                      section 7.15).

8.12 Inquiry Request Trading Block

   The Inquiry Request Trading Block contains an Inquiry Type Component
   and an optional Payment Scheme Component to contain payment scheme
   specific inquiry messages.

   <!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) >
   <!ATTLIST InquiryReqBlk
    ID                 ID      #REQUIRED >

   Attributes:

   ID                 An identifier which uniquely identifies the
                      Inquiry Request Trading Block within the IOTP
                      Transaction.

   Content:

   InquiryType        Inquiry Type Component (see section 7.18) that
                      contains the type of inquiry.

   PaySchemeData      Payment Scheme Component (see section 7.10) that
                      contains payment scheme specific inquiry messages
                      for inquiries on payments. This is present when
                      the Type attribute of Inquiry Type Component is
                      Payment.

8.13 Inquiry Response Trading Block

   The Inquiry Response Trading Block contains a Status Component and an
   optional Payment Scheme Component to contain payment scheme specific
   inquiry messages. Its purpose is to enquire on the current status of
   an IOTP transaction at a server.

Top      Up      ToC       Page 178 
   <!ELEMENT InquiryRespBlk (Status, PaySchemeData?) >
   <!ATTLIST InquiryRespBlk
    ID                 ID      #REQUIRED
    LastReceivedIotpMsgRef NMTOKEN #IMPLIED
    LastSentIotpMsgRef  NMTOKEN #IMPLIED >

   Attributes:

   ID                      An identifier which uniquely identifies the
                           Inquiry Response Trading Block within the
                           IOTP Transaction.

   LastReceivedIotpMsgRef  Contains an Element Reference (see section
                           3.5) to the Message Id Component (see section
                           3.3.2) of the last message this server has
                           received from the Consumer. If there is no
                           previously received message from the Consumer
                           in the pertinent transaction, this attribute
                           should be contain the value Null. This
                           attribute exists for debugging purposes.

   LastSentIotpMsgRef      Contains an Element Reference (see section
                           3.5) to the Message Id Component (see section
                           3.3.2) of the last message this server has
                           sent to the Consumer. If there is no
                           previously sent message to the Consumer in
                           the pertinent transaction, this attribute
                           should contain the value Null. This attribute
                           exists for debugging purposes.

   Content:

   Status             Contains status information about the business
                      success (see section 4.2) or failure of a certain
                      trading exchange (i.e., Offer, Payment, or
                      Delivery).

   PaySchemeData      Payment Scheme Component (see section 7.10) that
                      contains payment scheme specific inquiry messages
                      for inquiries on payments. This is present when
                      the Type attribute of StatusType attribute of the
                      Status Component is set to Payment.

Top      Up      ToC       Page 179 
8.14 Ping Request Block

   The Ping Request Block is used to determine if a Server is operating
   and whether or not cryptography is compatible.

   The definition of a Ping Request Block is as follows.

   <!ELEMENT PingReqBlk (Org*)>
   <!ATTLIST PingReqBlk
    ID                 ID      #REQUIRED>

   Attributes:

   ID                 An identifier which uniquely identifies the Ping
                      Request Trading Block within the IOTP Transaction.

   Content:

   Org                Optional Organisation Components (see section
                      7.6).

                      If no Organisation Component is present then the
                      Ping Request is anonymous and simply determines if
                      the server is operating.

                      However if Organisation Components are present,
                      then it indicates that the sender of the Ping
                      Request wants to verify that digital signatures
                      can be handled.

                      In this case the sender includes:
                       o an Organisation Component that identifies
                         itself specifying the Trading Role(s) it is
                         taking in IOTP transactions (Merchant, Payment
                         Handler, etc.)
                       o an Organisation Component that identifies the
                         intended recipient of the message.

                      These are then used to generate a signature over
                      the Ping Response Block.

8.15 Ping Response Block

   The Ping Response Trading Block provides the result of a Ping
   Request.

   It contains an Organisation Component that identifies the sender of
   the Ping Response.

Top      Up      ToC       Page 180 
   If the Ping Request to which this block is a response contained
   Organisation Components, then it also contains those Organisation
   Components.

   <!ELEMENT PingRespBlk (Org+)>
   <!ATTLIST PingRespBlk
    ID                 ID      #REQUIRED
    PingStatusCode (Ok | Busy | Down) #REQUIRED
    SigVerifyStatusCode (Ok | NotSupported | Fail) #IMPLIED
    xml:lang           NMTOKEN #IMPLIED
    PingStatusDesc     CDATA   #IMPLIED>

   Attributes:

   ID                   An identifier which uniquely identifies the Ping
                        Request Trading Block within the IOTP
                        Transaction.

   PingStatusCode       Contains a code which shows the status of the
                        sender software which processes IOTP messages.
                        Valid values are:
                         o Ok. Everything with the service is working
                          normally, including the signature
                          verification.
                         o Busy. Things are working normally but there
                          may be some delays.
                         o Down. The server is not functioning fully but
                          can still provide a Ping response.

   SigVerifyStatusCode  Contains a code which shows the status of
                        signature verification. This is present only
                        when the message containing the Ping Request
                        Block also contains a Signature Block. Valid
                        values are:
                         o Ok. The signature has successfully been
                          verified and proved compatible.
                         o NotSupported The receiver of this Ping
                          Request Block does not support validation of
                          signatures.
                         o Fail. Signature verification failed.

   Xml:lang             Defines the language used in PingStatusDesc.
                        This is present when PingStatusDesc is present.

   PingStatusDesc       Contains a short description of the status of
                        the server which sends this Ping Response Block.
                        Servers, if their designers want, can use this

Top      Up      ToC       Page 181 
                        attribute to send more refined status
                        information than PingStatusCode which can be
                        used for debugging purposes, for example.

   Content:

   Org                These are Organisation Components (see section
                      7.6).

                      The Organisation Components of the sender of the
                      Ping Response is always included in addition to
                      the Organisation Components sent in the Ping
                      Request.

   Note: Ping Status Code values do not include a value such as Fail,
   since, when the software receiving the Ping Request message is not
   working at all, no Ping Response message will be sent back.

8.16 Signature Block

   The Signature Block contains one or more Signature Components and
   associated Certificates (if required) which sign data associated with
   the IOTP Transaction. For a general discussion and introduction to
   how IOTP uses signatures, see section 6 Digital Signatures. The
   definition of the Signature Component and certificates is contained
   in the paper "Digital Signatures for the Internet Open Trading
   Protocol", see [IOTPDSIG].  Descriptions of how these are used by
   IOTP is contained in sections 7.19 and 7.20.

   The definition of a Signature Block is as follows:

   <!ELEMENT IotpSignatures (Signature+, Certificate*) >
   <!ATTLIST IotpSignatures
     ID                ID      #IMPLIED >

   Attributes:

   ID                 An identifier which uniquely identifies the
                      Signature Block within the IOTP Transaction.

   Content:

   Signature          A Signature Component. See section 7.19.

   Certificate        A Certificate Component. See section 7.20.

Top      Up      ToC       Page 182 
   The contents of a Signature Block depends on the Trading Block that
   is contained in the same IOTP Message as the Signature Block.

8.16.1 Signature Block with Offer Response

   A Signature Block which is in the same message as an Offer Response
   Block contains just an Offer Response Signature Component (see
   section 7.19.2).

8.16.2 Signature Block with Payment Request

   A Signature Block which is in the same message as a Payment Request
   Block contains:

   o  an Offer Response Signature Component (see section 7.19.2), and

   o  if the Payment is dependent on an earlier step (as indicated by
      the StartAfter attribute on the Payment Component), then the
      Payment Receipt Signature Component (see section 7.19.3) generated
      by the previous step

8.16.3 Signature Block with Payment Response

      A Signature Block which is in the same message as a Payment
      Response Block contains just a Payment Receipt Signature Component
      (see section 7.19.3) generated by the step.

8.16.4 Signature Block with Delivery Request

      A Signature Block which is in the same message as a Delivery
      Request Block contains:

   o  an Offer Response Signature Component (see section 7.19.2), and

   o  the Payment Receipt Signature Component (see section 7.19.3)
      generated by the previous step.

8.16.5 Signature Block with Delivery Response

   A Signature Block which is in the same message as a Delivery Response
   Block contains just a Delivery Response Signature component (see
   section 7.19.4) generated by the step.

Top      Up      ToC       Page 183 
8.17 Error Block

   The Error Trading Block contains one or more Error Components (see
   section 7.21) which contain information about Technical Errors (see
   section 4.1) in an IOTP Message which has been received by one of the
   Trading Roles involved in the trade.

   For clarity two phrases are defined which are used in the description
   of an Error Trading Block:

   o  message in error. An IOTP message which contains or causes an
      error of some kind

   o  message reporting the error. An IOTP message that contains an
      Error Trading Block that describes the error found in a message in
      error.

   An Error Trading Block may be contained in any message reporting the
   error. The action which then follows depends on the severity of the
   error. See the definition of an Error Component, for an explanation
   of the different types of severity and the actions which can then
   occur.

   in3 Note: Although, an Error Trading Block can report multiple
   different errors using multiple Error Components, there is no
   obligation on a developer of an IOTP Aware Application to do so.

   The structure of an Error Trading Block is as follows.

   <!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) >
   <!ATTLIST ErrorBlk
    ID                 ID      #REQUIRED >

   Attributes:

   ID                 An identifier which uniquely identifies the Error
                      Trading Block within the IOTP Transaction.

   Content:

   ErrorComp          An Error Components (see section 7.21) that
                      contains information about an individual Technical
                      Error.

   PaySchemeData      An optional Payment Scheme Component (see section
                      7.10) which contains a Payment Scheme Message. See
                      the appropriate payment scheme supplement to

Top      Up      ToC       Page 184 
                      determine whether or not this component needs to
                      be present and for the definition of what it must
                      contain.

8.18 Cancel Block

   The Cancel Block is used by one Trading Role to inform any other that
   a transaction has been cancelled. Example usage includes:

   o  a Consumer Role informing a non-Consumer role that it no longer
      plans to continue with the transaction. This will allow the server
      to close down the transaction tidily without a waiting for a
      time-out to occur

   o  a non-Consumer Role to inform a Consumer role that the Transaction
      is being stopped. In this case, the Consumer is then unlikely to
      re-send the previous message that was sent in the mistaken
      understanding that the original was not received.

   Its definition is as follows.

   <!ELEMENT CancelBlk (Status) >
   <!ATTLIST CancelBlk
    ID                 ID      #REQUIRED >

   Attributes:

   ID                 An identifier which uniquely identifies the Cancel
                      Block within the IOTP Transaction.

   Content:

   Status             Contains status information indicating that the
                      IOTP transaction has been cancelled.

9. Internet Open Trading Protocol Transactions

   The Baseline Internet Open Trading Protocol supports three types of
   transactions for different purposes. These are

   o  an Authentication IOTP transaction which supports authentication
      of one party in a trade by another and/or requests information
      about another Trading Role

Top      Up      ToC       Page 185 
   o  IOTP Transactions that involve one or more payments. Specifically:

      -  Deposit

      -  Purchase

      -  Refund

      -  Withdrawal, and

      -  Value Exchange

   o  IOTP Transactions designed to check the correct function of the
      IOTP infrastructure. Specifically:

      -  Transaction Status Inquiry, and

      -  Ping

   Although the Authentication IOTP Transaction can operate on its own,
   authentication can optionally precede any of the "payment"
   transactions.  Therefore, the rest of this section is divided into
   two parts covering:

   o  Authentication and Payment transactions (Authentication, Deposit,
      Purchase, Refund, Withdrawal and Value Exchange)

   o  Infrastructure Transactions (Transaction Status Inquiry and Ping)
      that are designed to support inquiries on whether or not a
      transaction has succeeded or a Trading Role's servers are
      operating correctly, and

9.1 Authentication and Payment Related IOTP Transactions

      The Authentication and Payment related IOTP Transactions consist
      of six Document Exchanges which are then combined in sequence to
      implement a specific transaction.

      Generally, there is a close, but not exact, correspondence between
      a Document Exchange and a Trading Exchange. The main difference is
      that some Document Exchanges implement part or all of two Trading
      Exchanges simultaneously in order to minimise the number of actual
      IOTP Messages which must be sent over the Internet.

      The six Document Exchanges are:

   o  Authentication. This is a direct implementation of the
      Authentication Trading Exchange

Top      Up      ToC       Page 186 
   o  Brand Dependent Offer. This is the Offer Trading Exchange combined
      with the Brand Selection part of the Payment Trading Exchange. Its
      purpose is to provide the Merchant with information on the Brand
      selected so that the content of the Offer Response may be adapted
      accordingly

   o  Brand Independent Offer. This is also an Offer Trading Exchange.
      However, in this instance, the content of the Offer Response does
      not depend on the Brand selected.

   o  Payment. This is a direct implementation of the Payment part of a
      Payment Trading Exchange

   o  Delivery. This is a direct implementation of the Delivery Exchange

   o  Delivery with Payment. This is an implementation of combined
      Payment and Delivery Trading Exchanges

   These Document Exchanges are combined together in different sequences
   to implement each IOTP Transaction. The way in which they may be
   combined is illustrated by the diagram below.

Top      Up      ToC       Page 187 
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

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

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

         Figure 17 Payment and Authentication Message Flow Combinations

   The combinations of Document Exchanges that are valid depend on the
   particular IOTP transaction.

   The remainder of this sub-section describes:

   o  each Document Exchange in more detail including descriptions of
      the content of each Trading Block in the Document Exchanges, and

   o  descriptions of how each IOTP Transaction uses the Document
      Exchanges to effect the desired result.

Top      Up      ToC       Page 188 
   Note: The descriptions of the Document Exchanges which follow
   describe the ways in which various Business Errors (see section 4.2)
   are handled. No reference is made however to the handling of
   Technical Errors (see section 4.1) in any of the messages since these
   are handled the same way irrespective of the context in which the
   message is being sent. See section 4 for more details.

9.1.1 Authentication Document Exchange

   The Authentication Document Exchange is a direct implementation of
   the Authentication Trading Exchange (see section 2.2.4). It involves:

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

   o  an Authenticatee - the Organisation being authenticated.

   The authentication consists of:

   o  an Authentication Request being sent by the Authenticator to the
      Authenticatee,

   o  an Authentication Response being sent in return by the
      Authenticatee to the Authenticator which is then checked, and

   o  an Authentication Status being sent by the Authenticator to the
      Authenticatee to provide an indication of the success or failure
      of the authentication.

   An Authentication Document Exchange also:

   o  provides an Authenticatee with an Organisation Component which
      describes the Authenticator, and

   o  optionally provides the Authenticator with Organisation Components
      which describe the Authenticatee.

   The Authentication Request may also be digitally signed which allows
   the Authenticatee to verify the credentials of the Authenticator.

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

Top      Up      ToC       Page 189 
 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
 Organisation 1
 (Authenticatee)
     |   Organisation 2
     |  (Authenticator)
STEP |     |
 1.          First Organisation takes an action (for example by
             pressing a button on an HTML page) which requires that
             the Organisation is authenticated

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

 2.          The second Organisation generates: an Authentication
             Request Block containing one or more Authentication
             Request Components and/or a Trading Role Information
             Request Component, then sends it to the first
             Organisation

     1 <-- 2 TPO & AUTHENTICATION REQUEST. IotpMsg: Trans Ref Block;
             Signature Block (optional); TPO Block; Auth Request Block

 3.          IOTP aware application started. If a Signature Block is
             present, the first Organisation may use this to check the
             credentials of the second Organisation. If credentials are
             OK, the first Organisation selects an Authentication
             Request to use (if present and more than one), then uses
             the authentication algorithm selected to generate an
             Authentication Response Block. If present, the Trading
             Role Information Request Component is used to generate
             Organisation Components. Finally a Signature Component is
             created if required and all components are then sent back
             to the second Organisation for validation.

     1 --> 2 AUTHENTICATION RESPONSE. IotpMsg; Trans Ref Block;
             Signature Block (optional) ; Auth Response Block

 4.          The second Organisation checks the Authentication
             Response against the data in the Authentication Request
             Block to check that the first Organisation is who they
             appear to be, and sends an Authentication Status Block to
             the first Organisation to indicate the result then
             stops.

     1 <-- 2 AUTHENTICATION STATUS. IotpMsg: Trans Ref Block;
             Signature Block (optional); Auth Response Block

Top      Up      ToC       Page 190 
 5.          The first Organisation checks the authentication Status
             Block and optionally keeps information on the IOTP
             transaction for record keeping purposes and stops.

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

                 Figure 18 Authentication Document Exchange

9.1.1.1 Message Processing Guidelines

   On receiving a TPO & Authentication Request IOTP Message (see below),
   an Authenticatee may either:

   o  generate and send an Authentication Response IOTP Message back to
      the Authenticator, or

   o  indicate failure to comply with the Authentication Request by
      sending a Cancel Block back to the Authenticator containing a
      Status Component with a StatusType of Authentication a
      ProcessState of Failed and the CompletionCode (see section 7.16.4)
      set to either: AutEeCancel, NoAuthReq, TradRolesIncon or
      Unspecified.

   On receiving an Authentication Response IOTP Message (see below), an
   Authenticator should send in return, an Authentication Status IOTP
   Message (see below) containing a Status Block with a Status Component
   where the StatusType is set to Authentication, and:

   o  the ProcessState attribute of the Status Component is set to
      CompletedOk which indicates a successful completion, or

   o  the ProcessState attribute is set to Failed and the CompletionCode
      attribute is set to either: AutOrCancel, AuthFailed or Unspecified
      which indicates a failed authentication,

   On receiving an Authentication Status IOTP Message (see below), the
   Authenticatee should check the Status Component in the Status Block.
   If this indicates:

   o  a successful authentication, then the Authenticatee should either:

      -  continue with the next step in the IOTP Transaction of which
         the Authentication Document Exchange is part (if any), or

Top      Up      ToC       Page 191 
      -  indicate a failure to continue with the rest of the IOTP
         Transaction, by sending back to the Authenticator a Cancel
         Block containing a Status Component with a StatusType of
         Authentication, a ProcessState of Failed and the CompletionCode
         (see section 7.16.4) set to AutEeCancel.

   o  a failed authentication, then the failure should be reported to
      the Authenticatee and any further processing stopped.

   If the Authenticator receives an IOTP Message containing a Cancel
   block from a Consumer, then the Authenticatee may go to the
   CancelNetLocn specified on the Trading Role Element in the
   Organisation Component for the Authenticator contained in the Trading
   Protocol Options Block.

9.1.1.2 TPO & Authentication Request IOTP Message

   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 Authentication Request Block (see section 8.4), and

   o an optional Signature Block (see section 8.16).

   Each of these are described below.

   TRADING PROTOCOL OPTIONS BLOCK

   The Trading Protocol Options Block (see section 8.1) must contain the
   following Trading Components:

   o  one Protocol Options Component (see Section 7.1) which defines the
      options which apply to the whole Authentication Document Exchange.

   o  one Organisation Component (see section 7.6) which describes the
      Authenticator. The Trading Role on the Organisation Component
      should indicate the role which the Authenticator is taking in the
      Trade, for example a Merchant or a Consumer.

   AUTHENTICATION REQUEST BLOCK

   The Authentication Request Block (see section 8.4) must contain the
   following Trading Components:

   o  one Authentication Request Component (see section 7.2), and

Top      Up      ToC       Page 192 
   SIGNATURE BLOCK (AUTHENTICATION REQUEST)

   If the Authentication Request is being digitally signed then a
   Signature Block must be included. It contains Digests of 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

      -  the Organisation Component

   o  the following components of the Authentication Request Block:

      -  the Authentication Request Component

      -  the Trading Role Information Request Component

9.1.1.3 Authentication Response IOTP Message

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

   o  an Authentication Response Block (see section 8.5), and

   o  an optional Signature Block (see section 8.16).

   Each of these are described below.

   AUTHENTICATION RESPONSE BLOCK

   The Authentication Response Block must contain the following Trading
   Component:

   o  one Authentication Response Component (see section 7.3)

   o  one Organisation Component for every Trading Role identified in
      the TradingRoleList attribute of the Trading Role Information
      Request Component contained in the Authentication Request Block.

Top      Up      ToC       Page 193 
   SIGNATURE BLOCK (AUTHENTICATION RESPONSE)

   If the Algorithm element (see section 12. IANA Considerations) within
   the Authentication Request Component contained in the Authentication
   Request Block indicates that the Authentication Response should
   consist of a digital signature then a Signature Block must be
   included in the same IOTP message that contains an Authentication
   Response Block. The Signature Component contains 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 Authentication Request Block:

      -  the Authentication Request Component

      -  the Trading Role Information Request Component

   o  the Organisation Components contained in the Authentication
      Response Block

   Note: It should not be assumed that all trading roles can support the
   signing of data. Particularly it should not be assumed that Consumers
   support the signing of data.

9.1.1.4 Authentication Status IOTP Message

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

   o  an Authentication Status Block (see section 8.5), and

   o  an optional Signature Block (see section 8.16).

   Each of these are described below.

   AUTHENTICATION STATUS BLOCK

   The Authentication Status Block (see section 8.6) must contain the
   following Trading Components:

   o  one Status Component (see section 7.16) with a ProcessState
      attribute set to CompletedOk.

Top      Up      ToC       Page 194 
      SIGNATURE BLOCK (AUTHENTICATION STATUS)

      If the Authentication Status Block is being digitally signed then
      a Signature Block must be included that contains a Signature
      Component 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 Authentication Status Block:

      -  the Status Component (see section 7.16).

   Note: If the Authentication Document Exchange is followed by an Offer
   Document Exchange (see section 9.1.2) then the Authentication Status
   Block and the Signature Block (Authentication Status) may be combined
   with either:

   o a TPO IOTP Message (see section 9.1.2.3), or

   o a TPO and Offer Response IOTP Message (see section 9.1.2.6)

9.1.2 Offer Document Exchange

   The Offer Document Exchange occurs in two basic forms:

   o  Brand Dependent Offer Exchange. Where the content of the offer,
      e.g., the order details, amount, delivery details, etc., are
      dependent on the payment brand and protocol selected by the
      consumer, and

   o  Brand Independent Offer Exchange. Where the content of the offer
      is not dependent on the payment brand and protocol selected.

      Each of these types of Offer Document Exchange may be preceded by
      an Authentication Document Exchange (see section 9.1.1).

9.1.2.1 Brand Dependent Offer Document Exchange

      In a Brand Dependent Offer Document Exchange the TPO Block and the
      Offer Response Block are sent separately by the Merchant to the
      Consumer, i.e.:

Top      Up      ToC       Page 195 
   o  the Brand List Component is sent to the Consumer in a TPO Block,

   o  the Consumer selects a Payment Brand, Payment Protocol and
      optionally a Currency and amount from the Brand List Component

   o  the Consumer sends the selected brand, protocol and
      currency/amount back to the Merchant in a TPO Selection Block, and

   o  the Merchant uses the information received to define the content
      of and then send the Offer Response Block to the Consumer.

Top      Up      ToC       Page 196 
 This is illustrated by the diagram below.

 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Consumer
     |  Merchant
STEP |     |
 1.          Consumer decides to trade and sends to the Merchant
             information (e.g., using HTML) that enables the Merchant
             to create an offer,

     C --> M Offer information - outside scope of IOTP

 2.          Merchant decides which payment brand protocols,
             currencies and amounts apply, places then in a Brand List
             Component inside a TPO Block and sends to Consumer

     C <-- M TPO. IotpMsg: Trans Ref Block; TPO Block

 3.          IOTP aware application started. Consumer selects the
             payment brand, payment protocol and currency/amount to
             use. Records selection in a Brand Selection Component and
             sends back to Merchant.

     C --> M TPO SELECTION. IotpMsg: Trans Ref Block; TPO Selection
             Block

 4.          Merchant uses selected payment brand, payment protocol,
             currency/amount and the offer information to create an
             Offer Response Block containing details about the IOTP
             Transaction including price, etc. Optionally signs it and
             sends to the Consumer

     C <-- M OFFER RESPONSE. IotpMsg: Trans Ref Block; Signature Block
             (optional); Offer Response Block

 5.          Consumer checks the Offer is OK, then combines components
             from the TPO Block, the TPO Selection Block and the Offer
             Response Block to create the next IOTP Message for the
             Transaction and sends it together with the Signature
             block if present to the required Trading Role

     CONTINUED ...

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

              Figure 19 Brand Dependent Offer Document Exchange

Top      Up      ToC       Page 197 
   Note, a Consumer identifies a Brand Dependent Offer Document
   Exchange, by the absence of an Offer Response Block in the first IOTP
   Message.

   MESSAGE PROCESSING GUIDELINES

   On receiving a TPO IOTP Message (see below), the Consumer may either:

   o  generate and send a TPO Selection IOTP Message back to the
      Merchant, 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 Offer, a ProcessState of Failed and the
      CompletionCode (see section 7.16.4) set to either: ConsCancelled
      or Unspecified.

   On receiving a TPO Selection IOTP Message (see below) the Merchant
   may either:

   o  generate and send an Offer Response IOTP Message back to the
      Consumer, or

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

   On receiving an Offer Response IOTP Message (see below) 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, 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 Offer, a ProcessState of Failed and the
      CompletionCode (see section 7.16.4) set to either: ConsCancelled
      or Unspecified.

   If the Merchant 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
   Merchant.

Top      Up      ToC       Page 198 
   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.2.2 Brand Independent Offer Document Exchange

   In a Brand Independent Offer Document Exchange the TPO Block and the
   Offer Response Block are sent together by the Merchant to the
   Consumer, i.e. there is one IOTP Message that contains both a TPO
   Block, and an Offer Response Block.

   The message flow is illustrated by the diagram below:

 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
 Consumer
     |  Merchant
STEP |     |
 1.          Consumer decides to trade and sends to the Merchant
             information (e.g., using HTML) that enables the Merchant
             to create an offer,

     C --> M Offer information - outside scope of IOTP

 2.          Merchant decides which payment brand protocols,
             currencies and amounts apply, places then in a Brand List
             Component inside a TPO Block, creates an Offer Response
             containing details about the IOTP Transaction including
             price, etc., optionally signs it  and sends to Consumer

     C <-- M TPO & OFFER RESPONSE. IotpMsg: Trans Ref Block; Signature
             Block; TPO Block; Offer Response Block

 3.          IOTP aware application started. Consumer selects the
             payment brand, payment protocol and currency/amount to
             use. Records selection in a Brand Selection Component,
             checks offer is OK, combines the Brand Selection
             Component with information from the TPO Block and Offer
             Response Block to create the next IOTP Message for the
             Transaction and sends it together with the Signature
             Block if present to the required Trading Role.

     CONTINUED ...

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

                 Figure 20 Brand Independent Offer Exchange

Top      Up      ToC       Page 199 
   Note that a Brand Independent Offer Document Exchange always occurs
   when only one payment brand, protocol and currency/amount is being
   offered to the Consumer by the Merchant. It is also likely to, but
   will not necessarily, occur when multiple brands are being offered,
   the Payment Handler is the same, and all brands use the same set of
   protocols.

   Note that the TPO Block and the Offer Response Block can be sent in
   separate IOTP messages (see Brand Dependent Offer Document Exchange)
   even if the Offer Response Block does not change. However this
   increases the number of messages in the transaction and is therefore
   likely to increase transaction response times.

   IOTP aware applications supporting the Consumer Trading Role must
   check for the existence of an Offer Response Block in the first IOTP
   Message to determine whether the Offer Document Exchange is brand
   dependent or not.

   MESSAGE PROCESSING GUIDELINES

   On receiving a TPO and Offer Response IOTP Message (see below), 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, 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 Offer, a ProcessState of Failed and the
      CompletionCode (see section 7.16.1) set to either: ConsCancelled
      or Unspecified.

   If the Merchant 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
   Merchant.

9.1.2.3 TPO IOTP Message

   The TPO 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 Trading Protocol
   Options Block (see section 8.1) which is described below.

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

   The Trading Protocol Options Block (see section 8.1) must contain the
   following Trading Components:

   o  one Protocol Options Component which defines the options which
      apply to the whole IOTP Transaction. See Section 7.1.

   o  one Brand List Component (see section 7.7) for each Payment in the
      IOTP Transaction that contain one or more payment brands and
      protocols which may be selected for use in each payment

   o  Organisation Components (see section 7.6) with the following
      roles:

      -  Merchant who is making the offer

      -  Consumer who is carrying out the transaction

      -  the PaymentHandler(s) for the payment. The "ID" of the Payment
         Handler Organisation Component is contained within the PhOrgRef
         attribute of the Payment Component

   If the IOTP Transaction includes a Delivery then the TPO Block must
   also contain:

   o  Organisation Components with the following roles:

      -  DeliveryHandler who will be delivering the goods or services

      -  DelivTo i.e. the person or Organisation which is to take
         delivery

   AUTHENTICATION STATUS AND SIGNATURE BLOCKS

   If the Offer Document Exchange was preceded by an Authentication
   Document Exchange, then the TPO IOTP Message may also contain:

   o  an Authentication Status Block (see section 8.6), and

   o  an optional Signature Block (Authentication Status) Signature
      Block

   See section 9.1.1.4 Authentication Status IOTP Message for more
   details.


Next RFC Part