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 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.
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 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.
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.
9.1.2.4 TPO Selection IOTP Message
The TPO Selection IOTP Message is only used with a Brand Dependent
Offer Document Exchange. Apart from a Transaction Reference Block
(see section 3.3), this message consists of just a TPO Selection
Block (see section 8.1) which is described below.
TPO SELECTION BLOCK
The TPO Selection Block (see section 8.2) contains:
o one Brand Selection Component (see section 7.8) for use in a
later Payment Exchange. It contains the results of the consumer
selecting a Payment Brand, Payment Protocol and currency/amount
from the list provided in the Brand List Component.
9.1.2.5 Offer Response IOTP Message
The Offer Response IOTP Message is only used with a Brand Dependent
Offer Document Exchange. Apart from a Transaction Reference Block
(see section 3.3), this message consists of:
o an Offer Response Block (see section 8.1) and
o an optional Signature Block (see section 8.16).
OFFER RESPONSE BLOCK
The Offer Response Block (see section 8.3) contains the following
components:
o one Status Component (see section 7.16) which indicates the status
of the Offer Response. The ProcessState attribute should be set to
CompletedOk
o one Order Component (see section 7.5) which contains details about
the goods and services which are being purchased or the financial
transaction which is taking place
o one or more Payment Component(s) (see section 7.9) for each
payment which is to be made
o zero or one Delivery Components (see section 7.13) containing
details of the delivery to be made if the IOTP Transaction
includes a delivery
o zero or more Trading Role Data Components (see section 7.17) if
required by the Merchant.
SIGNATURE BLOCK (OFFER RESPONSE)
If the Authentication Status Block is being digitally signed then a
Signature Block must be included that contains a Signature Component
(see section 7.19) with Digest Elements for the following XML
elements:
If the Offer Response is being digitally signed then a Signature
Block must be included that contains a Signature Component (see
section 7.19) with Digest Elements for the following XML elements:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message that contains information that describes the IOTP Message
and IOTP Transaction
o the Transaction Id Component (see section 3.3.1) which globally
uniquely identifies the IOTP Transaction
o the following components of the TPO Block :
- the Protocol Options Component, and
- the Brand List Component
- all the Organisation Components present
o the following components of the Offer Response Block:
- the Order Component
- all the Payment Components present
- the Delivery Component if present
- any Trading Role Data Components present
9.1.2.6 TPO and Offer Response IOTP Message
The TPO and Offer Response IOTP Message is only used with a Brand
Independent Offer Document Exchange. Apart from a Transaction
Reference Block (see section 3.3), this message consists of:
o a Trading Protocol Options Block (see section 8.1)
o an Offer Response Block (see section 8.1) and
o an optional Signature Block (see section 8.16).
TPO (TRADING PROTOCOL OPTIONS) BLOCK
This is the same as the Trading Protocol Options Block described in
TPO IOTP Message (see section 9.1.2.3).
OFFER RESPONSE BLOCK
This the same as the Offer Response Block in the Offer Response IOTP
Message (see section 9.1.2.5).
AUTHENTICATION STATUS
If the Offer Document Exchange was preceded by an Authentication
Document Exchange, then the TPO and Offer Response IOTP Message may
also contain an Authentication Status Block (see section 8.6).
SIGNATURE BLOCK
This is the same as the Signature Block in the Offer Response IOTP
Message (see section 9.1.2.5) with the addition that:
o if the Offer Document Exchange is Brand Dependent then the
Signature Component in the Signature Block additionally contains a
Digest Element for the Brand Selection Component contained in the
TPO Selection Block
o if the Offer Document Exchange was preceded by an Authentication
Document Exchange then the Signature Component in the Signature
Block additionally contains a Digest Element for the
Authentication Status Block.
9.1.3 Payment Document Exchange
The Payment Document Exchange is a direct implementation of the last
part of a Payment Trading Exchange (see section 2.2.2) after the
Brand has been selected by the Consumer. A Payment Exchange consists
of:
o the Consumer requesting that a payment starts by generating
Payment Request IOTP Message using information from previous IOTP
Messages in the Transaction and then sending it to the Payment
Handler
o the Payment Handler and the Consumer then swapping Payment
Exchange IOTP Messages encapsulating payment protocol messages
until the payment is complete, and finally
o the Payment Handler sending a Payment Response IOTP Message to the
Consumer containing a receipt for the payment.
The IOTP Messages which are involved are illustrated by the diagram
below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer
| Payment
| Handler
STEP | |
1. Consumer generates Pay Request Block encapsulating a
payment protocol message if required and sends to Payment
Handler with the Signature Block if present
C --> P PAYMENT REQUEST. IotpMsg: Trans Ref Block; Signature
Block (optional); Pay Request Block
2. Payment Handler processes Pay Request Block, checks
optional signature and starts exchanging payment protocol
messages encapsulated in a Pay Exchange Block, with the
Consumer
C <-> P PAYMENT EXCHANGE. IotpMsg: Trans Ref Block; Pay Exchange
Block
3. Consumer and Payment Handler keep on exchanging Payment
Exchange blocks until eventually payment protocol
messages finish so Payment Handler creates a Pay Receipt
Component inside a Pay Response Block, and an optional
Signature Component inside a Signature Block, sends them