RFC 2801
Internet Open Trading Protocol - IOTP Version 1.0
Pages: 290
Informational
Informational
Part 6 of 9 – Pages 163 to 200
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.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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
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
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.
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.
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:
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.
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.
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 authentication8.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
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
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.
<!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).
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.
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:
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.
<!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.
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.
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
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.
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 step8.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.
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
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
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
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.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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.
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.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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
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
- 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
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 Component9.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.
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.
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.:
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.
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
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.
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
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.
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 page on part 7)