set to Failed. The following table contains the valid values for the
CompletionCode that may be used. It is recommended that the
StatusDesc attribute is used to provide further explanation where
appropriate.
Value Description
InMsgHardError Input Message Hard Error. The type of Request Block
could not be identified or was inconsistent.
Therefore no single Document Exchange could be
identified. This will cause a Hard Error in the
transaction
7.16.6 Transaction Inquiry Completion Codes
The Completion Code is only required if the ProcessState attribute is
set to Failed. The following table contains the valid values for the
CompletionCode that may be used. It is recommended that the
StatusDesc attribute is used to provide further explanation where
appropriate.
Value Description
UnAuthReq Unauthorised Request. The recipient of the
Transaction Status Request declines to respond to the
request.
7.17 Trading Role Data Component
The Trading Role Data Component contains opaque data which needs to
be communicated between the Trading Roles involved in an IOTP
Transaction.
Trading Role Components identify:
o the Organisation that generated the component, and
o the Organisation that is to receive it.
They are first generated and included in a "Response" Block, and then
copied to the appropriate "Request" Block. For example a Payment
Handler might need to inform a Delivery Handler that a credit card
payment had been authorised but not captured. There may also be other
information that the Payment Handler has generated where the format
is privately agreed with the Delivery Handler which needs to be
communicated. In another example a Merchant might need to provide a
Payment Handler with some specific information about a Consumer so
that consumer can acquire double loyalty points with the payment.
Its definition is as follows.
<!ELEMENT TradingRoleData (PackagedContent+) >
<!ATTLIST TradingRoleData
ID ID #REQUIRED
OriginatorElRef NMTOKEN #REQUIRED
DestinationElRefs NMTOKENS #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Trading Role Data Component within the IOTP
Transaction.
OrginatorElRef Contains an element reference to the Organisation
Component of the Organisation that created the
Trading Role Data Component and included it in a
"Response" Block (e.g., an Offer Response or a
Payment Response Block).
DestinationElRefs Contains element references to the Organisation
Components of the Organisations that are to
receive the Trading Role Data Component in a
"Request" Block (e.g., either a Payment Request or
a Delivery Request Block).
Content:
PackagedContent This contains the data which is to be sent between
the various Trading Roles as one or more
PackagedContent elements see section 3.7.
7.17.1 Who Receives a Trading Role Data Component
The rules for deciding what to do with Trading Role Data Components
are described below.
o whenever a Trading Role Data Component is received in a "Response"
block identify the Organisation Components of the Organisations
that are to receive it as identified by the DestinationElRefs
attribute.
o whenever a "Request" Block is being sent, check to see if it is
being sent to one of the Organisations identified by the
DestinationElRefs attribute. If it is then include in the
"Request" block:
- the Trading Role Data Component as well as,
- the Organisation Component of the Organisation identified by
the OriginatorElRef attribute (if not already present)
7.18 Inquiry Type Component
The Inquiry Type Component contains the information which indicates
the type of process that is being inquired upon. Its definition is as
follows.
<!ELEMENT InquiryType EMPTY >
<!ATTLIST InquiryType
ID ID #REQUIRED
Type NMTOKEN #REQUIRED
ElRef NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Inquiry Type Component within the IOTP
Transaction.
Type Contains the type of inquiry. Valid values for
Type are:
o Offer. The inquiry is about the status of an
offer and is addressed to the Merchant.
o Payment. The inquiry is about the status of a
payment and is addressed to the Payment
Handler.
o Delivery. The inquiry is about the status of a
delivery and addressed to the Delivery Handler.
ElRef Contains an Element Reference (see section 3.5) to
the component to which this Inquiry Type Component
applies. That is,
o TPO Block when Type is Offer
o Payment Component when Type is Payment
o Delivery Component when Type is Delivery
ProcessReference Optionally contains a reference to the process
being inquired upon. It should be set if the
information is available. For the definition of
the values it may contain, see the
ProcessReference attribute of the Status Component
(see section 7.16).
7.19 Signature Component
Note: Definitions of the XML structures for signatures and
certificates are described in the document titled "Digital Signatures
for the Internet Open Trading Protocol" by Kent Davidson and Yoshiaki
Kawatsura published at the same time as this document - see
[IOTPDSIG].
In the future it is anticipated that future versions of IOTP will
adopt a whatever method for digitally signing XML becomes the
standard.
Each Signature Component digitally signs one or more Blocks or
Components including other Signature Components.
The Signature Component:
o contains digests of one or more Blocks or Components in one or
more IOTP Messages within the same IOTP Transaction and places the
result in a Digest Element
o concatenates these Digest elements with other information on the
type of signature, the originator and potential recipients of the
signature and details of the signature algorithms being used and
places them in a Manifest element, and
o signs the Manifest element using the optional certificate
identified in the Certificate element within the Signature Block
placing the result in a Value element within a Signature Component
Note that there may be multiple Value elements that contain
signatures of a Manifest Element.
A Signature Component can be one of four types either:
o an Offer Response Signature,
o a Payment Response Signature,
o a Delivery Response Signature, or
o an Authentication Response Signature.
For a general explanation of signatures see section 6 Digital
Signatures.
7.19.1 IOTP usage of signature elements and attributes
Definitions of the elements and attributes are contained in
[IOTPDSIG]. The following contains additional information that
describes how these elements and attributes are used by IOTP.
SIGNATURE ELEMENT
The ID attribute is mandatory.
MANIFEST ELEMENT
The optional LocatorHrefBase attribute contains text which should be
concatenated before the text contained in the LocatorHREF attribute
of all Digest elements within the Manifest.
Its purpose is to reduce the size of LocatorHREF attribute values
since the first part of the LocatorHREF attributes in the same
signature are likely to be the same.
Typically, within IOTP, it will contain all the characters in a
LocatorHref attribute up to the sharp ("#") character (see
immediately below).
ALGORITHM AND PARAMETER ELEMENTS
The algorithm element identifies the algorithms used in generating
the signature. The type of the algorithm is defined by the value of
the Type attribute which indicates if it is to be used as a Digest
algorithm, a Signature algorithm or a Key Agreement algorithm.
The following Digest algorithms must be implemented:
o a [DOM-HASH] algorithm. This is identified by setting the Name
attribute of the Algorithm element to "urn:ibm:dom-hash"
o a [SHA1] algorithm. This is identified by setting the Name
attribute of the Algorithm element to "urn:fips:sha1", and
o a [MD5] algorithm. This is identified by setting the Name
attribute of the Algorithm element to "urn:rsa:md5"
o The following Signature algorithms must be implemented:
o a [DSA] algorithm. This is identified by setting the Name
attribute of the Algorithm element to "urn:us.gov:dsa"
o a [HMAC] algorithm. This is identified by setting the Name
attribute of the Algorithm element to "urn:ibm:hmac"
It is recommended that the following Signature algorithm is also
implemented:
o a [RSA] algorithm. This is identified by setting the Name
attribute of the Algorithm element to "urn:rsa:rsa"
In addition other payment scheme specific algorithms may be used. In
this case the value of the name attribute to use is specified in the
payment scheme supplement for that algorithm.
One algorithm may make use of other algorithms by use of the
Parameter element, for example:
<Algorithm ID=A1 type="digest" name="urn:ibm:dom-hash">
<Parameter type='AlgorithmRef'>A2</Parameter>
</Algorithm>
<Algorithm ID=A2 type="digest" name="urn:fips:sha1">
</Algorithm>
<Algorithm ID=A3 type="signature" name="urn:ibm:hmac">
<Parameter type='AlgorithmRef'>A1</Parameter>
</Algorithm>
DIGEST ELEMENT
The LocatorHREF attribute identifies the IOTP element which is being
digitally signed. Specifically it consists of:
o the value of the IotpTransId attribute of the Transaction ID
Component, followed by:
o a sharp character, i.e. "#", followed by
o an Element Reference (see section 3.5) to the element within the
IOTP Transaction which is the subject of the digest.
Before analysing the structure of the LocatorHREF attribute, it must
be concatenated with the value of the LocatorHrefBase attribute of
the Manifest element (see immediately above).
ATTRIBUTE ELEMENT
There must be one and only one Attribute Element that contains a Type
attribute with a value of IOTP Signature Type and with content set to
either: OfferResponse, PaymentResponse, DeliveryResponse,
AuthenticationRequest, AuthenticationResponse, PingRequest or
PingResponse; depending on the type of the signature.
Values of the content of the Attribute element are controlled under
the procedures defined in section 12 IANA Considerations which also
allows user defined values to be defined.
The Critical attribute must be set to true.
ORIGINATORINFO ELEMENT
The OriginatorRef attribute of the OriginatorInfo element must always
be present and contain an Element Reference (see section 3.5) to the
Organisation Component of the Organisation that generated the
Signature Component.
RECIPIENTINFO ELEMENT
The RecipientRefs attribute contains a list of Element References
(see section 3.5), that point to the Organisations that might need to
validate the signature. For details see below.
7.19.2 Offer Response Signature Component
The Manifest Element of a signature which has a type of OfferResponse
should contain Digest elements for the following Components:
o the Transaction Id Component (see section 3.3.1) of the IOTP
message that contains the Offer Response Signature
o the Transaction Reference Block (see section 3.3) of the IOTP
Message that contains the Offer Response Signature
o from the TPO Block:
- the Protocol Options Component
- each of the Organisation Components
- each of the Brand List Components
o optionally, all the Brand Selection Components if they were sent
to the Merchant in a TPO Selection Block
o from the Offer Response Block:
- the Order Component
- each of the Payment Components
- the Delivery Component
- each of the Authentication Request Components
- any Trading Role Data Components
The Offer Response Signature should also contain Digest elements for
the components that describe each of the Organisations that may or
will need to verify the signature. This involves:
o if the Merchant has received a TPO Selection Block containing
Brand Selection Components, then generate a Digest element for the
Payment Handler identified by the Brand Selection Component and
the Delivery Handler identified by the Delivery Component. See
section 6.3.1 Check Request Block sent Correct Organisation for a
description of how this can be done.
o if the Merchant is not expecting to receive a TPO Selection Block
then generate a Digest element for the Delivery Handler and all
the Payment Handlers that are involved.
7.19.3 Payment Receipt Signature Component
The Manifest Element of the Payment Receipt Signature Component
should contain Digest Elements for the following Components:
o the Transaction Id Component (see section 3.3.1) of the IOTP
message that contains the Payment Receipt Signature
o the Transaction Reference Block (see section 3.3) of the IOTP
Message that contains the Payment Receipt Signature
o the Offer Response Signature Component
o the Payment Receipt Component
o the Payment Note Component
o the Status Component
o the Brand Selection Component.
o any Trading Role Data Components
7.19.4 Delivery Response Signature Component
The Manifest Element of the Delivery Response Signature Component
should contain Digest Elements for the following Components:
o the Transaction Id Component (see section 3.3.1) of the IOTP
message that contains the Delivery Response Signature
o the Transaction Reference Block (see section 3.3) of the IOTP
Message that contains the Delivery Response Signature
o the Consumer Delivery Data component contained in the preceding
Delivery Request (if any)
o the Signature Components contained in the preceding Delivery
Request (if any)
o the Status Component
o the Delivery Note Component
7.19.5 Authentication Request Signature Component
The Manifest Element of the Authentication Request Signature
Component should contain Digest Elements for the following
Components:
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(s) (if present)
- the Trading Role Information Request Component (if present)
7.19.6 Authentication Response Signature Component
The Manifest Element of the Authentication Response Signature
Component should contain Digest Elements for the following
Components:
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 that was used in the
Authentication (if present)
- the Trading Role Information Request Component (if present)
o the Organisation Components contained in the Authentication
Response Block
7.19.7 Inquiry Request Signature Component
If the Inquiry Request is being signed (see section 9.2.1) the
Manifest Element of the Inquiry Request Signature Component should
contain Digest elements of the Inquiry Type Component, and if
present, the Payment Scheme Component.
7.19.8 Inquiry Response Signature Component
If the Inquiry Response is being signed (see section 9.2.1) the
Manifest Element of the Inquiry Response Signature Component should
contain Digest elements of the Trading Response Block and the Status
Component.
7.19.9 Ping Request Signature Component
If the Ping Request is being singed (see section 9.2.2), the Manifest
Element of the Ping Request Signature Component should contain Digest
elements for all the Organisation Components.
7.19.10 Ping Response Signature Component
If the Ping Response is being singed (see section 9.2.2), the
Manifest Element of the Ping Response Signature Component should
contain Digest elements fir all the Organisation Components.
7.20 Certificate Component
Note: Definitions of the XML structures for signatures and
certificates are described in the paper "Digital Signatures for the
Internet Open Trading Protocol", see [IOTPDSIG].
See note at the start of section 7.19 Signature Component for more
details.
A Certificate Component contains a Digital Certificate. They are used
only when required, for example, when asymmetric cryptography is
being used and the recipient of the signature that needs to check has
not already received the Public Key.
The structure of a Certificate Component is defined in [IOTPDSIG].
7.20.1 IOTP usage of signature elements and attributes
Detailed definitions of the above elements and attributes are
contained in [IOTPDSIG]. The following contains additional
information that describes how these elements and attributes are used
by IOTP.
CERTIFICATE COMPONENT
The ID attribute is mandatory.
VALUE ELEMENT
The ID attribute is mandatory.
7.21 Error Component
The Error Component contains 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 Component:
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 Component that describes the error found in a message in
error.
The definition of the Error Component is as follows.
<!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*) >
<!ATTLIST ErrorComp
ID NMTOKEN #REQUIRED
xml:lang NMTOKEN #REQUIRED
ErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED
Severity (Warning|TransientError|HardError) #REQUIRED
MinRetrySecs CDATA #IMPLIED
SwVendorErrorRef CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the Error
Component within the IOTP Transaction.
xml:lang Defines the language used by attributes or child
elements within this component, unless overridden
by an xml:lang attribute on a child element. See
section 3.8 Identifying Languages.
ErrorCode Contains an error code which indicates the nature
of the error in the message in error. Valid values
for the ErrorCode are given in section 7.21.2
Error Codes.
ErrorDesc Contains a narrative description of the error in
the language defined by xml:lang. The content of
this attribute is defined by the vendor/developer
of the software which generated the Error
Component
Severity Indicates the severity of the error. Valid values
are:
o Warning. This indicates that although there is
a message in error the IOTP Transaction can
still continue.
o TransientError. This indicates that the error
in the message in error may be recovered if the
message in error that is referred to by the
ErrorLocation element is resent
o HardError. This indicates that there is an
unrecoverable error in the message in error and
the IOTP Transaction must stop.
MinRetrySecs This attribute should be present if Severity is
set to TransientError. It is the minimum number of
whole seconds which the IOTP aware application
which received the message reporting the error
should wait before re-sending the message in error
identified by the ErrorLocation element.
If Severity is not set to TransientError then the
value of this attribute is ignored.
SwVendorErrorRef This attribute is a reference whose value is set
by the vendor/developer of the software which
generated the Error Component. It should contain
data which enables the vendor to identify the
precise location in their software and the set of
circumstances which caused the software to
generate a message reporting the error. See also
the SoftwareId attribute of the Message Id element
in the Transaction Reference Block (section 3.3).
Content:
ErrorLocation This identifies the IOTP Transaction Id of the
message in error and, where possible, the element
and attribute in the message in error that caused
the Error Component to be generated.
If the Severity of the error is not
TransientError, more than one ErrorLocation may be
specified as appropriate depending on the nature
of the error (see section 7.21.2 Error Codes) and
at the discretion of the vendor/developer of the
IOTP Aware Application.
PackagedContent This contains additional data which can be used to
understand the error. Its content may vary as
appropriate depending on the nature of the error
(see section 7.21.2 Error Codes) and at the
discretion of the vendor/developer of the IOTP
Aware Application. For a definition of
PackagedContent see section 3.7.
7.21.1 Error Processing Guidelines
If there is more than one Error Component in a message reporting the
error, carry out the actions appropriate for the Error Component with
the highest severity. In this context, HardError has a higher
severity than TransientError, which has a higher severity than
Warning.
7.21.1.1 Severity - Warning
If an IOTP aware application is generating a message reporting the
error with an Error Component where the Severity attribute is set to
Warning, then if the message reporting the error does not contain
another Error Component with a severity higher than Warning, the IOTP
Message must also include the Trading Blocks and Trading Components
that would have been included if no error was being reported.
If a message reporting the error is received with an Error Component
where Severity is set to Warning, then:
o it is recommended that information about the error is either
logged, or otherwise reported to the user,
o the implementer of the IOTP aware application must either, at
their or the user's discretion:
- continue the IOTP transaction as normal, or
- fail the IOTP transaction by generating a message reporting the
error with an Error Component with Severity set to HardError
(see section 7.21.1.3).
If the intention is to continue the IOTP transaction then, if there
are no other Error Components with a higher severity, check that the
necessary Trading Blocks and Trading Components for normal processing
of the transaction to continue are present. If they are not then
generate a message reporting the error with an Error Component with
Severity set to HardError.
7.21.1.2 Severity - Transient Error
If an IOTP Aware Application is generating a message reporting the
error with an Error Component where the Severity attribute is set to
TransientError, then there should be only one Error Component in the
message reporting the error. In addition, the MinRetrySecs attribute
should be present.
If a message reporting the error is received with an Error Component
where Severity is set to TransientError then:
o if the MinRetrySecs attribute is present and a valid number, then
use the MinRetrySecs value given. Otherwise if MinRetrySecs is
missing or is invalid, then:
- generate a message reporting the error containing an Error
Component with a Severity of Warning and send it on the next
IOTP message (if any) to be sent to the Trading Role which sent
the message reporting the error with the invalid MinRetrySecs,
and
- use a value for MinRetrySecs which is set by the
vendor/developer of the IOTP Aware Application.
o check that only one ErrorLocation element is contained within the
Error Component and that it refers to an IOTP Message which was
sent by the recipient of the Error Component with a Severity of
TransientError. If more than one ErrorLocation is present then
generate a message reporting the error with a Severity of
HardError.
7.21.1.3 Severity - Hard Error
If an IOTP Aware Application is generating a message reporting the
error with an Error Component where the Severity attribute set to
HardError, then there should be only one Error Component in the
message reporting the error.
If a message reporting the error is received with an Error Component
where Severity is set to HardError then terminate the IOTP
Transaction.
7.21.2 Error Codes
The following table contains the valid values for the ErrorCode
attribute of the Error Component. The first sentence of the
description contains the text that should be used to describe the
error when displayed or otherwise reported. Individual
implementations may translate this into alternative languages at
their discretion.
An Error Code must not be more that 14 characters long.
Value Description
Reserved Reserved. This error is reserved by the
vendor/developer of the software. Contact the
vendor/developer of the software for more information
See the SoftwareId attribute of the Message Id
element in the Transaction Reference Block(section
3.3).
XmlNotWellFrmd XML not well formed. The XML document is not well
formed. See [XML] for the meaning of "well formed".
Even if the XML is not well formed, it should still
be scanned to find the Transaction Reference Block so
that a properly formed Error Response may be
generated.
XmlNotValid XML not valid. The XML document is well formed but
the document is not valid. See [XML] for the meaning
of "valid". Specifically:
o the XML document does not comply with the
constraints defined in the IOTP document type
declaration (DTD) (see section 13 Internet Open
Trading Protocol Data Type Definition), and
o the XML document does not comply with the
constraints defined in the document type
declaration of any additional [XML Namespace] that
are declared.
As for XML not well formed, attempts should still be
made to extract the Transaction Reference Block so
that a properly formed Error Response may be
generated.
ElUnexpected Unexpected element. Although the XML document is well
formed and valid, an element is present that is not
expected in the particular context according to the
rules and constraints contained in this
specification.
ElNotSupp Element not supported. Although the document is well
formed and valid, an element is present that:
o is consistent with the rules and constraints
contained in this specification, but
o is not supported by the IOTP Aware Application
which is processing the IOTP Message.
ElMissing Element missing. Although the document is well formed
and valid, an element is missing that should have
been present if the rules and constraints contained
in this specification are followed.
In this case set the PackagedContent of the Error
Component to the type of the missing element.
ElContIllegal Element content illegal. Although the document is
well formed and valid, the element Content contains
values which do not conform to the rules and
constraints contained in this specification.
EncapProtErr Encapsulated protocol error. Although the document is
well formed and valid, the PackagedContent of an
element contains data from an encapsulated protocol
which contains errors.
AttUnexpected Unexpected attribute. Although the XML document is
well formed and valid, the presence of the attribute
is not expected in the particular context according
to the rules and constraints contained in this
specification.
AttNotSupp Attribute not supported. Although the XML document is
well formed and valid, and the presence of the
attribute in an element is consistent with the rules
and constraints contained in this specification, it
is not supported by the IOTP Aware Application which
is processing the IOTP Message.
AttMissing Attribute missing. Although the document is well
formed and valid, an attribute is missing that should
have been present if the rules and constraints
contained in this specification are followed.
In this case set the PackagedContent of the Error
Component to the type of the missing attribute.
AttValIllegal Attribute value illegal. The attribute contains a
value which does not conform to the rules and
constraints contained in this specification.
AttValNotRecog Attribute Value Not Recognised. The attribute
contains a value which the IOTP Aware Application
generating the message reporting the error could not
recognise.
MsgTooLarge Message too large. The message is too large to be
processed by the IOTP Aware Application.
ElTooLarge Element too large. The element is too large to be
processed by the IOTP Aware Application
ValueTooSmall Value too small or early. The value of all or part of
the Content of an element or an attribute, although
valid, is too small.
ValueTooLarge Value too large or in the future. The value of all or
part of the Content of an element or an attribute,
although valid, is too large.
ElInconsistent Element Inconsistent. Although the document is well
formed and valid, according to the rules and
constraints contained in this specification:
o the content of an element is inconsistent with the
content of other elements or their attributes, or
o the value of an attribute is inconsistent with the
value of one or more other attributes.
In this case create ErrorLocation elements which
identify all the attributes or elements which are
inconsistent.
TransportError Transport Error. This error code is used to indicate
that there is a problem with the Transport Mechanism
which is preventing the message from being received.
It is typically associated with a Transient Error.
Explanation of the Transport Error is contained
within the ErrorDesc attribute. The values which can
be used inside ErrorDesc with a TransportError is
specified in the IOTP supplement for the Transport
mechanism.
MsgBeingProc Message Being Processed. This error code is only used
with a Severity of Transient Error. It indicates that
the previous message, which may be an exchange
message or a request message, is being processed and,
if no response is received by the time indicated by
the MinRetrySecs attribute, then the original message
should be resent.
SystemBusy System Busy. This error code is only used with a
Severity of Transient Error. It indicates that the
server that received a message is currently too busy
to handle the message. If no response is received by
the time indicated by the MinRetrySecs attribute,
then the original message should be resent.
Note: If the server/system handling the Transport Mechanism (e.g.,
HTTP) is busy then a Transport Specific error message should be used
instead of an IOTP Error message. This code should be used in
association with IOTP servers/systems or other servers/systems to
which the IOTP server is connected.
UnknownError Unknown Error. Indicates that the transaction cannot
complete for some reason that is not covered
explicitly by any of the other errors. The ErrorDesc
attribute should be used to indicate the nature of
the problem.
This could be used to indicate, for example, an
internal error in a backend server or client process
of some kind.
7.21.3 Error Location Element
An Error Location Element identifies an element and optionally an
attribute in the message in error which is associated with the error.
It contains a reference to the IOTP Message, Trading Block, Trading
Component, element and attribute, which is in error.
<!ELEMENT ErrorLocation EMPTY >
<!ATTLIST ErrorLocation
ElementType NMTOKEN #REQUIRED
IotpMsgRef NMTOKEN #IMPLIED
BlkRef NMTOKEN #IMPLIED
CompRef NMTOKEN #IMPLIED
ElementRef NMTOKEN #IMPLIED
AttName NMTOKEN #IMPLIED >
Attributes:
ElementType This is the name of the type of the element where
the error is located. For example if the element
was declared as <!ELEMENT Org ... then its name is
"Org".
IotpMsgRef This is the value of the ID attribute of the of
the Message Id Component (see section 3.3.2) of
the message in error to which this Error Component
applies.
BlkRef If the error is associated with a specific Trading
Block, then this is the value of the ID attribute
of the Trading Block where the error is located.
CompRef If the error is associated with a specific Trading
Component, then this is the value of the ID
attribute of the Trading Component where the error
is located.
ElementRef If the error is associated with a specific element
within a Trading Component then, if the element
has an attribute with an "attribute type" (see
[XML]) of "ID", then this is the value of that
attribute.
AttName If the error is associated with the value of an
attribute, then this is the name of that
attribute. In this case the PackagedContent of the
Error Component should contain the value of the
attribute.
Note that as many as the attributes as possible should be included.
For example if an attribute in a child element of a Trading Component
contains an incorrect value, then all the attributes of ErrorLocation
should be present.
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
authentication
8.7 Payment Request Block
The Payment Request Block contains information which requests that a
payment is started. Its definition is as follows.
<!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection,
Payment, PaySchemeData?, Org*, TradingRoleData*) >
<!ATTLIST PayReqBlk
ID ID #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the
Payment Request Block within the IOTP Transaction.
Content:
Status Contains the Status Components (see section 7.13)
of the responses of the steps (e.g., an Offer
Response and/or a Payment Response) on which this
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