draft-ietf-trade-iotp-v1.0-protocol-05.txt   draft-ietf-trade-iotp-v1.0-protocol-06.txt 
Internet Draft. Internet Draft. David Burdett
David Burdett
Commerce One Commerce One
Expires: February 2000 Expires: March 2000
Internet Open Trading Protocol - IOTP Internet Open Trading Protocol - IOTP
Version 1.0 Version 1.0
Status of this Memo Status of this Memo
This document, filename draft-ietf-trade-iotp-v1.0-protocol-05.txt, is This document, filename draft-ietf-trade-iotp-v1.0-protocol-06.txt, is
the main specification of the Internet Open Trading Protocol version 1.0 the main specification of the Internet Open Trading Protocol version 1.0
and is intended to become an Informational RFC. Distribution of this and is intended to become an Informational RFC. Distribution of this
document is unlimited. Comments should be sent to the TRADE working group document is unlimited. Comments should be sent to the TRADE working group
at <ietf-trade@lists.elistx.com>. at <ietf-trade@lists.elistx.com>.
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
skipping to change at page 3, line 14 skipping to change at page 3, line 14
4.1 Technical Errors ...........................................51 4.1 Technical Errors ...........................................51
4.2 Business Errors ............................................52 4.2 Business Errors ............................................52
4.3 Error Depth ................................................52 4.3 Error Depth ................................................52
4.3.1 Transport Level ......................................52 4.3.1 Transport Level ......................................52
4.3.2 Message Level ........................................53 4.3.2 Message Level ........................................53
4.3.3 Block Level ..........................................53 4.3.3 Block Level ..........................................53
4.4 Idempotency, Processing Sequence, and Message Flow .........55 4.4 Idempotency, Processing Sequence, and Message Flow .........55
4.5 Server Role Processing Sequence ............................56 4.5 Server Role Processing Sequence ............................56
4.5.1 Initiating Transactions ..............................56 4.5.1 Initiating Transactions ..............................56
4.5.2 Processing Input Messages ............................56 4.5.2 Processing Input Messages ............................56
4.5.3 Cancelling a Transaction .............................61 4.5.3 Cancelling a Transaction .............................62
4.5.4 Retransmitting Messages ..............................62 4.5.4 Retransmitting Messages ..............................62
4.6 Client Role Processing Sequence ............................62 4.6 Client Role Processing Sequence ............................63
4.6.1 Initiating Transactions ..............................63 4.6.1 Initiating Transactions ..............................63
4.6.2 Processing Input Messages ............................63 4.6.2 Processing Input Messages ............................63
4.6.3 Cancelling a Transaction .............................65 4.6.3 Cancelling a Transaction .............................65
4.6.4 Retransmitting Messages ..............................65 4.6.4 Retransmitting Messages ..............................65
5. Security Considerations .......................................66 5. Security Considerations .......................................66
5.1 Determining whether to use digital signatures ..............66 5.1 Determining whether to use digital signatures ..............66
5.2 Symmetric and Asymmetric Cryptography ......................67 5.2 Symmetric and Asymmetric Cryptography ......................67
5.3 Data Privacy ...............................................68 5.3 Data Privacy ...............................................68
5.4 Payment Protocol Security ..................................68 5.4 Payment Protocol Security ..................................68
skipping to change at page 3, line 48 skipping to change at page 3, line 48
7. Trading Components ............................................80 7. Trading Components ............................................80
7.1 Protocol Options Component .................................81 7.1 Protocol Options Component .................................81
7.2 Authentication Request Component ...........................83 7.2 Authentication Request Component ...........................83
7.3 Authentication Response Component ..........................84 7.3 Authentication Response Component ..........................84
7.4 Trading Role Information Request Component .................85 7.4 Trading Role Information Request Component .................85
7.5 Order Component ............................................85 7.5 Order Component ............................................85
7.5.1 Order Description Content ............................86 7.5.1 Order Description Content ............................86
7.5.2 OkFrom and OkTo Timestamps ...........................87 7.5.2 OkFrom and OkTo Timestamps ...........................87
7.6 Organisation Component .....................................88 7.6 Organisation Component .....................................88
7.6.1 Organisation IDs .....................................89
7.6.2 Trading Role Element .................................90 7.6.2 Trading Role Element .................................90
7.6.3 Contact Information Element ..........................92 7.6.3 Contact Information Element ..........................93
7.6.4 Person Name Element ..................................93 7.6.4 Person Name Element ..................................93
7.6.5 Postal Address Element ...............................94 7.6.5 Postal Address Element ...............................94
7.7 Brand List Component .......................................95 7.7 Brand List Component .......................................95
7.7.1 Brand Element ........................................97 7.7.1 Brand Element ........................................97
7.7.2 Protocol Brand Element ...............................99 7.7.2 Protocol Brand Element ...............................99
7.7.3 Protocol Amount Element ..............................99 7.7.3 Protocol Amount Element .............................100
7.7.4 Currency Amount Element .............................101 7.7.4 Currency Amount Element .............................101
7.7.5 Pay Protocol Element ................................102 7.7.5 Pay Protocol Element ................................102
7.8 Brand Selection Component .................................103 7.8 Brand Selection Component .................................103
7.8.1 Brand Selection Brand Info Element ..................105 7.8.1 Brand Selection Brand Info Element ..................105
7.8.2 Brand Selection Protocol Amount Info Element ........105 7.8.2 Brand Selection Protocol Amount Info Element ........105
7.8.3 Brand Selection Currency Amount Info Element ........106 7.8.3 Brand Selection Currency Amount Info Element ........106
7.9 Payment Component .........................................106 7.9 Payment Component .........................................106
7.10 Payment Scheme Component ..................................107 7.10 Payment Scheme Component ..................................107
7.11 Payment Receipt Component .................................108 7.11 Payment Receipt Component .................................108
7.12 Payment Note Component ....................................110 7.12 Payment Note Component ....................................110
7.13 Delivery Component ........................................111 7.13 Delivery Component ........................................111
7.13.1 Delivery Data Element ...............................112 7.13.1 Delivery Data Element ...............................112
7.14 Consumer Delivery Data Component ..........................114 7.14 Consumer Delivery Data Component ..........................114
7.15 Delivery Note Component ...................................115 7.15 Delivery Note Component ...................................115
7.16 Status Component ..........................................116 7.16 Status Component ..........................................116
7.16.1 Offer Completion Codes ..............................118 7.16.1 Offer Completion Codes ..............................118
7.16.2 Payment Completion Codes ............................119 7.16.2 Payment Completion Codes ............................119
7.16.3 Delivery Completion Codes ...........................121 7.16.3 Delivery Completion Codes ...........................121
7.16.4 Authentication Completion Codes .....................123 7.16.4 Authentication Completion Codes .....................123
7.16.5 Undefined Completion Codes ..........................125 7.16.5 Undefined Completion Codes ..........................124
7.16.6 Transaction Inquiry Completion Codes ................125 7.16.6 Transaction Inquiry Completion Codes ................125
7.17 Trading Role Data Component ...............................125 7.17 Trading Role Data Component ...............................125
7.17.1 Who Receives a Trading Role Data Component ..........126 7.17.1 Who Receives a Trading Role Data Component ..........126
7.18 Inquiry Type Component ....................................126 7.18 Inquiry Type Component ....................................126
7.19 Signature Component .......................................127 7.19 Signature Component .......................................127
7.19.1 IOTP usage of signature elements and attributes .....128 7.19.1 IOTP usage of signature elements and attributes .....128
7.19.2 Offer Response Signature Component ..................130 7.19.2 Offer Response Signature Component ..................130
7.19.3 Payment Receipt Signature Component .................131 7.19.3 Payment Receipt Signature Component .................131
7.19.4 Delivery Response Signature Component ...............132 7.19.4 Delivery Response Signature Component ...............132
7.19.5 Authentication Request Signature Component ..........132 7.19.5 Authentication Request Signature Component ..........132
7.19.6 Authentication Response Signature Component .........132 7.19.6 Authentication Response Signature Component .........132
7.19.7 Inquiry Request Signature Component .................133 7.19.7 Inquiry Request Signature Component .................133
7.19.8 Inquiry Response Signature Component ................133 7.19.8 Inquiry Response Signature Component ................133
7.19.9 Ping Request Signature Component ....................133 7.19.9 Ping Request Signature Component ....................133
7.19.10 Ping Response Signature Component...................133 7.19.10 Ping Response Signature Component...................133
7.20 Certificate Component .....................................133 7.20 Certificate Component .....................................133
7.20.1 IOTP usage of signature elements and attributes .....134 7.20.1 IOTP usage of signature elements and attributes .....134
7.21 Error Component ...........................................134 7.21 Error Component ...........................................134
7.21.1 Error Processing Guidelines .........................136 7.21.1 Error Processing Guidelines .........................136
7.21.2 Error Codes .........................................138 7.21.2 Error Codes .........................................137
7.21.3 Error Location Element ..............................141 7.21.3 Error Location Element ..............................141
8. Trading Blocks ...............................................143 8. Trading Blocks ...............................................143
8.1 Trading Protocol Options Block ............................145 8.1 Trading Protocol Options Block ............................145
8.2 TPO Selection Block .......................................146 8.2 TPO Selection Block .......................................146
8.3 Offer Response Block ......................................146 8.3 Offer Response Block ......................................146
8.4 Authentication Request Block ..............................147 8.4 Authentication Request Block ..............................147
8.5 Authentication Response Block .............................149 8.5 Authentication Response Block .............................149
8.6 Authentication Status Block ...............................149 8.6 Authentication Status Block ...............................149
8.7 Payment Request Block .....................................150 8.7 Payment Request Block .....................................150
skipping to change at page 11, line 8 skipping to change at page 11, line 8
o there are ways in which they can get their problems fixed through the o there are ways in which they can get their problems fixed through the
merchant (rather than the bank!) merchant (rather than the bank!)
o there is a record of their transaction which can be used, for example, o there is a record of their transaction which can be used, for example,
to feed into accounting systems or, potentially, to present to the tax to feed into accounting systems or, potentially, to present to the tax
authorities authorities
1.3 Baseline IOTP 1.3 Baseline IOTP
This specification is Baseline IOTP. It is a Baseline in that it contains This specification is Baseline IOTP. It is a Baseline in that it contains
ways of doing trades on the Internet which are the most common. The team ways of doing trades on the Internet which are the most common, for
working on the IOTP see an extended version of this specification being example purchases and refunds.
developed as needs demand but at this stage feel a need to develop a
limited function but usable specification in order that technology
providers can develop pathway-pilot products that will be placed in the
market in order to understand the real "market place" demands and
requirements for electronic trading or electronic commerce.
Accordingly the IOTP Baseline specification has been produced for The group that has worked on the IOTP see an extended version being
pathway-pilot product development, expecting to transact live trades to developed over time but feel a need to focus on a limited function but
prove the interoperability of solutions based on this specification. completely usable specification in order that implementers can develop
solutions that work now.
During this period it is anticipated that there will be no changes to the During this period it is anticipated that there will be no changes to the
scope of this specification with the only changes made being limited to scope of this specification with the only changes made being limited to
corrections where problems are found. Software solutions have been corrections where problems are found. Software solutions have been
developed based on earlier versions of this specification (for example developed based on earlier versions of this specification (for example
version 0.9 published in early 1998) which prove that the basic concepts version 0.9 published in early 1998 and earlier revisions of version 1.0
work. published during 1999) which prove that the IOTP works.
1.4 Objectives of Document 1.4 Objectives of Document
The objectives of this document are to provide a functional specification The objectives of this document are to provide a specification of version
of version 1.0 of the Internet Open Trading Protocols which can be used 1.0 of the Internet Open Trading Protocols which can be used to design
to design and implement systems which support electronic trading on the and implement systems which support electronic trading on the Internet
Internet using the Internet Open Trading Protocols. using the Internet Open Trading Protocols.
The purpose of the document is: The purpose of the document is:
o to allow potential developers of products based on the protocol to o to allow potential developers of products based on the protocol to
start development of software/hardware solutions which use the protocol develop software/hardware solutions which use the protocol
o to allow the financial services industry to understand a developing o to allow the financial services industry to understand a developing
electronic commerce trading protocol that encapsulates (without electronic commerce trading protocol that encapsulates (without
modification) any of the current or developing payment schemes now modification) any of the current or developing payment schemes now
being used or considered by their merchant customer base being used or considered by their merchant customer base
1.5 Scope of Document 1.5 Scope of Document
The protocol describes the content, format and sequences of messages that The protocol describes the content, format and sequences of messages that
pass among the participants in an electronic trade - consumers, merchants pass among the participants in an electronic trade - consumers, merchants
skipping to change at page 15, line 41 skipping to change at page 15, line 41
o Ping This supports a simple query which enables one IOTP aware o Ping This supports a simple query which enables one IOTP aware
application to determine whether another IOTP application running application to determine whether another IOTP application running
elsewhere is working or not. elsewhere is working or not.
These IOTP Transactions are "Baseline" transactions since they have been These IOTP Transactions are "Baseline" transactions since they have been
identified as a minimum useful set of transactions. Later versions of identified as a minimum useful set of transactions. Later versions of
IOTP may include additional types of transactions. IOTP may include additional types of transactions.
Each of the IOTP Transactions above involve: Each of the IOTP Transactions above involve:
o a number organisations playing a Trading Role, and o a number of organisations playing a Trading Role, and
o a set of Trading Exchanges. Each Trading Exchange involves the exchange o a set of Trading Exchanges. Each Trading Exchange involves the exchange
of data, between Trading Roles, in the form of a set of Trading of data, between Trading Roles, in the form of a set of Trading
Components. Components.
Trading Roles, Trading Exchanges and Trading Components are described Trading Roles, Trading Exchanges and Trading Components are described
below. below.
2.1 Trading Roles 2.1 Trading Roles
skipping to change at page 18, line 34 skipping to change at page 18, line 34
transaction (requests an offer) to the Merchant e.g. using transaction (requests an offer) to the Merchant e.g. using
HTML. HTML.
C --> M Data: Information on what is being purchased (Offer Request) C --> M Data: Information on what is being purchased (Offer Request)
- outside scope of IOTP - outside scope of IOTP
2. Merchant checks the information provided by the Consumer, 2. Merchant checks the information provided by the Consumer,
creates an Offer optionally signs it and sends it to the creates an Offer optionally signs it and sends it to the
Consumer. Consumer.
C <-- M OFFER RESPONSE. Components: Organisation(s) (Consumer, C <-- M OFFER RESPONSE. Components: Status; Organisation(s)
DeliverTo, Merchant, Payment Handler, Customer Care); Order; (Consumer, DelivTo, Merchant, Payment Handler, Customer
Pay Amount; Delivery; Optional Offer Response Signature that Care); Order; Payment; Delivery; TradingRoleData (optional)
signs other components Offer Response Signature (optional) that signs other
components
3. Consumer checks the information from the Merchant and decides 3. Consumer checks the information from the Merchant and decides
whether to continue. whether to continue.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 2 Offer Exchange Figure 2 Offer Exchange
An Offer Exchange uses the following Trading Components that are passed An Offer Exchange uses the following Trading Components that are passed
between the Consumer and the Merchant: between the Consumer and the Merchant:
o the Status component is used to indicate to other parties that a valid
Offer Response has been generated
o the Organisation Component contains information which describes the o the Organisation Component contains information which describes the
organisations which are taking a role in the trade: Organisations which are taking a role in the trade:
- the consumer provides information, about who the consumer is and, if - the consumer provides information, about who the consumer is and, if
goods or services are being delivered, where the goods or services goods or services are being delivered, where the goods or services
are to be delivered to are to be delivered to
- the merchant augments this information by providing information about - the merchant augments this information by providing information about
the merchant, the Payment Handler, the customer care provider and, if the merchant, the Payment Handler, the customer care provider and, if
goods or services are being delivered, the Delivery Handler goods or services are being delivered, the Delivery Handler
o the Order Component contains descriptions of the goods or services o the Order Component contains descriptions of the goods or services
which will result from the trade if the consumer agrees to the offer. which will result from the trade if the consumer agrees to the offer.
This information is sent by the Merchant to the consumer who should This information is sent by the Merchant to the consumer who should
skipping to change at page 19, line 22 skipping to change at page 19, line 26
o the Payment Component generated by the Merchant, contains details of o the Payment Component generated by the Merchant, contains details of
how much to pay, the currency and the payment direction, for example how much to pay, the currency and the payment direction, for example
the consumer could be asking for a refund. Note that there may be more the consumer could be asking for a refund. Note that there may be more
than one payment in a trade than one payment in a trade
o the Delivery Component, also generated by the Merchant, is used if o the Delivery Component, also generated by the Merchant, is used if
goods or services are being delivered. This contains information about goods or services are being delivered. This contains information about
how delivery will occur, for example by post or using e-mail how delivery will occur, for example by post or using e-mail
o the Trading Role Data component contains data the Merchant wants to
forward to another Trading Role such as a Payment Handler or Delivery
Handler
o the "Offer Response" Signature Component, if present, digitally signs o the "Offer Response" Signature Component, if present, digitally signs
all of the above components to ensure their integrity. all of the above components to ensure their integrity.
The exact content of the information provided by the Merchant to the The exact content of the information provided by the Merchant to the
Consumer will vary depending on the type of IOTP Transaction. For Consumer will vary depending on the type of IOTP Transaction. For
example: example:
o low value purchases may not need a signature o low value purchases may not need a signature
o the amount to be paid may vary depending on the payment brand and o the amount to be paid may vary depending on the payment brand and
skipping to change at page 20, line 45 skipping to change at page 20, line 46
3. Consumer selects the payment brand, protocol and 3. Consumer selects the payment brand, protocol and
currency/amount to use, creates a Brand Selection currency/amount to use, creates a Brand Selection
component and sends it to the Merchant component and sends it to the Merchant
C --> M Component: Brand List Selection C --> M Component: Brand List Selection
4. Merchant checks Brand Selection, creates a Payment 4. Merchant checks Brand Selection, creates a Payment
Amount information, optionally signs it to authorise Amount information, optionally signs it to authorise
payment and sends it to the Consumer payment and sends it to the Consumer
C <-- M Component: Pay Amount; Organisation(s) (Merchant and C <-- M Component: Payment; Organisation(s) (Merchant and
Payment Handler); Optional Offer Response Signature Payment Handler); Optional Offer Response Signature
that signs other components that signs other components
5. Consumer checks the Payment Amount information and if 5. Consumer checks the Payment Amount information and if
OK requests that the payment starts by sending OK requests that the payment starts by sending
information to the Payment Handler information to the Payment Handler
C --------> P PAYMENT REQUEST. Components: Pay Amount; Organisations C --------> P PAYMENT REQUEST. Components: Status, Payment;
(Merchant and Payment Handler); Optional Offer Organisations (Merchant and Payment Handler); Trading
Response Signature that signs other components; Pay Role Data (optional); Optional Offer Response
Scheme Signature that signs other components; Pay Scheme Data
6. Payment Handler checks information including optional 6. Payment Handler checks information including optional
signature and if OK starts exchanging Pay Scheme signature and if OK starts exchanging Pay Scheme Data
components for selected payment brand and payment components for selected payment brand and payment
protocol protocol
C <-------> P PAYMENT EXCHANGE. Component: Pay Scheme C <-------> P PAYMENT EXCHANGE. Component: Pay Scheme Data
7. Eventually payment protocol messages finish so Payment 7. Eventually payment protocol messages finish so Payment
Handler sends Pay Receipt and optional signature to Handler sends Pay Receipt and optional signature to
the Consumer as proof of payment the Consumer as proof of payment
C <-------> P PAYMENT RESPONSE. Components: Pay Receipt; Payment C <-------> P PAYMENT RESPONSE. Components: Status, Pay Receipt;
Note; Optional Offer Response Signature; Optional Payment Note; Trading Role Data (optional); Optional
Payment Receipt Signature that binds the payment to Offer Response Signature; Optional Payment Receipt
the Offer Signature that binds the payment to the Offer
8. Consumer checks Payment Receipt is OK 8. Consumer checks Payment Receipt is OK
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 3 Payment Exchange Figure 3 Payment Exchange
A Payment Exchange uses the following Trading Components that are passed A Payment Exchange uses the following Trading Components that are passed
between the Consumer, the Merchant and the Payment Handler: between the Consumer, the Merchant and the Payment Handler:
skipping to change at page 21, line 45 skipping to change at page 21, line 48
that apply. The Merchant sends the Brand List to the Consumer. The that apply. The Merchant sends the Brand List to the Consumer. The
consumer compares the payment brands, protocols and currencies/amounts consumer compares the payment brands, protocols and currencies/amounts
on offer with those that the Consumer supports and makes a selection. on offer with those that the Consumer supports and makes a selection.
o The Brand Selection Component contains the Consumer's selection. o The Brand Selection Component contains the Consumer's selection.
Payment brand, protocol, currency/amount and possibly protocol-specific Payment brand, protocol, currency/amount and possibly protocol-specific
information is sent back to the Merchant. This information may be used information is sent back to the Merchant. This information may be used
to change information in the Offer Exchange. For example, a merchant to change information in the Offer Exchange. For example, a merchant
could choose to offer a discount to encourage the use of a store card. could choose to offer a discount to encourage the use of a store card.
o the Status component is used to indicate to the Payment Handler that an
earlier exchange (e.g. an Offer Exchange) has successfully completed
and by the Payment Handler to indicate the completion status of the
Payment Exchange.
o The Organisation Components are generated by the Merchant. They contain o The Organisation Components are generated by the Merchant. They contain
details of the Merchant and Payment Handler Roles: details of the Merchant and Payment Handler Roles:
- the Merchant role is required so that the Payment Handler can - the Merchant role is required so that the Payment Handler can
identify which Merchant initiated the payment. Typically, the result identify which Merchant initiated the payment. Typically, the result
of the Payment Handler accepting (or making) a payment on behalf of of the Payment Handler accepting (or making) a payment on behalf of
the Merchant will be a credit or debit transaction to the Merchant's the Merchant will be a credit or debit transaction to the Merchant's
account held by the Payment Handler. These transactions are outside account held by the Payment Handler. These transactions are outside
the scope of this version of IOTP the scope of this version of IOTP
- the Payment Handler role is required so that the Payment Handler can - the Payment Handler role is required so that the Payment Handler can
check that it is the correct Payment Handler to be used for the check that it is the correct Payment Handler to be used for the
skipping to change at page 22, line 4 skipping to change at page 22, line 11
details of the Merchant and Payment Handler Roles: details of the Merchant and Payment Handler Roles:
- the Merchant role is required so that the Payment Handler can - the Merchant role is required so that the Payment Handler can
identify which Merchant initiated the payment. Typically, the result identify which Merchant initiated the payment. Typically, the result
of the Payment Handler accepting (or making) a payment on behalf of of the Payment Handler accepting (or making) a payment on behalf of
the Merchant will be a credit or debit transaction to the Merchant's the Merchant will be a credit or debit transaction to the Merchant's
account held by the Payment Handler. These transactions are outside account held by the Payment Handler. These transactions are outside
the scope of this version of IOTP the scope of this version of IOTP
- the Payment Handler role is required so that the Payment Handler can - the Payment Handler role is required so that the Payment Handler can
check that it is the correct Payment Handler to be used for the check that it is the correct Payment Handler to be used for the
payment payment
o The Payment Component contains details of how much to pay, the currency o The Payment Component contains details of how much to pay, the currency
and the payment direction and the payment direction
o The "Offer Response" Signature Component, if present, digitally signs o The "Offer Response" Signature Component, if present, digitally signs
all of the above components to ensure their integrity. Note that the all of the above components to ensure their integrity. Note that the
Brand List and Brand Selection Components are not signed until the Brand List and Brand Selection Components are not signed until the
payment information is created (step 4 in the diagram) payment information is created (step 4 in the diagram)
o the Trading Role Data component contains from other roles (e.g. a
Merchant) that needs to be forwarded to the Payment Handler
o The Payment Scheme Component contains messages from the payment o The Payment Scheme Component contains messages from the payment
protocol used in the Trade. For example they could be SET messages, protocol used in the Trade. For example they could be SET messages,
Mondex messages, GeldKarte Messages or one of the other payment methods Mondex messages, GeldKarte Messages or one of the other payment methods
supported by IOTP. The content of the Payment Scheme Component is supported by IOTP. The content of the Payment Scheme Component is
defined in the supplements that describe how IOTP works with various defined in the supplements that describe how IOTP works with various
payment protocols. payment protocols.
o The Payment Receipt Component contains a record of the payment. The o The Payment Receipt Component contains a record of the payment. The
content depends upon the payment protocol used. content depends upon the payment protocol used.
skipping to change at page 23, line 4 skipping to change at page 23, line 16
CONSUMER DELIVERY CONSUMER DELIVERY
| HANDLER | HANDLER
| Merchant | | Merchant |
STEP | | | STEP | | |
1. Consumer decides to trade and sends information about 1. Consumer decides to trade and sends information about
what to deliver and who is to take delivery, to the what to deliver and who is to take delivery, to the
Merchant e.g. using HTML. Merchant e.g. using HTML.
C --> M Information on what is being delivered (outside scope C --> M Information on what is being delivered (outside scope
of IOTP) of IOTP)
2. Merchant checks the information provided by the 2. Merchant checks the information provided by the
Consumer, adds information about how the delivery will Consumer, adds information about how the delivery will
occur, information about the organisations involved in occur, information about the Organisations involved in
the delivery and optionally sings it and sends it to the delivery and optionally sings it and sends it to
the Consumer the Consumer
C <-- M Components: Delivery; Organisations (Delivery Handler, C <-- M Components: Delivery; Organisations (Delivery Handler,
Deliver To); Order, Optional Offer Response Signature Deliver To); Order, Optional Offer Response Signature
3. Consumer checks delivery information is OK, obtains 3. Consumer checks delivery information is OK, obtains
authorisation for the delivery, for example by making authorisation for the delivery, for example by making
a payment, and sends the delivery information to the a payment, and sends the delivery information to the
Delivery Handler Delivery Handler
C --------> D DELIVERY REQUEST. Components: Delivery, Organisations: C --------> D DELIVERY REQUEST. Components: Status; Delivery,
(Merchant, Delivery Handler, DelivTo); Order, Optional Organisations: (Merchant, Delivery Handler, DelivTo);
Offer Response Signature, Optional Payment Receipt Order, Trading Role Data (optional); Optional Offer
Signature (from Payment Exchange) Response Signature, Optional Payment Receipt Signature
(from Payment Exchange)
4. Delivery Handler checks information and authorisation. 4. Delivery Handler checks information and authorisation.
Starts or schedules delivery and creates and then Starts or schedules delivery and creates and then
sends a delivery not tot the Consumer which can sends a delivery not tot the Consumer which can
optionally be signed. optionally be signed.
C <-------- D DELIVERY RESPONSE. Components: Delivery Note, Optional C <-------- D DELIVERY RESPONSE. Components: Status; Delivery Note,
Delivery Response Signature Trading Role Data (optional); Optional Delivery
Response Signature
5. Consumer checks delivery note is OK and accepts or 5. Consumer checks delivery note is OK and accepts or
waits for delivery as described in the the Delivery waits for delivery as described in the the Delivery
Note. Note.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 4 Delivery Exchange Figure 4 Delivery Exchange
A Delivery Exchange uses the following Trading Components that are passed A Delivery Exchange uses the following Trading Components that are passed
between the Consumer, the Merchant and the Delivery Handler: between the Consumer, the Merchant and the Delivery Handler:
o the Status component is used to indicate to the Delivery Handler that
an earlier exchange (e.g. an Offer Exchange or Payment Exchange) has
successfully completed and by the Delivery Handler to indicate the
completion status of the Delivery Exchange.
o The Organisation Component(s) contain details of the Deliver To, o The Organisation Component(s) contain details of the Deliver To,
Delivery Handler and Merchant Roles: Delivery Handler and Merchant Roles:
- the Deliver To role indicates where the goods or services are to be - the Deliver To role indicates where the goods or services are to be
delivered to delivered to
- the Delivery Handler role is required so that the Delivery Handler - the Delivery Handler role is required so that the Delivery Handler
can check that she is the correct Delivery Handler to do the delivery can check that she is the correct Delivery Handler to do the delivery
- the Merchant role is required so that the Delivery Handler can - the Merchant role is required so that the Delivery Handler can
identify which Merchant initiated the delivery identify which Merchant initiated the delivery
o The Order Component, contains information about the goods or services o The Order Component, contains information about the goods or services
skipping to change at page 24, line 27 skipping to change at page 24, line 47
at the time of the delivery and later if the Consumer selects the Trade at the time of the delivery and later if the Consumer selects the Trade
to which this delivery relates from a transaction list to which this delivery relates from a transaction list
o The "Delivery Response" Signature Component, if present, provides proof o The "Delivery Response" Signature Component, if present, provides proof
of the results of the Delivery by digitally signing the Delivery Note of the results of the Delivery by digitally signing the Delivery Note
and any Offer Response or Payment Response signatures that the Delivery and any Offer Response or Payment Response signatures that the Delivery
Handler received. Handler received.
2.2.4 Authentication Exchange 2.2.4 Authentication Exchange
The goal of the Authentication Exchange is to allow one organisation, for The goal of the Authentication Exchange is to allow one Organisation, for
example a financial institution, to be able to check that another example a financial institution, to be able to check that another
organisation, for example a consumer, is who they appear to be. Organisation, for example a consumer, is who they appear to be.
An Authentication Exchange involves: An Authentication Exchange involves:
o an Authenticator - the organisation which is requesting the o an Authenticator - the Organisation which is requesting the
authentication, and authentication, and
o an Authenticatee - the organisation being authenticated. o an Authenticatee - the Organisation being authenticated.
This is illustrated in the diagram below. This is illustrated in the diagram below.
+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Organisation 1 Organisation 1
(Authenticatee) (Authenticatee)
| Organisation 2 | Organisation 2
| (Authenticator) | (Authenticator)
STEP | | STEP | |
1. First organisation, e.g. a Consumer, takes an action (for 1. First Organisation, e.g. a Consumer, takes an action (for
example by pressing a button on an HTML page) which requires example by pressing a button on an HTML page) which requires
that the organisation is authenticated that the Organisation is authenticated
1 --> 2 Need for Authentication (outside scope of IOTP) 1 --> 2 Need for Authentication (outside scope of IOTP)
2. The second organisation generates an Authentication Request - 2. The second Organisation generates an Authentication Request -
including challenge data, and a list of the algorithms that including challenge data, and a list of the algorithms that
may be used for the authentication - and/or a request for the may be used for the authentication - and/or a request for the
Organisation information then sends it to the first Organisation information then sends it to the first
organisation Organisation
1 <-- 2 AUTHENTICATION REQUEST. Components: Authentication Request, 1 <-- 2 AUTHENTICATION REQUEST. Components: Authentication Request,
Trading Role Information Request Trading Role Information Request
3. The first organisation optionally checks any signature 3. The first Organisation optionally checks any signature
associated with the Authentication Request then uses the associated with the Authentication Request then uses the
specified authentication algorithm to generate an specified authentication algorithm to generate an
Authentication Response which is sent back to the second Authentication Response which is sent back to the second
organisation together with details of any Organisation Organisation together with details of any Organisation
information requested information requested
1 --> 2 AUTHENTICATION RESPONSE. Component: Authentication Response, 1 --> 2 AUTHENTICATION RESPONSE. Component: Authentication Response,
Organisation(s) Organisation(s)
4. The Authentication Response is checked against the challenge 4. The Authentication Response is checked against the challenge
data to check that the first organisation is who they appear data to check that the first Organisation is who they appear
to be and the result recorded in a Status Component which is to be and the result recorded in a Status Component which is
then sent back to the first organisation. then sent back to the first Organisation.
1 <-- 2 AUTHENTICATION STATUS. Component: Status 1 <-- 2 AUTHENTICATION STATUS. Component: Status
5. The first organisation then optionally checks the results 5. The first Organisation then optionally checks the results
indicated by the Status and any associated signature and indicated by the Status and any associated signature and
takes the appropriate action or stops. takes the appropriate action or stops.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 5 Authentication Exchange Figure 5 Authentication Exchange
An Authentication Exchange uses the following Trading Components that are An Authentication Exchange uses the following Trading Components that are
passed between the two organisations: passed between the two Organisations:
o the Authentication Request Component that requests an Authentication o the Authentication Request Component that requests an Authentication
and indicates the authentication algorithm and optional challenge data and indicates the authentication algorithm and optional challenge data
to be used. to be used.
o A Trading Role Information Request Component that requests information o A Trading Role Information Request Component that requests information
about an Organisation, for example a ship to or billing address. about an Organisation, for example a ship to address.
o The Authentication Response Component which contains the challenge o The Authentication Response Component which contains the challenge
response generated by the recipient of the Authentication Request response generated by the recipient of the Authentication Request
Component. Component.
o Organisation Components that contain the result of the Trading Role o Organisation Components that contain the result of the Trading Role
Information Request Information Request
o the Status Component which contains the results of the second party's o the Status Component which contains the results of the second party's
verification of the Authentication Response. verification of the Authentication Response.
skipping to change at page 26, line 39 skipping to change at page 27, line 4
Merchants Merchants
ECash ECash ECash ECash
Store Value Value Consumer Payment Delivery Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler Issuer Acquirer Handler Handler
TRANSACTIONS TRANSACTIONS
Purchase Must Must Purchase Must Must
Merchants
ECash ECash
Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
Refund Must b) Refund Must b)
Depends Depends
Authentication May Must May b) Authentication May Must May b)
Depends Depends
Value Exchange May Must Value Exchange May Must
Withdrawal Must b) Withdrawal Must b)
Depends Depends
Deposit Must b) Deposit Must b)
Depends Depends
Inquiry Must Must Must Must Must Must Inquiry Must Must Must May Must Must
Ping Must Must Must Must Must Must
Merchants
ECash ECash Ping Must Must Must May Must Must
Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
TRADING BLOCKS TRADING BLOCKS
TPO Must Must Must Must TPO Must Must Must Must
TPO Selection Must Must Must Must TPO Selection Must Must Must Must
Auth-Request a) a) a) Auth-Request a) a) a)
Depends Depends Depends Depends Depends Depends
skipping to change at page 27, line 38 skipping to change at page 28, line 4
Exchange Exchange
Payment Must Must Payment Must Must
Response Response
Delivery Must Must Delivery Must Must
Request Request
Delivery Must Must Delivery Must Must
Response Response
Merchants
ECash ECash
Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
Inquiry Must Must Must Must Must Must Inquiry Must Must Must Must Must Must
Request Request
Inquiry Must Must Must Must Must Must Inquiry Must Must Must Must Must Must
Response Response
Ping Request Must Must Must Must Must Must Ping Request Must Must Must Must Must Must
Ping Response Must Must Must Must Must Must Ping Response Must Must Must Must Must Must
skipping to change at page 29, line 9 skipping to change at page 29, line 9
Block, Consumers do not have to be able to validate digital signatures. Block, Consumers do not have to be able to validate digital signatures.
An IOTP solution must support all the IOTP Transactions and Trading An IOTP solution must support all the IOTP Transactions and Trading
Blocks required by at least one role (column) as described in the above Blocks required by at least one role (column) as described in the above
table for that solution to be described as "supporting IOTP". table for that solution to be described as "supporting IOTP".
3. Protocol Structure 3. Protocol Structure
The previous section provided an introduction which explained: The previous section provided an introduction which explained:
o Trading Roles which are the different roles which organisations can o Trading Roles which are the different roles which Organisations can
take in a trade: Consumer, Merchant, Payment Handler, Delivery Handler take in a trade: Consumer, Merchant, Payment Handler, Delivery Handler
and Customer Care Provider, and and Customer Care Provider, and
o Trading Exchanges where each Trading Exchange involves the exchange of o Trading Exchanges where each Trading Exchange involves the exchange of
data, between Trading Roles, in the form of a set of Trading data, between Trading Roles, in the form of a set of Trading
Components. Components.
This section describes: This section describes:
o how Trading Components are constructed into Trading Blocks and the IOTP o how Trading Components are constructed into Trading Blocks and the IOTP
skipping to change at page 34, line 53 skipping to change at page 34, line 53
3.3.1 Transaction Id Component 3.3.1 Transaction Id Component
This contains information which globally uniquely identifies the IOTP This contains information which globally uniquely identifies the IOTP
Transaction. Its definition is as follows: Transaction. Its definition is as follows:
<!ELEMENT TransId EMPTY > <!ELEMENT TransId EMPTY >
<!ATTLIST TransId <!ATTLIST TransId
ID ID #REQUIRED ID ID #REQUIRED
Version NMTOKEN #FIXED '1.0' Version NMTOKEN #FIXED '1.0'
IotpTransId NMTOKEN #REQUIRED IotpTransId CDATA #REQUIRED
IotpTransType CDATA #REQUIRED IotpTransType CDATA #REQUIRED
TransTimeStamp CDATA #REQUIRED > TransTimeStamp CDATA #REQUIRED >
Attributes: Attributes:
ID An identifier which uniquely identifies the ID An identifier which uniquely identifies the
Transaction Id Component within the IOTP Transaction Id Component within the IOTP
Transaction. Transaction.
Version This identifies the version of IOTP, and therefore Version This identifies the version of IOTP, and therefore
the structure of the IOTP Messages, which the IOTP the structure of the IOTP Messages, which the IOTP
skipping to change at page 50, line 20 skipping to change at page 50, line 20
in the Protocol Options Component (see section 7.1) contained in the TPO in the Protocol Options Component (see section 7.1) contained in the TPO
Block (see section 8.1) for the transaction. This is normally the Block (see section 8.1) for the transaction. This is normally the
Merchant Trading Role. Merchant Trading Role.
A Consumer should not send a Cancel Block after the IOTP Transaction has A Consumer should not send a Cancel Block after the IOTP Transaction has
completed. Cancelling a complete transaction should be treated as a completed. Cancelling a complete transaction should be treated as a
technical error. technical error.
After cancelling the IOTP Transaction, the Consumer should go to the net After cancelling the IOTP Transaction, the Consumer should go to the net
location specified by the CancelNetLocn attribute contained in the location specified by the CancelNetLocn attribute contained in the
Trading Role Element for the organisation that was sent the Cancel Block. Trading Role Element for the Organisation that was sent the Cancel Block.
A non-Consumer Trading Role should only cancel a transaction: A non-Consumer Trading Role should only cancel a transaction:
o after a request block has been received and o after a request block has been received and
o before the response block has been sent o before the response block has been sent
If a non-Consumer Trading Role cancels a transaction at any other time it If a non-Consumer Trading Role cancels a transaction at any other time it
should be treated by the recipient as an error. should be treated by the recipient as an error.
skipping to change at page 57, line 38 skipping to change at page 57, line 38
component with a new IotpTransId and return it to the sender of the component with a new IotpTransId and return it to the sender of the
original message. original message.
4.5.2.2 Checking/Handling Duplicate Messages 4.5.2.2 Checking/Handling Duplicate Messages
If the input message can be identified as potentially a valid input If the input message can be identified as potentially a valid input
message then check to see if an "identical" input message has been message then check to see if an "identical" input message has been
received before. Identical means that all blocks, components, elements, received before. Identical means that all blocks, components, elements,
attribute values and element content in the input message are the same. attribute values and element content in the input message are the same.
[Note] The recommended way of checking for identical messages is to
check for equal values of their [DOM-HASH]
[Note End]
If an identical message has been received before then check to see if the If an identical message has been received before then check to see if the
processing of the previous message has completed. processing of the previous message has completed.
If processing has not completed then generate an Error Component with a If processing has not completed then generate an Error Component with a
Severity of Transient Error and an Error Code of MsgBeingProc to Severity of Transient Error and an Error Code of MsgBeingProc to indicate
indicate the message is being processed and send it back to the sender the message is being processed and send it back to the sender of the
of the Input Message requesting that the original message be resent Input Message requesting that the original message be resent after an
after an appropriate period of time. appropriate period of time.
Otherwise, if processing has completed and resulted in an output message Otherwise, if processing has completed and resulted in an output message
then retrieve the last message that was sent and send it again. then retrieve the last message that was sent and send it again.
If the message is not a duplicate then it should be processed. If the message is not a duplicate then it should be processed.
4.5.2.3 Processing Non-Duplicate Message 4.5.2.3 Processing Non-Duplicate Message
Once it's been established that the message is not a duplicate, then it Once it's been established that the message is not a duplicate, then it
can be processed. This involves: can be processed. This involves:
skipping to change at page 58, line 30 skipping to change at page 58, line 35
message and generating an output message, if required, for return to message and generating an output message, if required, for return to
the sender of the Input Message the sender of the Input Message
[Note] This approach to handling of duplicate input messages means, [Note] This approach to handling of duplicate input messages means,
if absolutely "identical" messages are received then if absolutely "identical" messages are received then
absolutely "identical" messages are returned. This also absolutely "identical" messages are returned. This also
applies to Inquiry and Ping transactions when in reality the applies to Inquiry and Ping transactions when in reality the
state of a transaction or the processing ability of the state of a transaction or the processing ability of the
servers may have changed. If up-to-date status of transactions servers may have changed. If up-to-date status of transactions
or servers is required, then an IOTP transaction with a new or servers is required, then an IOTP transaction with a new
IotpTransId must be used. value for the ID attribute of the MsgId component must be
used.
[Note End] [Note End]
Each of the above steps is discussed below. Each of the above steps is discussed below.
CHECKING A SERVER IS AVAILABLE CHECKING A SERVER IS AVAILABLE
The process that is handling the input message should check that the rest The process that is handling the input message should check that the rest
of the system is not so busy that a response in a reasonable time cannot of the system is not so busy that a response in a reasonable time cannot
be produced. be produced.
skipping to change at page 62, line 53 skipping to change at page 63, line 9
transaction to Failed, and a completion code of either: transaction to Failed, and a completion code of either:
o TimedOutRcvr if the transaction can potentially recovered later, or o TimedOutRcvr if the transaction can potentially recovered later, or
o TimedOutNoRcvr if the transaction is non-recoverable o TimedOutNoRcvr if the transaction is non-recoverable
4.6 Client Role Processing Sequence 4.6 Client Role Processing Sequence
The "Client role" in IOTP is the Consumer Trading Role. The "Client role" in IOTP is the Consumer Trading Role.
[Note] A company or organisation that is a Merchant, for example, may [Note] A company or Organisation that is a Merchant, for example, may
take on the Trading Role of a Consumer when making purchases take on the Trading Role of a Consumer when making purchases
or downloading or withdrawing electronic cash. or downloading or withdrawing electronic cash.
[Note End] [Note End]
More specifically the Consumer Role must be able to: More specifically the Consumer Role must be able to:
o Initiate a transaction (see section 4.6.1). These are divided into: o Initiate a transaction (see section 4.6.1). These are divided into:
- payment related transactions and - payment related transactions and
- infrastructure transactions - infrastructure transactions
o Accept and process a message received from another role (see section o Accept and process a message received from another role (see section
4.6.2). This includes: 4.6.2). This includes:
skipping to change at page 64, line 42 skipping to change at page 64, line 46
- if input message also contains an Authentication Status Block and the - if input message also contains an Authentication Status Block and the
Authentication Status Block has not been sent after an earlier Authentication Status Block has not been sent after an earlier
Authentication Response message then there is a hard error Authentication Response message then there is a hard error
- if input message also contains an Offer Response Block and the IOTP - if input message also contains an Offer Response Block and the IOTP
Transaction is recognised by the Consumer role's system then there is Transaction is recognised by the Consumer role's system then there is
a Hard Error, otherwise a Hard Error, otherwise
- if the TPO Block occurs on its own and the IOTP Transaction is - if the TPO Block occurs on its own and the IOTP Transaction is
recognised by the Consumer role's system then there is a Hard Error recognised by the Consumer role's system then there is a Hard Error
o Offer Response Block. Check as follows: o Offer Response Block. Check as follows:
- if the Offer Response Block is part of a Brand Independent Offer
Exchange (see section 9.1.2.2) then there is no sequence checking as
it is part of the first message received, otherwise
- if the Offer Response Block is not part of an IOTP Transaction that - if the Offer Response Block is not part of an IOTP Transaction that
is recognised by the Consumer role then there is a Hard Error, is recognised by the Consumer role then there is a Hard Error,
otherwise otherwise
- if the Offer Response Block does not refer to an IOTP transaction - if the Offer Response Block does not refer to an IOTP transaction
where a TPO Selection Block was the last message sent then there is a where a TPO Selection Block was the last message sent then there is a
Hard Error Hard Error
o Payment Exchange Block. Check as follows: o Payment Exchange Block. Check as follows:
- if the Payment Exchange Block doesn't refer to an IOTP Transaction - if the Payment Exchange Block doesn't refer to an IOTP Transaction
that is recognised by the Consumer role's system then there is a Hard that is recognised by the Consumer role's system then there is a Hard
Error, otherwise Error, otherwise
- if the Payment Exchange doesn't refer to an IOTP Transaction where - if the Payment Exchange doesn't refer to an IOTP Transaction where
either a Payment Request or a Payment Exchange block was most either a Payment Request or a Payment Exchange block was most
recently sent then there is a Hard Error recently sent then there is a Hard Error
o Payment Response Block. Check as follows: o Payment Response Block. Check as follows:
- if the Payment Response Block doesn't refer to an IOTP Transaction - if the Payment Response Block doesn't refer to an IOTP Transaction
that is recognised by the Consumer role's system then there is a Hard that is recognised by the Consumer role's system then there is a Hard
Error, otherwise Error, otherwise
- if the Payment Response doesn't refer to an IOTOP Transaction where - if the Payment Response doesn't refer to an IOTOP Transaction where
either a Payment Request or a Payment Exchange block was most either a Payment Request or a Payment Exchange block was most
recently sent then there is a Hard Error recently sent then there is a Hard Error
o Delivery Response Block. Check as follows: o Delivery Response Block. Check as follows:
- if the Delivery Response Block doesn't refer to an IOTP Transaction - if the Delivery Response Block doesn't refer to an IOTP Transaction
that is recognised by the Consumer role's system then there is a Hard that is recognised by the Consumer role's system then there is a Hard
skipping to change at page 66, line 44 skipping to change at page 66, line 44
o accept a lower volume and value of business. o accept a lower volume and value of business.
A non-exhaustive list of the reasons why digital signatures might be used A non-exhaustive list of the reasons why digital signatures might be used
follows: follows:
o the Merchant (or other trading role) wants to demonstrate that they can o the Merchant (or other trading role) wants to demonstrate that they can
be trusted. If, for example, a merchant generates an Offer Response be trusted. If, for example, a merchant generates an Offer Response
Signature (see section 7.19.2) using a certificate from a trusted third Signature (see section 7.19.2) using a certificate from a trusted third
party, known to the Consumer, then the Consumer can check the signature party, known to the Consumer, then the Consumer can check the signature
and certificate and so more reasonably rely on the offer being from the and certificate and so more reasonably rely on the offer being from the
actual organisation the Merchant claims to be. In this case signatures actual Organisation the Merchant claims to be. In this case signatures
using asymmetric cryptography are likely to be required using asymmetric cryptography are likely to be required
o the Merchant, or other Trading Role, want to generate a record of the o the Merchant, or other Trading Role, want to generate a record of the
transaction that is fit for a particular purpose. For example, with transaction that is fit for a particular purpose. For example, with
appropriate trust hierarchies, digital signatures could be checked by appropriate trust hierarchies, digital signatures could be checked by
the Consumer to determine: the Consumer to determine:
- if it would be accepted by tax authorities as a valid record of a - if it would be accepted by tax authorities as a valid record of a
transaction, or transaction, or
- if some warranty, for example from a "Better Business Bureau" or - if some warranty, for example from a "Better Business Bureau" or
similar was being provided similar was being provided
skipping to change at page 67, line 33 skipping to change at page 67, line 33
used follows: used follows:
o trading roles are combined therefore changes to data made by the o trading roles are combined therefore changes to data made by the
consumer can be detected. One of the reasons for using signatures is so consumer can be detected. One of the reasons for using signatures is so
that one trading role can determine if data has been changed by the that one trading role can determine if data has been changed by the
Consumer or some other party. However if the trading roles have access Consumer or some other party. However if the trading roles have access
to the necessary data, then it might be possible to compare, for to the necessary data, then it might be possible to compare, for
example, the payment information in the Payment Request with the example, the payment information in the Payment Request with the
payment information in the Offer Response. Access to the data necessary payment information in the Offer Response. Access to the data necessary
could be realised by, for example, the Merchant and Payment Handler could be realised by, for example, the Merchant and Payment Handler
roles being carried out by the same organisation on the same system, or roles being carried out by the same Organisation on the same system, or
the Merchant and Payment Handler roles being carried out on different the Merchant and Payment Handler roles being carried out on different
systems but the systems can communicate in some way. (Note this type of systems but the systems can communicate in some way. (Note this type of
communication is outside the current scope of IOTP) communication is outside the current scope of IOTP)
o the processing cost of the cryptography is too high. For example, if a o the processing cost of the cryptography is too high. For example, if a
payment is being made of only a few cents, the cost of carrying out all payment is being made of only a few cents, the cost of carrying out all
the cryptography associated with generating and checking digital the cryptography associated with generating and checking digital
signatures might make the whole transaction uneconomic. Co-locating signatures might make the whole transaction uneconomic. Co-locating
trading roles, could help avoid this problem. trading roles, could help avoid this problem.
skipping to change at page 70, line 54 skipping to change at page 70, line 54
Payment Handler and Delivery Handler. Payment Handler and Delivery Handler.
The detailed definitions of a Signature component are contained in The detailed definitions of a Signature component are contained in
section 7.19. section 7.19.
The remainder of this section contains: The remainder of this section contains:
o an example of how IOTP uses signatures o an example of how IOTP uses signatures
o how the OriginatorInfo and RecipientInfo elements within a Signature o how the OriginatorInfo and RecipientInfo elements within a Signature
Component are used to identify the organisations associated with the Component are used to identify the Organisations associated with the
signature signature
o how IOTP uses signatures to prove actions complete successfully o how IOTP uses signatures to prove actions complete successfully
6.1.1 IOTP Signature Example 6.1.1 IOTP Signature Example
An example of how signatures are used is illustrated in the figure below An example of how signatures are used is illustrated in the figure below
which shows how the various components and elements in a Baseline which shows how the various components and elements in a Baseline
Purchase relate to one another. Refer to this example in the later Purchase relate to one another. Refer to this example in the later
description of how signatures are used to check a payment or delivery can description of how signatures are used to check a payment or delivery can
occur (see section 6.3). occur (see section 6.3).
skipping to change at page 74, line 33 skipping to change at page 74, line 33
- if the Signature Algorithm element indicates that asymmetric - if the Signature Algorithm element indicates that asymmetric
cryptography is being used then use the SignatureCertRef to identify cryptography is being used then use the SignatureCertRef to identify
the Certificate to be used by the signature algorithm the Certificate to be used by the signature algorithm
- if Signature Algorithm element indicates that symmetric cryptography - if Signature Algorithm element indicates that symmetric cryptography
is being used then the content of the RecipientInfo element is used is being used then the content of the RecipientInfo element is used
to identify the correct shared secret key to use to identify the correct shared secret key to use
- use the specified signature algorithm to check that the Value Element - use the specified signature algorithm to check that the Value Element
correctly signs the Manifest Element correctly signs the Manifest Element
- check that the Digest Elements in the Manifest Element are correctly - check that the Digest Elements in the Manifest Element are correctly
calculated where Components or Blocks referenced by the Digest have calculated where Components or Blocks referenced by the Digest have
been received by the organisation checking the signature. been received by the Organisation checking the signature.
6.3 Checking a Payment or Delivery can occur 6.3 Checking a Payment or Delivery can occur
This section describes the processes required for a Payment Handler or This section describes the processes required for a Payment Handler or
Delivery Handler to check that a payment or delivery can occur. This may Delivery Handler to check that a payment or delivery can occur. This may
include checking signatures if this is specified by the Merchant. include checking signatures if this is specified by the Merchant.
In outline the steps are: In outline the steps are:
o check that the Payment Request or Delivery Request has been sent to the o check that the Payment Request or Delivery Request has been sent to the
correct organisation correct Organisation
o check that correct IOTP components are present in the request, and o check that correct IOTP components are present in the request, and
o check that the payment or delivery is authorised o check that the payment or delivery is authorised
For clarity and brevity the following terms or phrases are used in this For clarity and brevity the following terms or phrases are used in this
section: section:
o a "Request Block" is used to refer to either a Payment Request Block o a "Request Block" is used to refer to either a Payment Request Block
(see section 8.7) or a Delivery Request Block (see section 8.10) unless (see section 8.7) or a Delivery Request Block (see section 8.10) unless
skipping to change at page 75, line 34 skipping to change at page 75, line 34
Checking the Request Block was sent to the correct Organisation varies Checking the Request Block was sent to the correct Organisation varies
depending on whether the request refers to a Payment or a Delivery. depending on whether the request refers to a Payment or a Delivery.
6.3.1.1 Payment 6.3.1.1 Payment
In outline a Payment Handler checks if it can accept or make a payment by In outline a Payment Handler checks if it can accept or make a payment by
identifying the Payment Component in the Payment Request Block it has identifying the Payment Component in the Payment Request Block it has
received, then using the ID of the Payment Component to track through the received, then using the ID of the Payment Component to track through the
Brand List and Brand Selection Components to identify the Organisation Brand List and Brand Selection Components to identify the Organisation
selected by the Consumer and then checking that this organisation is selected by the Consumer and then checking that this Organisation is
itself. itself.
The way data is accessed to do this is illustrated in the figure below. The way data is accessed to do this is illustrated in the figure below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Start Start
| |
v v
Brand List<--------------------------+-----------Payment Brand List<--------------------------+-----------Payment
Component BrandListRef | Component Component BrandListRef | Component
skipping to change at page 77, line 33 skipping to change at page 77, line 33
o Check that the Payment Handler that received the Payment Request Block o Check that the Payment Handler that received the Payment Request Block
is the Payment Handler selected by the Consumer. This involves: is the Payment Handler selected by the Consumer. This involves:
- identifying the Organisation Component for the Payment Handler. This - identifying the Organisation Component for the Payment Handler. This
is the Organisation Component where its ID attribute matches the is the Organisation Component where its ID attribute matches the
ActionOrgRef attribute in the identified Pay Protocol Element. If no ActionOrgRef attribute in the identified Pay Protocol Element. If no
or more than one matching Organisation Component is found there is an or more than one matching Organisation Component is found there is an
error error
- checking the Organisation Component has a Trading Role Element with a - checking the Organisation Component has a Trading Role Element with a
Role attribute of PaymentHandler. If not there is an error Role attribute of PaymentHandler. If not there is an error
- finally, if the identified Organisation Component is not the same as - finally, if the identified Organisation Component is not the same as
the organisation that received the Payment Request Block, then there the Organisation that received the Payment Request Block, then there
is an error. is an error.
6.3.1.2 Delivery 6.3.1.2 Delivery
The way data is accessed by a Delivery Handler in order to check that it The way data is accessed by a Delivery Handler in order to check that it
may carry out a delivery is illustrated in the figure below. may carry out a delivery is illustrated in the figure below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Start Start
| |
skipping to change at page 78, line 21 skipping to change at page 78, line 21
is no or more than one matching Delivery Component there is an error is no or more than one matching Delivery Component there is an error
o Use the ActionOrgRef attribute of the Delivery Component to identify o Use the ActionOrgRef attribute of the Delivery Component to identify
the Organisation Component of the Delivery Handler. If there is no or the Organisation Component of the Delivery Handler. If there is no or
more than one matching Organisation Component there is an error more than one matching Organisation Component there is an error
o If the Organisation Component for the Delivery Handler does not have a o If the Organisation Component for the Delivery Handler does not have a
Trading Role Element with a Role attribute of DeliveryHandler there is Trading Role Element with a Role attribute of DeliveryHandler there is
an error an error
o Finally, if the organisation that received the Delivery Request Block o Finally, if the Organisation that received the Delivery Request Block
does not identify the Organisation Component for the Delivery Handler does not identify the Organisation Component for the Delivery Handler
as itself, then there is an error. as itself, then there is an error.
6.3.2 Check Correct Components present in Request Block 6.3.2 Check Correct Components present in Request Block
Check that the correct components are present in the Payment Request Check that the correct components are present in the Payment Request
Block (see section 8.7) or in the Delivery Request Block (see section Block (see section 8.7) or in the Delivery Request Block (see section
8.10). 8.10).
If components are missing, there is an error. If components are missing, there is an error.
skipping to change at page 88, line 8 skipping to change at page 88, line 8
to appear in the Packaged Content of the Order Description it to appear in the Packaged Content of the Order Description it
is the dates contained in the Order Component that is is the dates contained in the Order Component that is
authoritative. This means it is important that the OkFrom and authoritative. This means it is important that the OkFrom and
OkTo dates actually being used is prominently displayed to the OkTo dates actually being used is prominently displayed to the
Consumer. Consumer.
[Note End] [Note End]
7.6 Organisation Component 7.6 Organisation Component
The Organisation Component provides information about an individual or an The Organisation Component provides information about an individual or an
organisation. This can be used for a variety of purposes. For example: Organisation. This can be used for a variety of purposes. For example:
o to describe the merchant who is selling the goods, o to describe the merchant who is selling the goods,
o to identify who made a purchase, o to identify who made a purchase,
o to identify who will take delivery of goods, o to identify who will take delivery of goods,
o to provide a customer care contact, o to provide a customer care contact,
o to describe who will be the Payment Handler. o to describe who will be the Payment Handler.
skipping to change at page 88, line 48 skipping to change at page 88, line 48
ID An identifier which uniquely identifies the ID An identifier which uniquely identifies the
Organisation Component within the IOTP Organisation Component within the IOTP
Transaction. Transaction.
xml:lang Defines the language used by attributes or child xml:lang Defines the language used by attributes or child
elements within this component, unless overridden elements within this component, unless overridden
by an xml:lang attribute on a child element. See by an xml:lang attribute on a child element. See
section 3.8 Identifying Languages. section 3.8 Identifying Languages.
OrgId A code which identifies the organisation described OrgId A code which identifies the Organisation described
by the Organisation Component. See 7.6.1.1 by the Organisation Component. See 7.6.1
Organisation IDs, below. Organisation IDs, below.
LegalName For organisations which are companies this is LegalName For Organisations which are companies this is
their legal name in the language defined by their legal name in the language defined by
xml:lang. It is required for Organisations who xml:lang. It is required for Organisations who
have a Trading Role other than Consumer or have a Trading Role other than Consumer or
DeliverTo. DelivTo.
ShortDesc A short description of the organisation in the ShortDesc A short description of the Organisation in the
language defined by xml:lang. It is typically the language defined by xml:lang. It is typically the
name by which the organisation is commonly known. name by which the Organisation is commonly known.
For example, if the legal name was "Blue Meadows For example, if the legal name was "Blue Meadows
Financial Services Inc.". Then its short name Financial Services Inc.". Then its short name
would likely be "Blue Meadows". would likely be "Blue Meadows".
It is used to facilitate selecting an individual It is used to facilitate selecting an individual
organisation from a list of organisations, for Organisation from a list of Organisations, for
example from a database of organisations involved example from a database of Organisations involved
in IOTP Transactions which has been stored by a in IOTP Transactions which has been stored by a
consumer. consumer.
LogoNetLocn The net location which can be used to download the LogoNetLocn The net location which can be used to download the
logo for the organisation. logo for the Organisation.
See section 10 Retrieving Logos. See section 10 Retrieving Logos.
The content of this attribute must conform to The content of this attribute must conform to
[RFC1738]. [RFC1738].
Content: Content:
TradingRole See 7.6.2 Trading Role Element below. TradingRole See 7.6.2 Trading Role Element below.
ContactInfo See 7.6.3 Contact Information Element below. ContactInfo See 7.6.3 Contact Information Element below.
PersonName See 7.6.4 Person Name below. PersonName See 7.6.4 Person Name below.
PostalAddress See 7.6.5 Postal Address below. PostalAddress See 7.6.5 Postal Address below.
7.6.1.1 Organisation IDs 7.6.1 Organisation IDs
Organisation IDs are used by one IOTP Trading Role to identify another. Organisation IDs are used by one IOTP Trading Role to identify another.
In order to avoid confusion, this means that these IDs must be globally In order to avoid confusion, this means that these IDs must be globally
unique. unique.
In principle this is achieved in the following way: In principle this is achieved in the following way:
o the Organisation Id for all trading roles, apart from the Consumer o the Organisation Id for all trading roles, apart from the Consumer
Trading Role, uses a domain name as their globally unique identifier, Trading Role, uses a domain name as their globally unique identifier,
skipping to change at page 90, line 6 skipping to change at page 90, line 7
Transaction the same Organisation Id is used by all the other trading Transaction the same Organisation Id is used by all the other trading
roles in that IOTP transaction to identify that Consumer. roles in that IOTP transaction to identify that Consumer.
Specifically, the content of the Organisation ID is defined as follows: Specifically, the content of the Organisation ID is defined as follows:
OrgId ::= NonConsumerOrgId | ConsumerOrgId OrgId ::= NonConsumerOrgId | ConsumerOrgId
NonConsumerOrgId ::= DomainName NonConsumerOrgId ::= DomainName
ConsumerOrgId ::= ConsumerOrgIdPrefix (namechar)+ "/" NonConsumerOrgId ConsumerOrgId ::= ConsumerOrgIdPrefix (namechar)+ "/" NonConsumerOrgId
ConsumerOrgIdPrefix ::= "Consumer:" ConsumerOrgIdPrefix ::= "Consumer:"
ConsumerOrgId If the Organisation ID for a Consumer consists of: ConsumerOrgId The Organisation ID for a Consumer consists of:
o a standard prefix to identify that the o a standard prefix to identify that the
Organisation Id is for a consumer, followed by Organisation Id is for a consumer, followed by
o one or more characters which conform to the o one or more characters which conform to the
definition of an XML "namechar". See [XML] definition of an XML "namechar". See [XML]
specifications, followed by specifications, followed by
o the NonConsumerOrgId for the Organisation o the NonConsumerOrgId for the Organisation
which allocated the ConsumerOrgId. It is which allocated the ConsumerOrgId. It is
normally the Merchant role. normally the Merchant role.
Use of upper and lower case is significant. Use of upper and lower case is not significant.
NonConsumerOrgId If the Role is not Consumer then this contains the NonConsumerOrgId If the Role is not Consumer then this contains the
Canonical Name for the non-consumer organisation Canonical Name for the non-consumer Organisation
being described by the Organisation Component. See being described by the Organisation Component. See
[DNS]. [DNS] optionally followed by additional
characters, if required, to make the
NonConsumerOrgId unique.
Note that a NonConsumerOrgId may not start with Note that a NonConsumerOrgId may not start with
the ConsumerOrgIdPrefix. the ConsumerOrgIdPrefix.
Use of upper and lower case is not significant. Use of upper and lower case is not significant.
Examples of Organisation Ids follow: Examples of Organisation Ids follow:
o newjerseybooks.com - a merchant organisation id o newjerseybooks.com - a merchant Organisation id
o westernbank.co.uk - a Payment Handler organisation id o westernbank.co.uk - a Payment Handler Organisation id
o consumer:1000247ABH/newjerseybooks.com - a consumer organisation id o consumer:1000247ABH/newjerseybooks.com - a consumer Organisation id
allocated by a merchant allocated by a merchant
7.6.2 Trading Role Element 7.6.2 Trading Role Element
This identifies the Trading Role of an individual or organisation in the This identifies the Trading Role of an individual or Organisation in the
IOTP Transaction. Note, an organisation may have more than one Trading IOTP Transaction. Note, an Organisation may have more than one Trading
Role and several roles may be present in one organisation element. Its Role and several roles may be present in one Organisation element. Its
definition is as follows: definition is as follows:
<!ELEMENT TradingRole EMPTY > <!ELEMENT TradingRole EMPTY >
<!ATTLIST TradingRole <!ATTLIST TradingRole
ID ID #REQUIRED ID ID #REQUIRED
TradingRole NMTOKEN #REQUIRED TradingRole NMTOKEN #REQUIRED
IotpMsgIdPrefix NMTOKEN #REQUIRED IotpMsgIdPrefix NMTOKEN #REQUIRED
CancelNetLocn CDATA #REQUIRED CancelNetLocn CDATA #IMPLIED
ErrorNetLocn CDATA #REQUIRED ErrorNetLocn CDATA #IMPLIED
ErrorLogNetLocn CDATA #IMPLIED > ErrorLogNetLocn CDATA #IMPLIED >
Attributes: Attributes:
ID An identifier which uniquely identifies the ID An identifier which uniquely identifies the
Trading Role Element within the IOTP Transaction. Trading Role Element within the IOTP Transaction.
TradingRole The trading role of the organisation. Valid values TradingRole The trading role of the Organisation. Valid values
are: are:
o Consumer. The person or organisation that is o Consumer. The person or Organisation that is
acting in the role of a consumer in the IOTP acting in the role of a consumer in the IOTP
Transaction. Transaction.
o Merchant. The person or organisation that is o Merchant. The person or Organisation that is
acting in the role of merchant in the IOTP acting in the role of merchant in the IOTP
Transaction. Transaction.
o PaymentHandler. The financial institution or o PaymentHandler. The financial institution or
other organisation which is a Payment Handler other Organisation which is a Payment Handler
for the IOTP Transaction for the IOTP Transaction
o DeliveryHandler. The person or organisation o DeliveryHandler. The person or Organisation
that is the delivering the goods or services that is the delivering the goods or services
for the IOTP Transaction for the IOTP Transaction
o DelivTo. The person or organisation that is o DelivTo. The person or Organisation that is
receiving the delivery of goods or services in receiving the delivery of goods or services in
the IOTP Transaction the IOTP Transaction
o CustCare. The organisation and/or individual o CustCare. The Organisation and/or individual
who will provide customer care for an IOTP who will provide customer care for an IOTP
Transaction. Transaction.
Values of TradingRole are controlled under the Values of TradingRole are controlled under the
procedures defined in section 12 IANA procedures defined in section 12 IANA
Considerations which also allows user defined Considerations which also allows user defined
values to be defined. values to be defined.
IotpMsgIdPrefix Contains the prefix which must be used for all IotpMsgIdPrefix Contains the prefix which must be used for all
IOTP Messages sent by the Trading Role in this IOTP Messages sent by the Trading Role in this
skipping to change at page 92, line 47 skipping to change at page 92, line 51
Consumer role, Consumer role,
o must be present when TradingRole is set to o must be present when TradingRole is set to
Merchant, PaymentHandler or DeliveryHandler. Merchant, PaymentHandler or DeliveryHandler.
The content of this attribute is dependent on the The content of this attribute is dependent on the
Transport Mechanism see the Transport Mechanism Transport Mechanism see the Transport Mechanism
Supplement. Supplement.
The ErrorLogNetLocn can be used to send error The ErrorLogNetLocn can be used to send error
messages to the software company or some other messages to the software company or some other
organisation responsible for fixing problems in Organisation responsible for fixing problems in
the software which sent the incoming message. See the software which sent the incoming message. See
section 7.21.1 Error Processing Guidelines for section 7.21.1 Error Processing Guidelines for
more details. more details.
7.6.3 Contact Information Element 7.6.3 Contact Information Element
This contains information which can be used to contact an organisation or This contains information which can be used to contact an Organisation or
an individual. All attributes are optional however at least one item of an individual. All attributes are optional however at least one item of
contact information should be present. Its definition is as follows. contact information should be present. Its definition is as follows.
<!ELEMENT ContactInfo EMPTY > <!ELEMENT ContactInfo EMPTY >
<!ATTLIST ContactInfo <!ATTLIST ContactInfo
xml:lang NMTOKEN #IMPLIED xml:lang NMTOKEN #IMPLIED
Tel CDATA #IMPLIED Tel CDATA #IMPLIED
Fax CDATA #IMPLIED Fax CDATA #IMPLIED
Email CDATA #IMPLIED Email CDATA #IMPLIED
NetLocn CDATA #IMPLIED > NetLocn CDATA #IMPLIED >
Attributes: Attributes:
xml:lang Defines the language used by attributes within xml:lang Defines the language used by attributes within
this element. See section 3.8 Identifying this element. See section 3.8 Identifying
Languages. Languages.
Tel A telephone number by which the organisation may Tel A telephone number by which the Organisation may
be contacted. Note that this is a text field and be contacted. Note that this is a text field and
no validation is carried out on it. no validation is carried out on it.
Fax A fax number by which the organisation may be Fax A fax number by which the Organisation may be
contacted. Note that this is a text field and no contacted. Note that this is a text field and no
validation is carried out on it. validation is carried out on it.
Email An email address by which the organisation may be Email An email address by which the Organisation may be
contacted. Note that this field should conform to contacted. Note that this field should conform to
the conventions for address specifications the conventions for address specifications
contained in [RFC822]. contained in [RFC822].
NetLocn A location on the Internet by which information NetLocn A location on the Internet by which information
about the organisation may be obtained that can be about the Organisation may be obtained that can be
displayed using a web browser. displayed using a web browser.
The content of this attribute must conform to The content of this attribute must conform to
[RFC1738]. [RFC1738].
7.6.4 Person Name Element 7.6.4 Person Name Element
This contains the name of an individual person. All fields are optional This contains the name of an individual person. All fields are optional
however as a minimum either the GivenName or the FamilyName should be however as a minimum either the GivenName or the FamilyName should be
present. Its definition is as follows. present. Its definition is as follows.
skipping to change at page 98, line 27 skipping to change at page 98, line 31
BrandName This contains the name of the brand, for example BrandName This contains the name of the brand, for example
MasterCard Credit. This is the description of the MasterCard Credit. This is the description of the
Brand which is displayed to the consumer in the Brand which is displayed to the consumer in the
Consumers language defined by xml:lang. For Consumers language defined by xml:lang. For
example it might be "American Airlines Advantage example it might be "American Airlines Advantage
Visa". Note that this attribute is not used for Visa". Note that this attribute is not used for
matching against the payment instruments held by matching against the payment instruments held by
the Consumer. the Consumer.
BrandLogoNetLocn The net location which can be used to download BrandLogoNetLocn The net location which can be used to download
the logo for the organisation. See section the logo for the Organisation. See section
Retrieving Logos (see section 10). Retrieving Logos (see section 10).
The content of this attribute must conform to The content of this attribute must conform to
[RFC1738]. [RFC1738].
BrandNarrative This optional attribute is designed to be used by BrandNarrative This optional attribute is designed to be used by
the Merchant to indicate some special conditions the Merchant to indicate some special conditions
or benefit which would apply if the Consumer or benefit which would apply if the Consumer
selected that brand. For example "5% discount", selected that brand. For example "5% discount",
"free shipping and handling", "free breakage "free shipping and handling", "free breakage
skipping to change at page 103, line 44 skipping to change at page 103, line 44
Examples of Pay Protocol Elements are contained in section 11.2 Brand Examples of Pay Protocol Elements are contained in section 11.2 Brand
List Examples. List Examples.
7.8 Brand Selection Component 7.8 Brand Selection Component
A Brand Selection Component identifies the choice of payment brand, A Brand Selection Component identifies the choice of payment brand,
payment protocol and the Payment Handler. This element is used: payment protocol and the Payment Handler. This element is used:
o in Payment Request messages within Baseline Purchase and Baseline Value o in Payment Request messages within Baseline Purchase and Baseline Value
IOTP Transactions to identify the brand, protocol and payment handler Exchange IOTP Transactions to identify the brand, protocol and payment
for a payment, or handler for a payment, or
o to, optionally, inform a merchant in a purchase of the payment brand o to, optionally, inform a merchant in a purchase of the payment brand
being used so that the offer and order details can be amended being used so that the offer and order details can be amended
accordingly. accordingly.
In Baseline IOTP, the integrity of Brand Selection Components is not In Baseline IOTP, the integrity of Brand Selection Components is not
guaranteed. However, modification of Brand Selection Components can only guaranteed. However, modification of Brand Selection Components can only
cause denial of service if the payment protocol itself is secure against cause denial of service if the payment protocol itself is secure against
message modification, duplication, and swapping attacks. message modification, duplication, and swapping attacks.
skipping to change at page 107, line 5 skipping to change at page 107, line 5
Its definition is as follows. Its definition is as follows.
<!ELEMENT Payment EMPTY > <!ELEMENT Payment EMPTY >
<!ATTLIST Payment <!ATTLIST Payment
ID ID #REQUIRED ID ID #REQUIRED
OkFrom CDATA #REQUIRED OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED OkTo CDATA #REQUIRED
BrandListRef NMTOKEN #REQUIRED BrandListRef NMTOKEN #REQUIRED
SignedPayReceipt (True | False) #REQUIRED SignedPayReceipt (True | False) #REQUIRED
StartAfter NMTOKENS #IMPLIED > StartAfterRefs NMTOKENS #IMPLIED >
Attributes: Attributes:
ID An identifier which uniquely identifies the ID An identifier which uniquely identifies the
Payment Component within the IOTP Transaction. Payment Component within the IOTP Transaction.
OkFrom The date and time in [UTC] format after which a OkFrom The date and time in [UTC] format after which a
Payment Handler may accept for processing a Payment Handler may accept for processing a
Payment Request Block (see section 8.7) containing Payment Request Block (see section 8.7) containing
the Payment Component. the Payment Component.
OkTo The date and time in [UTC] format before which a OkTo The date and time in [UTC] format before which a
Payment Handler may for processing accept a Payment Handler may accept for processing a
Payment Request Block containing the Payment Payment Request Block containing the Payment
Component. Component.
BrandListRef An Element Reference (see section 3.5) of a Brand BrandListRef An Element Reference (see section 3.5) of a Brand
List Component (see section 7.7) within the TPO List Component (see section 7.7) within the TPO
Trading Block for the IOTP Transaction. The Brand Trading Block for the IOTP Transaction. The Brand
List identifies the alternative ways in which the List identifies the alternative ways in which the
payment can be made. payment can be made.
SignedPayReceipt Indicates whether or not the Payment Response SignedPayReceipt Indicates whether or not the Payment Response
Block (8.9) generated by the Payment Handler for Block (see section 8.9) generated by the Payment
the payment must be digitally signed. Handler for the payment must be digitally signed.
StartAfter Contains Element References (see section 3.5) of StartAfter Contains Element References (see section 3.5) of
other Payment Components which describe payments other Payment Components which describe payments
which must be complete before this payment can which must be complete before this payment can
start. If no StartAfter attribute is present then start. If no StartAfter attribute is present then
there are no dependencies and the payment can there are no dependencies and the payment can
start immediately start immediately
7.10 Payment Scheme Component 7.10 Payment Scheme Component
skipping to change at page 108, line 9 skipping to change at page 108, line 9
ContentSoftwareId CDATA #IMPLIED > ContentSoftwareId CDATA #IMPLIED >
Attributes: Attributes:
ID An identifier which uniquely identifies the ID An identifier which uniquely identifies the
Payment Scheme Component within the IOTP Payment Scheme Component within the IOTP
Transaction. Transaction.
PaymentRef An Element Reference (see section 3.5) to the PaymentRef An Element Reference (see section 3.5) to the
Payment Component (see section 7.9) to which Payment Component (see section 7.9) to which
this Pay Scheme Data Component relates. It is this Payment Scheme Component relates. It is
required unless the Pay Scheme Data is part of required unless the Payment Scheme Component is
an Transaction Inquiry Status Transaction (see part of an Transaction Inquiry Status
section 9.2.1). Transaction (see section 9.2.1).
ConsumerPaymentId An identifier specified by the Consumer which, ConsumerPaymentId An identifier specified by the Consumer which,
if returned by the Payment Handler in another if returned by the Payment Handler in another
Payment Scheme Component or by other means, will Payment Scheme Component or by other means, will
enable the Consumer to identify which payment is enable the Consumer to identify which payment is
being referred to. being referred to.
PaymentHandlerPayId An identifier specified by the Payment Handler PaymentHandlerPayId An identifier specified by the Payment Handler
which, if returned by the Consumer in another which, if returned by the Consumer in another
Payment Scheme Component, or by other means, Payment Scheme Component, or by other means,
skipping to change at page 110, line 12 skipping to change at page 110, line 12
roles during the Payment, and/or roles during the Payment, and/or
o the Payment Receipt component itself. o the Payment Receipt component itself.
Note that: Note that:
o each payment scheme defines in its supplement o each payment scheme defines in its supplement
the Names of the Packaged Content elements the Names of the Packaged Content elements
that must be listed in this attribute (if that must be listed in this attribute (if
any). any).
o if a Payment Scheme Component contains o if a Payment Scheme Component contains
Packaged Content elements with a name that Packaged Content elements with a name that
matches a name within PaymentReceiptRefs, then matches a name within PayReceiptNameRefs, then
those Payment Scheme Components must be those Payment Scheme Components must be
referenced by Digests in the Payment Response referenced by Digests in the Payment Response
signature component (if such a signature is signature component (if such a signature is
being used) being used)
The client software should save all the The client software should save all the
components referenced so that the payment receipt components referenced so that the payment receipt
can be reconstructed when required. can be reconstructed when required.
ContentSoftwareId See section 14. Glossary. ContentSoftwareId See section 14. Glossary.
skipping to change at page 110, line 40 skipping to change at page 110, line 40
Note that: Note that:
o the values of the Name attribute of each o the values of the Name attribute of each
packaged content element are defined by the packaged content element are defined by the
Payment Protocol Supplement Payment Protocol Supplement
o the value of each Name must be unique within a o the value of each Name must be unique within a
Payment where a Payment is defined as all Payment where a Payment is defined as all
Payment Scheme or Payment Receipt Components, Payment Scheme or Payment Receipt Components,
with the same value of the PaymentRef attribute with the same value of the PaymentRef attribute
Note that either the PayReceiptRefs attribute, the PackagedContent Note that either the PayReceiptNameRefs attribute, the PackagedContent
element, or both must be present. element, or both must be present.
7.12 Payment Note Component 7.12 Payment Note Component
The Payment Note Component contains additional, non payment related, The Payment Note Component contains additional, non payment related,
information which the Payment Handler wants to provide to the Consumer. information which the Payment Handler wants to provide to the Consumer.
For example, if a withdrawal or deposit were being made then it could For example, if a withdrawal or deposit were being made then it could
contain information on the remaining balance on the account after the contain information on the remaining balance on the account after the
transfer was complete. The information should duplicate information transfer was complete. The information should duplicate information
contained within the Payment Receipt Component. contained within the Payment Receipt Component.
skipping to change at page 112, line 23 skipping to change at page 112, line 23
o False indicates each block will be in a o False indicates each block will be in a
different IOTP Message different IOTP Message
DelivAndPayResp should not be true if DelivExch DelivAndPayResp should not be true if DelivExch
is False. is False.
In practice combining the Delivery Response Block In practice combining the Delivery Response Block
and Payment Response Block is only likely to be and Payment Response Block is only likely to be
practical if the Merchant, the Payment Handler practical if the Merchant, the Payment Handler
and the Delivery Handler are the same and the Delivery Handler are the same
organisation since: Organisation since:
o the Payment Handler must have access to Order o the Payment Handler must have access to Order
Component information so that they know what Component information so that they know what
to deliver, and to deliver, and
o the Payment Handler must be able to carry out o the Payment Handler must be able to carry out
the delivery the delivery
ActionOrgRef An Element Reference to the Organisation ActionOrgRef An Element Reference to the Organisation
Component of the Delivery Handler for this Component of the Delivery Handler for this
delivery. delivery.
skipping to change at page 115, line 12 skipping to change at page 115, line 9
ConsumerDeliveryId An identifier specified by the Consumer which, if ConsumerDeliveryId An identifier specified by the Consumer which, if
returned by the Delivery Handler will enable the returned by the Delivery Handler will enable the
Consumer to identify which Delivery is being Consumer to identify which Delivery is being
referred to. referred to.
7.15 Delivery Note Component 7.15 Delivery Note Component
A Delivery Note contains delivery instructions about the delivery of A Delivery Note contains delivery instructions about the delivery of
goods or services or potentially the actual Delivery Information itself. goods or services or potentially the actual Delivery Information itself.
It is information which the person or organisation receiving the Delivery It is information which the person or Organisation receiving the Delivery
Note can use when delivery occurs. Note can use when delivery occurs.
For interoperability, the Delivery Note Component Packaged Content should For interoperability, the Delivery Note Component Packaged Content should
support both Plain Text, HTML and XML. support both Plain Text, HTML and XML.
It's definition is as follows.
<!ELEMENT DeliveryNote (PackagedContent+) > <!ELEMENT DeliveryNote (PackagedContent+) >
<!ATTLIST DeliveryNote <!ATTLIST DeliveryNote
ID ID #REQUIRED ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED xml:lang NMTOKEN #REQUIRED
DelivHandlerDelivId CDATA #IMPLIED DelivHandlerDelivId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED > ContentSoftwareId CDATA #IMPLIED >
Attributes: Attributes:
ID An identifier which uniquely identifies the ID An identifier which uniquely identifies the
skipping to change at page 117, line 4 skipping to change at page 116, line 52
Values of StatusType are managed under the Values of StatusType are managed under the
procedure described in section 12 IANA procedure described in section 12 IANA
Considerations which also allows user defined Considerations which also allows user defined
values of StatusType to be defined. values of StatusType to be defined.
ElRef If the StatusType is not set to Undefined then ElRef If the StatusType is not set to Undefined then
ElRef contains an Element Reference (see section ElRef contains an Element Reference (see section
3.5) to the Component for which the Status is 3.5) to the Component for which the Status is
being described. It must refer to either: being described. It must refer to either:
o an Order Component (see section 7.5), if the
o a Order Component (see section 7.5), if the
StatusType is Offer, StatusType is Offer,
o a Payment Component (see section 7.9), if the o a Payment Component (see section 7.9), if the
StatusType is Payment, or StatusType is Payment, or
o a Delivery Component (see section 7.13), if o a Delivery Component (see section 7.13), if
the StatusType is Delivery the StatusType is Delivery
o an Authentication Request Component (see o an Authentication Request Component (see
section 7.2) if the StatusType is section 7.2) if the StatusType is
Authentication. Authentication.
ProcessState Contains a State Code which indicates the current ProcessState Contains a State Code which indicates the current
state of the process being carried out. Valid state of the process being carried out. Valid
values for ProcessState are: values for ProcessState are:
o NotYetStarted. A Request Block has been o NotYetStarted. A Request Block has been
received but the process has not yet started received but the process has not yet started
o InProgress. Processing of the Request Block o InProgress. Processing of the Request Block
has started but it is not yet complete has started but it is not yet complete
o CompletedOk. The processing of the Request o CompletedOk. The processing of the Request
Block has completed successfully without any Block has completed successfully without any
errors errors
o Failed. The processing of the Request Block o Failed. The processing of the Request Block
has failed because of a business error (see has failed because of a Business Error (see
section 4.2) section 4.2)
o ProcessError. This value is only used when the o ProcessError. This value is only used when the
Status Component is being used in connection Status Component is being used in connection
with an Inquiry Request Trading Block (see with an Inquiry Request Trading Block (see
section 8.12). It indicates there was a section 8.12). It indicates there was a
Technical Error (see section 4.1) in the Technical Error (see section 4.1) in the
Request Block which is being processed or some Request Block which is being processed or some
internal processing error. internal processing error.
Note that this code reports on the processing of a Note that this code reports on the processing of a
skipping to change at page 118, line 10 skipping to change at page 118, line 4
Component Component
o when StatusType is set to Payment, it should o when StatusType is set to Payment, it should
contain the PaymentHandlerPayId from the contain the PaymentHandlerPayId from the
Payment Scheme Data Component Payment Scheme Data Component
o when StatusType is set to Delivery, it should o when StatusType is set to Delivery, it should
contain the DelivHandlerDelivId from the contain the DelivHandlerDelivId from the
Delivery Note Component Delivery Note Component
o when StatusType is set to Authentication, it o when StatusType is set to Authentication, it
should contain the AuthenticationId from the should contain the AuthenticationId from the
Authentication Request Component Authentication Request Component
This attribute should be absent in the Inquiry This attribute should be absent in the Inquiry
Request message when the Consumer has not been Request message when the Consumer has not been
given such a reference number by the IOTP Service given such a reference number by the IOTP Service
Provider. Provider.
This attribute can be used in an inside an Inquiry This attribute can be used inside an Inquiry
Response Block (see section 8.13) to give the Response Block (see section 8.13) to give the
reference number for a transaction which has reference number for a transaction which has
previously been unavailable. previously been unavailable.
For example, the package tracking number might not For example, the package tracking number might not
be assigned at the time a delivery response was be assigned at the time a delivery response was
received. However, if the Consumer issues a received. However, if the Consumer issues a
Baseline Transaction Status Inquiry later, the Baseline Transaction Status Inquiry later, the
Delivery Handler can put the package tracking Delivery Handler can put the package tracking
number into this attribute in the Inquiry Response number into this attribute in the Inquiry Response
skipping to change at page 123, line 38 skipping to change at page 123, line 31
7.16.4 Authentication Completion Codes 7.16.4 Authentication Completion Codes
The Completion Code is only required if the ProcessState attribute is set The Completion Code is only required if the ProcessState attribute is set
to Failed. The following table contains the valid values for the to Failed. The following table contains the valid values for the
CompletionCode that may be used. It is recommended that the StatusDesc CompletionCode that may be used. It is recommended that the StatusDesc
attribute is used to provide further explanation where appropriate. attribute is used to provide further explanation where appropriate.
Value Description Value Description
AutEeCancel Authenticatee Cancel. The organisation being AutEeCancel Authenticatee Cancel. The Organisation being
authenticated declines to be authenticated for some authenticated declines to be authenticated for some
reason. This could be, for example because the reason. This could be, for example because the
signature on an Authentication Request was invalid or signature on an Authentication Request was invalid or
the Authenticator was not known or acceptable to the the Authenticator was not known or acceptable to the
Authenticatee. Authenticatee.
Recovery is not possible. Recovery is not possible.
AutOrCancel Authenticator Cancel. The organisation requesting AutOrCancel Authenticator Cancel. The Organisation requesting
authentication declines to validate the authentication declines to validate the
Authentication Response received for some reason and Authentication Response received for some reason and
cancels the transaction. cancels the transaction.
Recovery is not possible. Recovery is not possible.
NoAuthReq Authentication Request Not Available. The NoAuthReq Authentication Request Not Available. The
Authenticatee does not have the data that must be Authenticatee does not have the data that must be
provided so that they may be successfully provided so that they may be successfully
authenticated. For example a password may have been authenticated. For example a password may have been
skipping to change at page 125, line 12 skipping to change at page 125, line 5
No recovery possible. No recovery possible.
7.16.5 Undefined Completion Codes 7.16.5 Undefined Completion Codes
The Completion Code is only required if the ProcessState attribute is set The Completion Code is only required if the ProcessState attribute is set
to Failed. The following table contains the valid values for the to Failed. The following table contains the valid values for the
CompletionCode that may be used. It is recommended that the StatusDesc CompletionCode that may be used. It is recommended that the StatusDesc
attribute is used to provide further explanation where appropriate. attribute is used to provide further explanation where appropriate.
InMsgHardError The type of Request Block could not be identified or Value Description
was inconsistent. Therefore no single Document
Exchange could be identified. This will cause a Hard InMsgHardError Input Message Hard Error. The type of Request Block
Error in the transaction 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 7.16.6 Transaction Inquiry Completion Codes
The Completion Code is only required if the ProcessState attribute is set The Completion Code is only required if the ProcessState attribute is set
to Failed. The following table contains the valid values for the to Failed. The following table contains the valid values for the
CompletionCode that may be used. It is recommended that the StatusDesc CompletionCode that may be used. It is recommended that the StatusDesc
attribute is used to provide further explanation where appropriate. attribute is used to provide further explanation where appropriate.
UnAuthReq The recipient of the Transaction Status Request Value Description
declines to respond to the request.
UnAuthReq Unauthorised Request. The recipient of the
Transaction Status Request declines to respond to the
request.
7.17 Trading Role Data Component 7.17 Trading Role Data Component
The Trading Role Data Component contains opaque data which is needs to be The Trading Role Data Component contains opaque data which needs to be
communicated between the Trading Roles involved in an IOTP Transaction. communicated between the Trading Roles involved in an IOTP Transaction.
Trading Role Components identify: Trading Role Components identify:
o the organisation that generated the component, and o the Organisation that generated the component, and
o the organisation that is to receive it. o the Organisation that is to receive it.
They are first generated and included in a "Response" Block, and then They are first generated and included in a "Response" Block, and then
copied to the appropriate "Request" Block. For example a Payment Handler copied to the appropriate "Request" Block. For example a Payment Handler
might need to inform a Delivery Handler that a credit card payment had might need to inform a Delivery Handler that a credit card payment had
been authorised but not captured. There may also be other information been authorised but not captured. There may also be other information
that the Payment Handler has generated where the format is privately that the Payment Handler has generated where the format is privately
agreed with the Delivery Handler which needs to be communicated. In agreed with the Delivery Handler which needs to be communicated. In
another example a Merchant might need to provide a Payment Handler with another example a Merchant might need to provide a Payment Handler with
some specific information about a Consumer so that consumer can acquire some specific information about a Consumer so that consumer can acquire
double loyalty points with the payment. double loyalty points with the payment.
skipping to change at page 126, line 50 skipping to change at page 126, line 46
o whenever a "Request" Block is being sent, check to see if it is being 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 sent to one of the Organisations identified by the DestinationElRefs
attribute. If it is then include in the "Request" block: attribute. If it is then include in the "Request" block:
- the Trading Role Data Component as well as, - the Trading Role Data Component as well as,
- the Organisation Component of the Organisation identified by the - the Organisation Component of the Organisation identified by the
OriginatorElRef attribute (if not already present) OriginatorElRef attribute (if not already present)
7.18 Inquiry Type Component 7.18 Inquiry Type Component
The Inquiry Component contains the information which indicates the type The Inquiry Type Component contains the information which indicates the
of process that is being inquired upon. Its definition is as follows. type of process that is being inquired upon. Its definition is as
follows.
<!ELEMENT InquiryType EMPTY > <!ELEMENT InquiryType EMPTY >
<!ATTLIST InquiryType <!ATTLIST InquiryType
ID ID #REQUIRED ID ID #REQUIRED
Type NMTOKEN #REQUIRED Type NMTOKEN #REQUIRED
ElRef NMTOKEN #IMPLIED ElRef NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIED > ProcessReference CDATA #IMPLIED >
Attributes: Attributes:
skipping to change at page 131, line 17 skipping to change at page 131, line 17
Merchant in a TPO Selection Block Merchant in a TPO Selection Block
o from the Offer Response Block: o from the Offer Response Block:
- the Order Component - the Order Component
- each of the Payment Components - each of the Payment Components
- the Delivery Component - the Delivery Component
- each of the Authentication Request Components - each of the Authentication Request Components
- any Trading Role Data Components - any Trading Role Data Components
The Offer Response Signature should also contain Digest elements for the The Offer Response Signature should also contain Digest elements for the
components that describe each of the organisations that may or will need components that describe each of the Organisations that may or will need
to verify the signature. This involves: to verify the signature. This involves:
o if the Merchant has received a TPO Selection Block containing Brand o if the Merchant has received a TPO Selection Block containing Brand
Selection Components, then generate a Digest element for the Payment Selection Components, then generate a Digest element for the Payment
Handler identified by the Brand Selection Component and the Delivery Handler identified by the Brand Selection Component and the Delivery
Handler identified by the Delivery Component. See section 6.3.1 Check Handler identified by the Delivery Component. See section 6.3.1 Check
Request Block sent Correct Organisation for a description of how this Request Block sent Correct Organisation for a description of how this
can be done. can be done.
o if the Merchant is not expecting to receive a TPO Selection Block then o if the Merchant is not expecting to receive a TPO Selection Block then
skipping to change at page 134, line 5 skipping to change at page 134, line 5
See note at the start of section 7.19 Signature Component for See note at the start of section 7.19 Signature Component for
more details. more details.
[Note End] [Note End]
A Certificate Component contains a Digital Certificate. They are used A Certificate Component contains a Digital Certificate. They are used
only when required, for example, when asymmetric cryptography is being only when required, for example, when asymmetric cryptography is being
used and the recipient of the signature that needs to check has not used and the recipient of the signature that needs to check has not
already received the Public Key. already received the Public Key.
The structure of a Certificate Component is as follows: The structure of a Certificate Component is defined in [IOTPDSIG].
<!ELEMENT Certificate (
IssuerAndSerialNumber
( Value | Locator ) )>
<!ATTLIST Certificate
ID ID #IMPLIED
type NMTOKEN #REQUIRED >
<!ELEMENT IssuerAndSerialNumber EMPTY >
<!ATTLIST IssuerAndSerialNumber
issuer CDATA #REQUIRED
number CDATA #REQUIRED >
<!ELEMENT Value ( #PCDATA ) >
<!ATTLIST Value
id ID #IMPLIED
encoding ( base64 | none ) #REQUIRED >
<!ELEMENT Locator EMPTY>
<!ATTLIST Locator
href CDATA #REQUIRED >
7.20.1 IOTP usage of signature elements and attributes 7.20.1 IOTP usage of signature elements and attributes
Detailed definitions of the above elements and attributes are contained Detailed definitions of the above elements and attributes are contained
in [IOTPDSIG]. The following contains additional information that in [IOTPDSIG]. The following contains additional information that
describes how these elements and attributes are used by IOTP. describes how these elements and attributes are used by IOTP.
CERTIFICATE COMPONENT CERTIFICATE COMPONENT
The ID attribute is mandatory. The ID attribute is mandatory.
skipping to change at page 138, line 20 skipping to change at page 138, line 4
otherwise reported. Individual implementations may translate this into otherwise reported. Individual implementations may translate this into
alternative languages at their discretion. alternative languages at their discretion.
An Error Code must not be more that 14 characters long. An Error Code must not be more that 14 characters long.
Value Description Value Description
Reserved Reserved. This error is reserved by the Reserved Reserved. This error is reserved by the
vendor/developer of the software. Contact the vendor/developer of the software. Contact the
vendor/developer of the software for more information vendor/developer of the software for more information
Value Description
See the SoftwareId attribute of the Message Id See the SoftwareId attribute of the Message Id
element in the Transaction Reference Block(section element in the Transaction Reference Block(section
3.3). 3.3).
XmlNotWellFrmd XML not well formed. The XML document is not well XmlNotWellFrmd XML not well formed. The XML document is not well
formed. See [XML] for the meaning of "well formed". formed. See [XML] for the meaning of "well formed".
Even if the XML is not well formed, it should still Even if the XML is not well formed, it should still
be scanned to find the Transaction Reference Block so be scanned to find the Transaction Reference Block so
that a properly formed Error Response may be that a properly formed Error Response may be
generated. generated.
skipping to change at page 139, line 4 skipping to change at page 138, line 43
ElUnexpected Unexpected element. Although the XML document is well ElUnexpected Unexpected element. Although the XML document is well
formed and valid, an element is present that is not formed and valid, an element is present that is not
expected in the particular context according to the expected in the particular context according to the
rules and constraints contained in this rules and constraints contained in this
specification. specification.
ElNotSupp Element not supported. Although the document is well ElNotSupp Element not supported. Although the document is well
formed and valid, an element is present that: formed and valid, an element is present that:
o is consistent with the rules and constraints o is consistent with the rules and constraints
contained in this specification, but contained in this specification, but
Value Description
o is not supported by the IOTP Aware Application o is not supported by the IOTP Aware Application
which is processing the IOTP Message. which is processing the IOTP Message.
ElMissing Element missing. Although the document is well formed ElMissing Element missing. Although the document is well formed
and valid, an element is missing that should have and valid, an element is missing that should have
been present if the rules and constraints contained been present if the rules and constraints contained
in this specification are followed. in this specification are followed.
In this case set the PackagedContent of the Error In this case set the PackagedContent of the Error
Component to the type of the missing element. Component to the type of the missing element.
ElContIllegal Element content illegal. Although the document is ElContIllegal Element content illegal. Although the document is
well formed and valid, the element Content contains well formed and valid, the element Content contains
values which do not conform to the rules and values which do not conform to the rules and
Value Description
constraints contained in this specification. constraints contained in this specification.
EncapProtErr Encapsulated protocol error. Although the document is EncapProtErr Encapsulated protocol error. Although the document is
well formed and valid, the PackagedContent of an well formed and valid, the PackagedContent of an
element contains data from an encapsulated protocol element contains data from an encapsulated protocol
which contains errors. which contains errors.
AttUnexpected Unexpected attribute. Although the XML document is AttUnexpected Unexpected attribute. Although the XML document is
well formed and valid, the presence of the attribute well formed and valid, the presence of the attribute
is not expected in the particular context according is not expected in the particular context according
skipping to change at page 139, line 54 skipping to change at page 139, line 40
In this case set the PackagedContent of the Error In this case set the PackagedContent of the Error
Component to the type of the missing attribute. Component to the type of the missing attribute.
AttValIllegal Attribute value illegal. The attribute contains a AttValIllegal Attribute value illegal. The attribute contains a
value which does not conform to the rules and value which does not conform to the rules and
constraints contained in this specification. constraints contained in this specification.
AttValNotRecog Attribute Value Not Recognised. The attribute AttValNotRecog Attribute Value Not Recognised. The attribute
contains a value which the IOTP Aware Application contains a value which the IOTP Aware Application
generating the message reporting the error could not generating the message reporting the error could not
recognise even though it should have been able to recognise.
since the information had been provided in an earlier
IOTP message.
Value Description
MsgTooLarge Message too large. The message is too large to be MsgTooLarge Message too large. The message is too large to be
processed by the IOTP Aware Application. processed by the IOTP Aware Application.
ElTooLarge Element too large. The element is too large to be ElTooLarge Element too large. The element is too large to be
processed by the IOTP Aware Application processed by the IOTP Aware Application
ValueTooSmall Value too small or early. The value of all or part of ValueTooSmall Value too small or early. The value of all or part of
the Content of an element or an attribute, although the Content of an element or an attribute, although
valid, is too small. valid, is too small.
ValueTooLarge Value too large or in the future. The value of all or ValueTooLarge Value too large or in the future. The value of all or
part of the Content of an element or an attribute, part of the Content of an element or an attribute,
although valid, is too large. although valid, is too large.
ElInconsistent Element Inconsistent. Although the document is well ElInconsistent Element Inconsistent. Although the document is well
Value Description
formed and valid, according to the rules and formed and valid, according to the rules and
constraints contained in this specification: constraints contained in this specification:
o the content of an element is inconsistent with the o the content of an element is inconsistent with the
content of other elements or their attributes, or content of other elements or their attributes, or
o the value of an attribute is inconsistent with the o the value of an attribute is inconsistent with the
value of one or more other attributes. value of one or more other attributes.
In this case create ErrorLocation elements which In this case create ErrorLocation elements which
identify all the attributes or elements which are identify all the attributes or elements which are
inconsistent. inconsistent.
skipping to change at page 141, line 5 skipping to change at page 140, line 41
the MinRetrySecs attribute, then the original message the MinRetrySecs attribute, then the original message
should be resent. should be resent.
SystemBusy SystemBusy. This error code is only used with a SystemBusy SystemBusy. This error code is only used with a
Severity of Transient Error. It indicates that the Severity of Transient Error. It indicates that the
server that received a message is currently too busy server that received a message is currently too busy
to handle the message. If no response is received by to handle the message. If no response is received by
the time indicated by the MinRetrySecs attribute, the time indicated by the MinRetrySecs attribute,
then the original message should be resent. then the original message should be resent.
Value Description
[Note] If the server/system handling the [Note] If the server/system handling the
Transport Mechanism (e.g. HTTP) is busy Transport Mechanism (e.g. HTTP) is busy
then a Transport Specific error message then a Transport Specific error message
should be used instead of an IOTP Error should be used instead of an IOTP Error
message. This code should be used in message. This code should be used in
association with IOTP servers/systems or association with IOTP servers/systems or
other servers/systems to which the IOTP other servers/systems to which the IOTP
server is connected. server is connected.
[Note End] [Note End]
UnknownError Unknown Error. Indicates that the transaction cannot UnknownError Unknown Error. Indicates that the transaction cannot
complete for some reason that is not covered complete for some reason that is not covered
explicitly by any of the other errors. The ErrorDesc explicitly by any of the other errors. The ErrorDesc
attribute should be used to indicate the nature of attribute should be used to indicate the nature of
the problem. the problem.
Value Description
This could be used to indicate, for example, an This could be used to indicate, for example, an
internal error in a backend server or client process internal error in a backend server or client process
of some kind. of some kind.
7.21.3 Error Location Element 7.21.3 Error Location Element
An Error Location Element identifies an element and optionally an An Error Location Element identifies an element and optionally an
attribute in the message in error which is associated with the error. It attribute in the message in error which is associated with the error. It
contains a reference to the IOTP Message, Trading Block, Trading contains a reference to the IOTP Message, Trading Block, Trading
Component, element and attribute, which is in error. Component, element and attribute, which is in error.
skipping to change at page 145, line 42 skipping to change at page 145, line 42
ProtocolOptions The Protocol Options Component (see section ProtocolOptions The Protocol Options Component (see section
7.1)defines the options which apply to the whole 7.1)defines the options which apply to the whole
IOTP Transaction (see section 9). IOTP Transaction (see section 9).
BrandList This Brand List Component contains one or more BrandList This Brand List Component contains one or more
payment brands and protocols which may be selected payment brands and protocols which may be selected
(see section 7.7). (see section 7.7).
Org The Organisation Components (see section 7.6) Org The Organisation Components (see section 7.6)
identify the organisations and their roles in the identify the Organisations and their roles in the
IOTP Transaction. The roles and organisations IOTP Transaction. The roles and Organisations
which must be present will depend on the which must be present will depend on the
particular type of IOTP Transaction. See the particular type of IOTP Transaction. See the
definition of each transaction in section 9. definition of each transaction in section 9.
Internet Open Trading Protocol Transactions. Internet Open Trading Protocol Transactions.
The TPO Block should contain: The TPO Block should contain:
o the Protocol Options Component o the Protocol Options Component
o the Organisation Component with the Trading Role of Merchant o the Organisation Component with the Trading Role of Merchant
skipping to change at page 148, line 10 skipping to change at page 148, line 10
The Authentication Request Block contains the data which is used by one The Authentication Request Block contains the data which is used by one
Trading Role to obtain information about and optionally authenticate Trading Role to obtain information about and optionally authenticate
another Trading Role. another Trading Role.
In outline it contains: In outline it contains:
o information about how the authentication itself will be carried out, o information about how the authentication itself will be carried out,
and/or and/or
o a request for additional information about the organisation being o a request for additional information about the Organisation being
authenticated. authenticated.
Its definition is as follows. Its definition is as follows.
<!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?) > <!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?) >
<!ATTLIST AuthReqBlk <!ATTLIST AuthReqBlk
ID ID #REQUIRED > ID ID #REQUIRED >
Attributes: Attributes:
skipping to change at page 150, line 48 skipping to change at page 150, line 48
section 7.8) for each payment to be made in the section 7.8) for each payment to be made in the
IOTP Transaction. IOTP Transaction.
Payment The Payment Components contain information about Payment The Payment Components contain information about
the payment which is being made see section 7.9. the payment which is being made see section 7.9.
PaySchemeData The Payment Scheme Component contains payment PaySchemeData The Payment Scheme Component contains payment
scheme specific data see section 7.10. scheme specific data see section 7.10.
Org The Organisation Component contains details of Org The Organisation Component contains details of
organisations involved in the payment (see section Organisations involved in the payment (see section
7.6). The Organisations present are dependent on 7.6). The Organisations present are dependent on
the IOTP Transaction and the data which is to be the IOTP Transaction and the data which is to be
signed. See section 6 Digital Signatures for more signed. See section 6 Digital Signatures for more
details. details.
TradingRoleData The Trading Role Data Component contains opaque TradingRoleData The Trading Role Data Component contains opaque
data which is needs to be communicated between the data which is needs to be communicated between the
Trading Roles involved in an IOTP Transaction (see Trading Roles involved in an IOTP Transaction (see
section 7.17). section 7.17).
skipping to change at page 151, line 24 skipping to change at page 151, line 24
o the Brand List Component for the Payment o the Brand List Component for the Payment
o the Brand Selection Component for the Brand List o the Brand Selection Component for the Brand List
o the Organisation Component for the Payment Handler of the Payment o the Organisation Component for the Payment Handler of the Payment
o the Organisation Component (if any) for the Organisation which carried o the Organisation Component (if any) for the Organisation which carried
out the previous step, for example another Payment Handler out the previous step, for example another Payment Handler
o the Organisation Component for the organisation which is to carry out 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 the next step, if any. This may be, for example, either a Delivery
Handler or a Payment Handler. Handler or a Payment Handler.
o the Organisation Components for any additional Organisations that the o the Organisation Components for any additional Organisations that the
Merchant has included in the Offer Response Block Merchant has included in the Offer Response Block
o an Optional Payment Scheme Data Component, if required by the Payment o an Optional Payment Scheme Data Component, if required by the Payment
Method as defined in the IOTP supplement for the payment method Method as defined in the IOTP supplement for the payment method
o any Trading Role Data Components that may be required (see section o any Trading Role Data Components that may be required (see section
skipping to change at page 153, line 36 skipping to change at page 153, line 36
Payment Response) on which this step is Payment Response) on which this step is
dependent. It is used to indicate the success dependent. It is used to indicate the success
or failure of those steps. Delivery should only or failure of those steps. Delivery should only
occur if the previous steps were successful. occur if the previous steps were successful.
Order The Order Component contains details about the Order The Order Component contains details about the
goods, services or financial transaction which goods, services or financial transaction which
is taking place see section 7.5. is taking place see section 7.5.
The Organisation Components (see section 7.6) The Organisation Components (see section 7.6)
identify the organisations and their roles in identify the Organisations and their roles in
Org the IOTP Transaction. The roles and Org the IOTP Transaction. The roles and
organisations which must be present will depend Organisations which must be present will depend
on the particular type of IOTP Transaction. See on the particular type of IOTP Transaction. See
the definition of each transaction in section the definition of each transaction in section
9. Internet Open Trading Protocol Transactions. 9. Internet Open Trading Protocol Transactions.
Delivery The Delivery Component contains details of the Delivery The Delivery Component contains details of the
delivery to be made (see section 7.13). delivery to be made (see section 7.13).
ConsumerDeliveryData Optional. Contains an identifier specified by ConsumerDeliveryData Optional. Contains an identifier specified by
the Consumer which, if returned by the Delivery the Consumer which, if returned by the Delivery
Handler will enable the Consumer to identify Handler will enable the Consumer to identify
skipping to change at page 163, line 10 skipping to change at page 163, line 10
The six Document Exchanges are: The six Document Exchanges are:
o Authentication. This is a direct implementation of the Authentication o Authentication. This is a direct implementation of the Authentication
Trading Exchange Trading Exchange
o Brand Dependent Offer. This is the Offer Trading Exchange combined with o Brand Dependent Offer. This is the Offer Trading Exchange combined with
the Brand Selection part of the Payment Trading Exchange. Its purpose the Brand Selection part of the Payment Trading Exchange. Its purpose
is to provide the Merchant with information on the Brand selected so is to provide the Merchant with information on the Brand selected so
that the content of the Offer Response may be adapted accordingly that the content of the Offer Response may be adapted accordingly
o Brand Independent Offer. This is also an Offer Trading Exchange. o Brand Independent Offer. This is also an Offer Trading Exchange.
However, in this instance, the content of the Offer Response does However, in this instance, the content of the Offer Response does not
depend on the Brand selected. depend on the Brand selected.
o Payment. This is a direct implementation of the Payment part of a o Payment. This is a direct implementation of the Payment part of a
Payment Trading Exchange Payment Trading Exchange
o Delivery. This is a direct implementation of the Delivery Exchange o Delivery. This is a direct implementation of the Delivery Exchange
o Delivery with Payment. This is an implementation of combined Payment o Delivery with Payment. This is an implementation of combined Payment
and Delivery Trading Exchanges and Delivery Trading Exchanges
skipping to change at page 164, line 33 skipping to change at page 164, line 33
messages since these are handled the same way irrespective of messages since these are handled the same way irrespective of
the context in which the message is being sent. See section 4 the context in which the message is being sent. See section 4
for more details. for more details.
[Note End] [Note End]
9.1.1 Authentication Document Exchange 9.1.1 Authentication Document Exchange
The Authentication Document Exchange is a direct implementation of the The Authentication Document Exchange is a direct implementation of the
Authentication Trading Exchange (see section 2.2.4). It involves: Authentication Trading Exchange (see section 2.2.4). It involves:
o an Authenticator - the organisation which is requesting the o an Authenticator - the Organisation which is requesting the
authentication, and authentication, and
o an Authenticatee - the organisation being authenticated. o an Authenticatee - the Organisation being authenticated.
The authentication consists of: The authentication consists of:
o an Authentication Request being sent by the Authenticator to the o an Authentication Request being sent by the Authenticator to the
Authenticatee, Authenticatee,
o an Authentication Response being sent in return by the Authenticatee to o an Authentication Response being sent in return by the Authenticatee to
the Authenticator which is then checked, and the Authenticator which is then checked, and
o an Authentication Status being sent by the Authenticator to the o an Authentication Status being sent by the Authenticator to the
skipping to change at page 165, line 18 skipping to change at page 165, line 18
Authenticatee to verify the credentials of the Authenticator. Authenticatee to verify the credentials of the Authenticator.
The IOTP Messages which are involved are illustrated by the diagram The IOTP Messages which are involved are illustrated by the diagram
below. below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Organisation 1 Organisation 1
(Authenticatee) (Authenticatee)
| Organisation 2 | Organisation 2
| (Authenticator) | (Authenticator)
STEP | | STEP | |
1. First organisation takes an action (for example by pressing a 1. First Organisation takes an action (for example by pressing a
button on an HTML page) which requires that the organisation button on an HTML page) which requires that the Organisation
is authenticated is authenticated
1 --> 2 Authentication Need (outside scope of IOTP) 1 --> 2 Authentication Need (outside scope of IOTP)
2. The second organisation generates: an Authentication Request 2. The second Organisation generates: an Authentication Request
Block containing one or more Authentication Request Block containing one or more Authentication Request
Components and/or a Trading Role Information Request Components and/or a Trading Role Information Request
Component, then sends it to the first organisation Component, then sends it to the first Organisation
1 <-- 2 TPO & AUTHENTICATION REQUEST. IotpMsg: Trans Ref Block; 1 <-- 2 TPO & AUTHENTICATION REQUEST. IotpMsg: Trans Ref Block;
Signature Block (optional); TPO Block; Auth Request Block Signature Block (optional); TPO Block; Auth Request Block
3. IOTP aware application started. If a Signature Block is 3. IOTP aware application started. If a Signature Block is
present, the first organisation may use this to check the present, the first Organisation may use this to check the
credentials of the second organisation. If credentials are credentials of the second Organisation. If credentials are
OK, the first organisation selects an Authentication Request OK, the first Organisation selects an Authentication Request
to use (if present and more than one), then uses the to use (if present and more than one), then uses the
authentication algorithm selected to generate an authentication algorithm selected to generate an
Authentication Response Block. If present, the Trading Role Authentication Response Block. If present, the Trading Role
Information Request Component is used to generate Information Request Component is used to generate
Organisation Components. Finally a Signature Component is Organisation Components. Finally a Signature Component is
created if required and all components are then sent back to created if required and all components are then sent back to
the second organisation for validation. the second Organisation for validation.
1 --> 2 AUTHENTICATION RESPONSE. IotpMsg; Trans Ref Block; Signature 1 --> 2 AUTHENTICATION RESPONSE. IotpMsg; Trans Ref Block; Signature
Block (optional) ; Auth Response Block Block (optional) ; Auth Response Block
4. The second organisation checks the Authentication Response 4. The second Organisation checks the Authentication Response
against the data in the Authentication Request Block to check against the data in the Authentication Request Block to check
that the first organisation is who they appear to be, and that the first Organisation is who they appear to be, and
sends an Authentication Status Block to the first sends an Authentication Status Block to the first
Organisation to indicate the result then stops. Organisation to indicate the result then stops.
1 <-- 2 AUTHENTICATION STATUS. IotpMsg: Trans Ref Block; Signature 1 <-- 2 AUTHENTICATION STATUS. IotpMsg: Trans Ref Block; Signature
Block (optional); Auth Response Block Block (optional); Auth Response Block
5. The first organisation checks the authentication Status Block 5. The first Organisation checks the authentication Status Block
and optionally keeps information on the IOTP transaction for and optionally keeps information on the IOTP transaction for
record keeping purposes and stops. record keeping purposes and stops.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 18 Authentication Document Exchange Figure 18 Authentication Document Exchange
9.1.1.1 Message Processing Guidelines 9.1.1.1 Message Processing Guidelines
On receiving a TPO & Authentication Request IOTP Message (see below), an On receiving a TPO & Authentication Request IOTP Message (see below), an
skipping to change at page 171, line 47 skipping to change at page 171, line 47
(see section 7.16.4) set to either: MerchCancelled or Unspecified. (see section 7.16.4) set to either: MerchCancelled or Unspecified.
On receiving an Offer Response IOTP Message (see below) the Consumer may On receiving an Offer Response IOTP Message (see below) the Consumer may
either: either:
o generate and send the next IOTP Message in the IOTP transaction and 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 send it to the required Trading Role. This is dependent on the IOTP
Transaction, or Transaction, or
o indicate failure to continue with the IOTP Transaction by sending a o indicate failure to continue with the IOTP Transaction by sending a
Cancel Block back to the Consumer containing a Status Component with a Cancel Block back to the Merchant containing a Status Component with a
StatusType of Offer, a ProcessState of Failed and the CompletionCode StatusType of Offer, a ProcessState of Failed and the CompletionCode
(see section 7.16.4) set to either: ConsCancelled or Unspecified. (see section 7.16.4) set to either: ConsCancelled or Unspecified.
If the Merchant receives an IOTP Message containing a Cancel block, then If the Merchant receives an IOTP Message containing a Cancel block, then
the Consumer is likely to go to the CancelNetLocn specified on the the Consumer is likely to go to the CancelNetLocn specified on the
Trading Role Element in the Organisation Component for the Merchant. Trading Role Element in the Organisation Component for the Merchant.
If the Consumer receives an IOTP Message containing a Cancel block, then If the Consumer receives an IOTP Message containing a Cancel block, then
the information contained in the IOTP Message should be reported to the the information contained in the IOTP Message should be reported to the
Consumer but no further action taken. Consumer but no further action taken.
skipping to change at page 174, line 7 skipping to change at page 174, line 7
- Consumer who is carrying out the transaction - Consumer who is carrying out the transaction
- the PaymentHandler(s) for the payment. The "ID" of the Payment - the PaymentHandler(s) for the payment. The "ID" of the Payment
Handler Organisation Component is contained within the PhOrgRef Handler Organisation Component is contained within the PhOrgRef
attribute of the Payment Component attribute of the Payment Component
If the IOTP Transaction includes a Delivery then the TPO Block must also If the IOTP Transaction includes a Delivery then the TPO Block must also
contain: contain:
o Organisation Components with the following roles: o Organisation Components with the following roles:
- DeliveryHandler who will be delivering the goods or services - DeliveryHandler who will be delivering the goods or services
- DelivTo i.e. the person or organisation which is to take delivery - DelivTo i.e. the person or Organisation which is to take delivery
AUTHENTICATION STATUS AND SIGNATURE BLOCKS AUTHENTICATION STATUS AND SIGNATURE BLOCKS
If the Offer Document Exchange was preceded by an Authentication Document If the Offer Document Exchange was preceded by an Authentication Document
Exchange, then the TPO IOTP Message may also contain: Exchange, then the TPO IOTP Message may also contain:
o an Authentication Status Block (see section 8.6), and o an Authentication Status Block (see section 8.6), and
o an optional Signature Block (Authentication Status) Signature Block o an optional Signature Block (Authentication Status) Signature Block
skipping to change at page 181, line 15 skipping to change at page 181, line 15
o the Transaction Reference Block (see section 3.3) for the IOTP Message o the Transaction Reference Block (see section 3.3) for the IOTP Message
which contains the first usage of the Payment Response Block, which contains the first usage of the Payment Response Block,
o the Transaction Id Component (see section 3.3.1) within the Transaction o the Transaction Id Component (see section 3.3.1) within the Transaction
Reference Block that globally uniquely identifies the IOTP Transaction, Reference Block that globally uniquely identifies the IOTP Transaction,
o the Payment Receipt Component from the Payment Response Block, o the Payment Receipt Component from the Payment Response Block,
o the Payment Note Component from the Payment Response Block, o the Payment Note Component from the Payment Response Block,
o the other Components referenced by the PayReceiptRefs attribute (if o the other Components referenced by the PayReceiptNameRefs attribute (if
present) of the Payment Receipt Component, present) of the Payment Receipt Component,
o the Status Component from the Payment Response Block, o the Status Component from the Payment Response Block,
o any Trading Role Data Components in the Payment Response Block, and o any Trading Role Data Components in the Payment Response Block, and
o all the Signature Components contained in the Payment Request Block if o all the Signature Components contained in the Payment Request Block if
present. present.
9.1.4 Delivery Document Exchange 9.1.4 Delivery Document Exchange
skipping to change at page 183, line 14 skipping to change at page 183, line 14
SIGNATURE BLOCK (DELIVERY REQUEST) SIGNATURE BLOCK (DELIVERY REQUEST)
If the preceding Offer Document Exchange included an Offer Response If the preceding Offer Document Exchange included an Offer Response
Signature or the Payment Document Exchange included a Payment Response Signature or the Payment Document Exchange included a Payment Response
Signature, then they should both be copied to the Signature Block. Signature, then they should both be copied to the Signature Block.
9.1.4.3 Delivery Response IOTP Message 9.1.4.3 Delivery Response IOTP Message
The Delivery Response IOTP Message contains a Delivery Response Block and The Delivery Response IOTP Message contains a Delivery Response Block and
an options Signature Block. an optional Signature Block.
DELIVERY RESPONSE BLOCK DELIVERY RESPONSE BLOCK
The Delivery Response Block contains: The Delivery Response Block contains:
o one Delivery Note Component (see section 7.15) which contains delivery o one Delivery Note Component (see section 7.15) which contains delivery
instructions about the delivery of goods or services instructions about the delivery of goods or services
SIGNATURE BLOCK (DELIVERY RESPONSE) SIGNATURE BLOCK (DELIVERY RESPONSE)
skipping to change at page 195, line 37 skipping to change at page 195, line 37
o Brand Dependent Value Exchange. Where the content of the offer, for o Brand Dependent Value Exchange. Where the content of the offer, for
example the rate at which one form of value is exchanged for another, example the rate at which one form of value is exchanged for another,
is dependent on the payment brands and protocols selected by the is dependent on the payment brands and protocols selected by the
consumer, and consumer, and
o Brand Independent Value Exchange. Where the content of the offer is not o Brand Independent Value Exchange. Where the content of the offer is not
dependent on the payment brands and protocols selected. dependent on the payment brands and protocols selected.
[Note] In the above the role is a Merchant even though the [Note] In the above the role is a Merchant even though the
organisation carrying out the Value Exchange may be a Bank or Organisation carrying out the Value Exchange may be a Bank or
some other Financial Institution. This is because the Bank is some other Financial Institution. This is because the Bank is
acting as a merchant in that they are making an offer which acting as a merchant in that they are making an offer which
the Consumer can either accept or decline. the Consumer can either accept or decline.
[Note End] [Note End]
The TPO Block and Offer Response Block may only be combined into the same The TPO Block and Offer Response Block may only be combined into the same
IOTP Message if the content of the Offer Response Block does not change IOTP Message if the content of the Offer Response Block does not change
as a result of selecting the payment brands and payment protocols to be as a result of selecting the payment brands and payment protocols to be
used in the Value Exchange. used in the Value Exchange.
skipping to change at page 197, line 41 skipping to change at page 197, line 41
| DELIVERY | | PAYMENT | | | | DELIVERY | | PAYMENT | | |
| | | {second)| | | | | | {second)| | |
---------- --------- | | ---------- --------- | |
| | | v | | | v
----------------------------------------------> STOP ----------------------------------------------> STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 31 Valid Combinations of Document Exchanges Figure 31 Valid Combinations of Document Exchanges
1) If first IOTP Message of an IOTP Transaction contains an Authentication 1)
If first IOTP Message of an IOTP Transaction contains an Authentication
Request then: Request then:
a) IOTP Transaction includes an Authentication Document Exchange (see a) IOTP Transaction includes an Authentication Document Exchange (see
section 9.1.1). (Note 1) section 9.1.1). (Note 1)
b) If the last IOTP Message of the Authentication Document Exchange b) If the last IOTP Message of the Authentication Document Exchange
includes a TPO Block and an Offer Response Block then: includes a TPO Block and an Offer Response Block then:
i)IOTP Transaction includes a Brand Independent Offer Document i)IOTP Transaction includes a Brand Independent Offer Document
Exchange (see section 9.1.2.2). (Note 2) Exchange (see section 9.1.2.2). (Note 2)
skipping to change at page 198, line 15 skipping to change at page 198, line 15
i)IOTP Transaction includes a Brand Dependent Offer Document Exchange i)IOTP Transaction includes a Brand Dependent Offer Document Exchange
(see section 9.1.2.1). (Note 2) (see section 9.1.2.1). (Note 2)
d) Otherwise (Authentication Status IOTP Message of the Authentication d) Otherwise (Authentication Status IOTP Message of the Authentication
Document Exchange contains neither a TPO Block but nor an Offer Document Exchange contains neither a TPO Block but nor an Offer
Response Block) Response Block)
i)IOTP Transaction consists of just an Authentication Document i)IOTP Transaction consists of just an Authentication Document
Exchange. (Note 3) Exchange. (Note 3)
2) Otherwise (no Authentication Request in first IOTP Message): 2)
Otherwise (no Authentication Request in first IOTP Message):
e) IOTP Transaction does not include an Authentication Document Exchange e) IOTP Transaction does not include an Authentication Document Exchange
(Note 2) (Note 2)
f) If first IOTP Message contains an Offer Response Block, then: f) If first IOTP Message contains an Offer Response Block, then:
i)the IOTP Transaction contains a Brand Independent Offer Document i)the IOTP Transaction contains a Brand Independent Offer Document
Exchange (Note 2) Exchange (Note 2)
g) Otherwise (no Offer Response Block in first IOTP Message): g) Otherwise (no Offer Response Block in first IOTP Message):
i)the IOTP Transaction includes a Brand Dependent Offer Document i)the IOTP Transaction includes a Brand Dependent Offer Document
Exchange (Note 2) Exchange (Note 2)
3) If an Offer Response Block exists in any IOTP message then: 3)
If an Offer Response Block exists in any IOTP message then:
h) If the Offer Response Block contains a Delivery Component then: h) If the Offer Response Block contains a Delivery Component then:
i)If the DelivAndPayResp attribute of the Delivery Component is set i)If the DelivAndPayResp attribute of the Delivery Component is set
to True, then: to True, then:
(1)the IOTP Transaction consists of a Payment And Delivery (1)the IOTP Transaction consists of a Payment And Delivery
Document Exchange (see section 9.1.5) (Note 4) Document Exchange (see section 9.1.5) (Note 4)
ii)otherwise (the DelivAndPayResp attribute of the Delivery ii)otherwise (the DelivAndPayResp attribute of the Delivery
skipping to change at page 199, line 12 skipping to change at page 199, line 12
ii) if the Offer Response Block contains two Payment Components, ii) if the Offer Response Block contains two Payment Components,
then: then:
(1)the IOTP Transaction contains two Payment Document Exchanges. (1)the IOTP Transaction contains two Payment Document Exchanges.
The StartAfter attribute of the Payment Components is used to The StartAfter attribute of the Payment Components is used to
indicate which payment occurs first (Note 6) indicate which payment occurs first (Note 6)
iii)if the Offer Response Block contains no or more than two iii)if the Offer Response Block contains no or more than two
Payment Components, then there is an error Payment Components, then there is an error
4) Otherwise (no Offer Response Block) there is an error. 4)
Otherwise (no Offer Response Block) there is an error.
The following table indicates the types of IOTP Transactions which can The following table indicates the types of IOTP Transactions which can
validly have the conditions indicated above. validly have the conditions indicated above.
Note IOTP Transaction Validity Note IOTP Transaction Validity
1. Any Payment and Authentication IOTP Transaction 1. Any Payment and Authentication IOTP Transaction
2. Any Payment and Authentication IOTP Transaction except Baseline 2. Any Payment and Authentication IOTP Transaction except Baseline
Authentication Authentication
skipping to change at page 203, line 49 skipping to change at page 203, line 49
TRANSACTION REFERENCE BLOCK TRANSACTION REFERENCE BLOCK
A Trading Role making an inquiry must use the identical Transaction Id A Trading Role making an inquiry must use the identical Transaction Id
Component (see section 3.3.1) that was in the original transaction. The Component (see section 3.3.1) that was in the original transaction. The
IotpTransId attribute in this component serves as the key in querying the IotpTransId attribute in this component serves as the key in querying the
transaction logs maintained at the Trading Role's site. The value of the transaction logs maintained at the Trading Role's site. The value of the
ID attribute of the Message Id Component should be different from those ID attribute of the Message Id Component should be different from those
of any in the original transaction (see section 3.4.1). of any in the original transaction (see section 3.4.1).
If up-to-date status information is required then the MsgId Component,
and in particular the ID attribute for the MsgId Component must be
different from any other IOTP Message that has been sent by the Trading
Role. This is required because of the way that Idempotency is handled by
IOTP (see section 4.5.2.2 Checking/Handling Duplicate Messages).
INQUIRY REQUEST BLOCK INQUIRY REQUEST BLOCK
The Inquiry Request Block (see section 8.12) contains the following The Inquiry Request Block (see section 8.12) contains the following
components: components:
o one Inquiry Type Component (see section 7.18). This identifies whether o one Inquiry Type Component (see section 7.18). This identifies whether
the inquiry is on an offer, payment, or delivery. the inquiry is on an offer, payment, or delivery.
o zero or one Payment Scheme Components (see section 7.10). This is for o zero or one Payment Scheme Components (see section 7.10). This is for
encapsulating payment scheme specific inquiry messages for inquiries on encapsulating payment scheme specific inquiry messages for inquiries on
skipping to change at page 212, line 7 skipping to change at page 212, line 7
o a credit card such as MasterCard or Visa; o a credit card such as MasterCard or Visa;
o a debit card such as MasterCard's Maestro; o a debit card such as MasterCard's Maestro;
o a smart card based electronic cash payment instrument such as a Mondex o a smart card based electronic cash payment instrument such as a Mondex
Card, a GeldKarte card or a Visa Cash card Card, a GeldKarte card or a Visa Cash card
o a software based electronic payment account such as a CyberCash or o a software based electronic payment account such as a CyberCash or
DigiCash account. DigiCash account.
All Payment Instruments have a number, typically an account number, by Most Payment Instruments have a number, typically an account number, by
which the Payment Instrument can be identified. which the Payment Instrument can be identified.
11.1.2 Definition of Brand 11.1.2 Definition of Brand
A Brand is the mark which identifies a particular type of Payment A Brand is the mark which identifies a particular type of Payment
Instrument. A list of Brands are the payment options which are presented Instrument. A list of Brands are the payment options which are presented
by the Merchant to the Consumer and from which the Consumer makes a by the Merchant to the Consumer and from which the Consumer makes a
selection. Each Brand may have a different Payment Handler. Examples of selection. Each Brand may have a different Payment Handler. Examples of
Brands include: Brands include:
o payment association and proprietary Brands, for example MasterCard, o payment association and proprietary Brands, for example MasterCard,
Visa, American Express, Diners Club, Mondex, GeldKarte, CyberCash, etc. Visa, American Express, Diners Club, Mondex, GeldKarte, CyberCash, etc.
o promotional brands (see below). These include: o promotional brands (see below). These include:
- store brands, where the Payment Instrument is issued to a Consumer by - store brands, where the Payment Instrument is issued to a Consumer by
a particular Merchant, for example Walmart, Sears, or Marks and a particular Merchant, for example Walmart, Sears, or Marks and
Spencer (UK) Spencer (UK)
- cobrands, for example American Advantage Visa, where an organisation - cobrands, for example American Advantage Visa, where an Organisation
uses their own brand in conjunction with, typically, a payment uses their own brand in conjunction with, typically, a payment
association Brand. association Brand.
11.1.3 Definition of Dual Brand 11.1.3 Definition of Dual Brand
A Dual Brand means that a single payment instrument may be used as if it A Dual Brand means that a single payment instrument may be used as if it
were two separate Brands. For example there could be a single Japanese were two separate Brands. For example there could be a single Japanese
"UC" MasterCard which can be used as either a UC card or a regular "UC" MasterCard which can be used as either a UC card or a regular
MasterCard. The UC card Brand and the MasterCard Brand could each have MasterCard. The UC card Brand and the MasterCard Brand could each have
their own separate Payment Handlers. This means that: their own separate Payment Handlers. This means that:
skipping to change at page 223, line 8 skipping to change at page 223, line 8
name space. It is likely that the name space. It is likely that the
maintenance procedure defined here maintenance procedure defined here
may need to vary over time, as the may need to vary over time, as the
DSIG proposals become more widely DSIG proposals become more widely
adopted. adopted.
[Note End] [Note End]
Element Type/ Attribute Values Element Type/ Attribute Values
Attribute Name Attribute Name
Brand/BrandId The following list of initial BrandIds have been Brand/BrandId The following list of initial BrandIds have been
taken from those organisations that have applied taken from those Organisations that have applied
for SET certificates as at 1st June 1999: for SET certificates as at 1st June 1999:
"Amex" - American Express "Amex" - American Express
"Dankort" - Dankort "Dankort" - Dankort
"JCB" - JCB "JCB" - JCB
"Maestro" - Maestro "Maestro" - Maestro
skipping to change at page 228, line 13 skipping to change at page 228, line 13
recommended although this method cannot be relied upon. recommended although this method cannot be relied upon.
13. Internet Open Trading Protocol Data Type Definition 13. Internet Open Trading Protocol Data Type Definition
This section contains the XML DTD for the Internet Open Trading This section contains the XML DTD for the Internet Open Trading
Protocols. Protocols.
<!-- <!--
****************************************************** ******************************************************
* * * *
* INTERNET OPEN TRADING PROTOCOL DTD VERSION 05 * * INTERNET OPEN TRADING PROTOCOL DTD VERSION 06 *
* Filename: iotp-v1.0-protocol-05.dtd * * Filename: iotp-v1.0-protocol-06.dtd *
* * * *
* Changes from version 04 (iotp-v1.0-protocol-04.dtd)* * Changes from version 05 (iotp-v1.0-protocol-05.dtd)*
* 1.Changed NMTOKEN to NMTOKENS in TradingRoleList * * 1. Changed NMTOKEN to CDATA in for IotpTransId in *
* attribute of Trading Role Information Request * * TransId component. *
* Component * * 2. Changed NMTOKEN to NMTOKENS in TradingRoleList *
* 2.Changed REQIURED to IMPLIED on the PaymentRef * * attribute of TradingRoleInfoReq element as more *
* attribute of the PaySchemeData Component * * than one token is allowed *
* 3.Added new ConsumerDeliveryData component contain-* * 3. Changed StartAfter to StartAfterRefs in Payment *
* ing a ConsumerDeliveryId attribute. Removed * * Component since they are references to other *
* ConsumerDeliveryId attribute from Delivery * * elements. *
* Component. Added ConsumerDeliveryData Component * * 4. Changed REQUIRED to IMPLIED on DelivReqNetLocn *
* to Delivery Request Block. * * and SecDelivReqNetLocn on Delivery Data Element *
* 4.Replaces Signature definitions with DTD taken * * as only one of them is mandatory *
* from draft-ietf-trade-iotp-v1.0-dsig-01.txt, with* * 5. Changed name of "xmlns.iotp" attribute in the *
* following changes: * * IotpMessage element to just "xmlns" *
* - changed IOTPSignatures to IotpSignatures * * 6. Changed default currency code type from"ISO4217"*
* - removed "#IMPLIED" from defintion of encoding * * to "ISO4217-A" as must be alphabetical. *
* attribute in Value element * * 7. Replaced Digital signature DTD with DTD from *
* draft-ietf-trade-iotp-v1.0-dsig-03.txt *
* * * *
* Copyright Internet Engineering Task Force 1998,99 * * Copyright Internet Engineering Task Force 1998,99 *
* * * *
****************************************************** ******************************************************
****************************************************** ******************************************************
* IOTP MESSAGE DEFINITION * * IOTP MESSAGE DEFINITION *
****************************************************** ******************************************************
--> -->
skipping to change at page 229, line 13 skipping to change at page 229, line 14
PayExchBlk | PayExchBlk |
PayReqBlk | PayReqBlk |
PayRespBlk | PayRespBlk |
PingReqBlk | PingReqBlk |
PingRespBlk | PingRespBlk |
TpoBlk | TpoBlk |
TpoSelectionBlk TpoSelectionBlk
)* )*
) > ) >
<!ATTLIST IotpMessage <!ATTLIST IotpMessage
xmlns:iotp CDATA xmlns CDATA
'ietf.org/draft-ietf-trade-iotp-v1.0-protocol-05' > 'ietf.org/draft-ietf-trade-iotp-v1.0-protocol-06' >
<!-- <!--
****************************************************** ******************************************************
* TRANSACTION REFERENCE BLOCK DEFINITION * * TRANSACTION REFERENCE BLOCK DEFINITION *
****************************************************** ******************************************************
--> -->
<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) > <!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) >
<!ATTLIST TransRefBlk <!ATTLIST TransRefBlk
ID ID #REQUIRED > ID ID #REQUIRED >
<!ELEMENT TransId EMPTY > <!ELEMENT TransId EMPTY >
<!ATTLIST TransId <!ATTLIST TransId
ID ID #REQUIRED ID ID #REQUIRED
Version NMTOKEN #FIXED '1.0' Version NMTOKEN #FIXED '1.0'
IotpTransId NMTOKEN #REQUIRED IotpTransId CDATA #REQUIRED
IotpTransType CDATA #REQUIRED IotpTransType CDATA #REQUIRED
TransTimeStamp CDATA #REQUIRED > TransTimeStamp CDATA #REQUIRED >
<!ELEMENT MsgId EMPTY > <!ELEMENT MsgId EMPTY >
<!ATTLIST MsgId <!ATTLIST MsgId
ID ID #REQUIRED ID ID #REQUIRED
RespIotpMsg NMTOKEN #IMPLIED RespIotpMsg NMTOKEN #IMPLIED
xml:lang NMTOKEN #REQUIRED xml:lang NMTOKEN #REQUIRED
LangPrefList NMTOKENS #IMPLIED LangPrefList NMTOKENS #IMPLIED
CharSetPrefList NMTOKENS #IMPLIED CharSetPrefList NMTOKENS #IMPLIED
skipping to change at page 230, line 50 skipping to change at page 231, line 4
<!ATTLIST AuthResp <!ATTLIST AuthResp
ID ID #REQUIRED ID ID #REQUIRED
AuthenticationId CDATA #REQUIRED AuthenticationId CDATA #REQUIRED
SelectedAlgorithmRef NMTOKEN #REQUIRED SelectedAlgorithmRef NMTOKEN #REQUIRED
ContentSoftwareId CDATA #IMPLIED > ContentSoftwareId CDATA #IMPLIED >
<!-- TRADING ROLE INFO REQUEST COMPONENT --> <!-- TRADING ROLE INFO REQUEST COMPONENT -->
<!ELEMENT TradingRoleInfoReq EMPTY> <!ELEMENT TradingRoleInfoReq EMPTY>
<!ATTLIST TradingRoleInfoReq <!ATTLIST TradingRoleInfoReq
ID ID #REQUIRED ID ID #REQUIRED
TradingRoleList NMTOKEN #REQUIRED > TradingRoleList NMTOKENS #REQUIRED >
<!-- ORDER COMPONENT --> <!-- ORDER COMPONENT -->
<!ELEMENT Order (PackagedContent*) > <!ELEMENT Order (PackagedContent*) >
<!ATTLIST Order <!ATTLIST Order
ID ID #REQUIRED ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED xml:lang NMTOKEN #REQUIRED
OrderIdentifier CDATA #REQUIRED OrderIdentifier CDATA #REQUIRED
ShortDesc CDATA #REQUIRED ShortDesc CDATA #REQUIRED
OkFrom CDATA #REQUIRED OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED OkTo CDATA #REQUIRED
ApplicableLaw CDATA #REQUIRED ApplicableLaw CDATA #REQUIRED
skipping to change at page 232, line 51 skipping to change at page 232, line 51
<!ATTLIST ProtocolAmount <!ATTLIST ProtocolAmount
ID ID #REQUIRED ID ID #REQUIRED
PayProtocolRef IDREF #REQUIRED PayProtocolRef IDREF #REQUIRED
CurrencyAmountRefs IDREFS #REQUIRED CurrencyAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED > ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT CurrencyAmount EMPTY > <!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount <!ATTLIST CurrencyAmount
ID ID #REQUIRED ID ID #REQUIRED
Amount CDATA #REQUIRED Amount CDATA #REQUIRED
CurrCodeType NMTOKEN 'ISO4217' CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED > CurrCode CDATA #REQUIRED >
<!ELEMENT PayProtocol (PackagedContent*) > <!ELEMENT PayProtocol (PackagedContent*) >
<!ATTLIST PayProtocol <!ATTLIST PayProtocol
ID ID #REQUIRED ID ID #REQUIRED
xml:lang NMTOKEN #IMPLIED xml:lang NMTOKEN #IMPLIED
ProtocolId NMTOKEN #REQUIRED ProtocolId NMTOKEN #REQUIRED
ProtocolName CDATA #REQUIRED ProtocolName CDATA #REQUIRED
ActionOrgRef NMTOKEN #REQUIRED ActionOrgRef NMTOKEN #REQUIRED
PayReqNetLocn CDATA #IMPLIED PayReqNetLocn CDATA #IMPLIED
skipping to change at page 233, line 46 skipping to change at page 233, line 47
ContentSoftwareId CDATA #IMPLIED > ContentSoftwareId CDATA #IMPLIED >
<!-- PAYMENT COMPONENT --> <!-- PAYMENT COMPONENT -->
<!ELEMENT Payment EMPTY > <!ELEMENT Payment EMPTY >
<!ATTLIST Payment <!ATTLIST Payment
ID ID #REQUIRED ID ID #REQUIRED
OkFrom CDATA #REQUIRED OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED OkTo CDATA #REQUIRED
BrandListRef NMTOKEN #REQUIRED BrandListRef NMTOKEN #REQUIRED
SignedPayReceipt (True | False) #REQUIRED SignedPayReceipt (True | False) #REQUIRED
StartAfter NMTOKENS #IMPLIED > StartAfterRefs NMTOKENS #IMPLIED >
<!-- PAYMENT SCHEME COMPONENT --> <!-- PAYMENT SCHEME COMPONENT -->
<!ELEMENT PaySchemeData (PackagedContent+) > <!ELEMENT PaySchemeData (PackagedContent+) >
<!ATTLIST PaySchemeData <!ATTLIST PaySchemeData
ID ID #REQUIRED ID ID #REQUIRED
PaymentRef NMTOKEN #IMPLIED PaymentRef NMTOKEN #IMPLIED
ConsumerPaymentId CDATA #IMPLIED ConsumerPaymentId CDATA #IMPLIED
PaymentHandlerPayId CDATA #IMPLIED PaymentHandlerPayId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED > ContentSoftwareId CDATA #IMPLIED >
skipping to change at page 234, line 36 skipping to change at page 234, line 37
DelivAndPayResp (True | False) #REQUIRED DelivAndPayResp (True | False) #REQUIRED
ActionOrgRef NMTOKEN #IMPLIED > ActionOrgRef NMTOKEN #IMPLIED >
<!ELEMENT DeliveryData (PackagedContent*) > <!ELEMENT DeliveryData (PackagedContent*) >
<!ATTLIST DeliveryData <!ATTLIST DeliveryData
xml:lang NMTOKEN #IMPLIED xml:lang NMTOKEN #IMPLIED
OkFrom CDATA #REQUIRED OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED OkTo CDATA #REQUIRED
DelivMethod NMTOKEN #REQUIRED DelivMethod NMTOKEN #REQUIRED
DelivToRef NMTOKEN #REQUIRED DelivToRef NMTOKEN #REQUIRED
DelivReqNetLocn CDATA #REQUIRED DelivReqNetLocn CDATA #IMPLIED
SecDelivReqNetLocn CDATA #REQUIRED SecDelivReqNetLocn CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED > ContentSoftwareId CDATA #IMPLIED >
<!-- CONSUMER DELIVERY DATA COMPONENT --> <!-- CONSUMER DELIVERY DATA COMPONENT -->
<!ELEMENT ConsumerDeliveryData EMPTY > <!ELEMENT ConsumerDeliveryData EMPTY >
<!ATTLIST ConsumerDeliveryData <!ATTLIST ConsumerDeliveryData
ID ID #REQUIRED ID ID #REQUIRED
ConsumerDeliveryId CDATA #REQUIRED > ConsumerDeliveryId CDATA #REQUIRED >
<!-- DELIVERY NOTE COMPONENT --> <!-- DELIVERY NOTE COMPONENT -->
<!ELEMENT DeliveryNote (PackagedContent+) > <!ELEMENT DeliveryNote (PackagedContent+) >
skipping to change at page 238, line 18 skipping to change at page 238, line 19
<!ELEMENT CancelBlk (Status) > <!ELEMENT CancelBlk (Status) >
<!ATTLIST CancelBlk <!ATTLIST CancelBlk
ID ID #REQUIRED > ID ID #REQUIRED >
<!-- <!--
****************************************************** ******************************************************
* IOTP SIGNATURES BLOCK DEFINITION * * IOTP SIGNATURES BLOCK DEFINITION *
****************************************************** ******************************************************
--> -->
<!ELEMENT IOTPSignatures (Signature+ ,Certificate*) > <!ELEMENT IotpSignatures (Signature+ ,Certificate*) >
<!ATTLIST IOTPSignatures <!ATTLIST IotpSignatures
ID ID #IMPLIED ID ID #IMPLIED
> >
<!-- <!--
****************************************************** ******************************************************
* IOTP SIGNATURE COMPONENT DEFINITION * * IOTP SIGNATURE COMPONENT DEFINITION *
****************************************************** ******************************************************
--> -->
<!ELEMENT Signature (Manifest, Value+) > <!ELEMENT Signature (Manifest, Value+) >
skipping to change at page 238, line 49 skipping to change at page 238, line 50
RecipientInfo+ RecipientInfo+
) )
> >
<!ATTLIST Manifest <!ATTLIST Manifest
LocatorHRefBase CDATA #IMPLIED LocatorHRefBase CDATA #IMPLIED
> >
<!ELEMENT Algorithm (Parameter*) > <!ELEMENT Algorithm (Parameter*) >
<!ATTLIST Algorithm <!ATTLIST Algorithm
id ID #REQUIRED ID ID #REQUIRED
type (digest|signature) #IMPLIED type (digest|signature) #IMPLIED
name NMTOKEN #REQUIRED name NMTOKEN #REQUIRED
> >
<!ELEMENT Digest (Locator, Value) > <!ELEMENT Digest (Locator, Value) >
<!ATTLIST Digest <!ATTLIST Digest
DigestAlgorithmRef IDREF #REQUIRED DigestAlgorithmRef IDREF #REQUIRED
> >
<!ELEMENT Attribute ( ANY ) > <!ELEMENT Attribute ( ANY ) >
<!ATTLIST Attribute <!ATTLIST Attribute
skipping to change at page 239, line 28 skipping to change at page 239, line 28
> >
<!ELEMENT RecipientInfo ANY > <!ELEMENT RecipientInfo ANY >
<!ATTLIST RecipientInfo <!ATTLIST RecipientInfo
SignatureAlgorithmRef IDREF #REQUIRED SignatureAlgorithmRef IDREF #REQUIRED
SignatureValueRef IDREF #IMPLIED SignatureValueRef IDREF #IMPLIED
SignatureCertRef IDREF #IMPLIED SignatureCertRef IDREF #IMPLIED
RecipientRefs NMTOKENS #IMPLIED RecipientRefs NMTOKENS #IMPLIED
> >
<!ELEMENT KeyIdentifier EMPTY>
<!ATTLIST KeyIdentifier
value CDATA #REQUIRED
>
<!ELEMENT Parameter ANY > <!ELEMENT Parameter ANY >
<!ATTLIST Parameter <!ATTLIST Parameter
type CDATA #REQUIRED type CDATA #REQUIRED
> >
<!-- <!--
****************************************************** ******************************************************
* IOTP CERTIFICATE COMPONENT DEFINITION * * IOTP CERTIFICATE COMPONENT DEFINITION *
****************************************************** ******************************************************
--> -->
skipping to change at page 240, line 8 skipping to change at page 240, line 13
number CDATA #REQUIRED number CDATA #REQUIRED
> >
<!-- <!--
****************************************************** ******************************************************
* IOTP SHARED COMPONENT DEFINITION * * IOTP SHARED COMPONENT DEFINITION *
****************************************************** ******************************************************
--> -->
<!ELEMENT Value ( #PCDATA ) > <!ELEMENT Value ( #PCDATA ) >
<!ATTLIST Value <!ATTLIST Value
id ID #IMPLIED ID ID #IMPLIED
encoding (base64|none) 'base64' encoding (base64|none) #IMPLIED 'base64'
> >
<!ELEMENT Locator EMPTY> <!ELEMENT Locator EMPTY>
<!ATTLIST Locator <!ATTLIST Locator
xml:link CDATA #FIXED 'simple' xml:link CDATA #FIXED 'simple'
href CDATA #REQUIRED href CDATA #REQUIRED
> >
14. Glossary 14. Glossary
skipping to change at page 244, line 17 skipping to change at page 244, line 17
Merchant The Organisation from whom the service or goods Merchant The Organisation from whom the service or goods
are being obtained, who is legally responsible for are being obtained, who is legally responsible for
providing the goods or services and receives the providing the goods or services and receives the
benefit of any payment made benefit of any payment made
Merchant Customer The Organisation that is involved with customer Merchant Customer The Organisation that is involved with customer
Care Provider dispute negotiation and resolution on behalf of Care Provider dispute negotiation and resolution on behalf of
the Merchant the Merchant
Organisation A company or individual that takes part in a Trade Organisation A company or individual that takes part in a Trade
as a Trading Role. The organisations may take one as a Trading Role. The Organisations may take one
or more of the roles involved in the Trade or more of the roles involved in the Trade
Payment Handler The Organisation that physically receives the Payment Handler The Organisation that physically receives the
payment from the Consumer on behalf of the payment from the Consumer on behalf of the
Merchant Merchant
Payment A Payment Instrument is the means by which Payment A Payment Instrument is the means by which
Instrument Consumer pays for goods or services offered by a Instrument Consumer pays for goods or services offered by a
Merchant. It can be, for example: Merchant. It can be, for example:
o a credit card such as MasterCard or Visa; o a credit card such as MasterCard or Visa;
skipping to change at page 247, line 20 skipping to change at page 247, line 20
o Payment, where a Consumer makes a payment to a o Payment, where a Consumer makes a payment to a
Payment Handler, Payment Handler,
o Delivery, where a Consumer requests, and o Delivery, where a Consumer requests, and
optionally obtains, delivery of goods or optionally obtains, delivery of goods or
services from a Delivery Handler, and services from a Delivery Handler, and
o Authentication, where any Trading Role may o Authentication, where any Trading Role may
request and receive information about another request and receive information about another
Trading Role. Trading Role.
Trading Role A Trading Role identifies the different ways in Trading Role A Trading Role identifies the different ways in
which organisations can participate in a trade. which Organisations can participate in a trade.
There are five Trading Roles: Consumer, Merchant, There are five Trading Roles: Consumer, Merchant,
Payment Handler, Delivery Handler, and Merchant Payment Handler, Delivery Handler, and Merchant
Customer Care Provider. Customer Care Provider.
Transaction A Transaction Reference Block identifies an IOTP Transaction A Transaction Reference Block identifies an IOTP
Reference Block Transaction. It contains data that identifies: Reference Block Transaction. It contains data that identifies:
o the Transaction Type, o the Transaction Type,
o the IOTP Transaction uniquely, through a o the IOTP Transaction uniquely, through a
globally unique transaction identifier globally unique transaction identifier
o the IOTP Message uniquely within the IOTP o the IOTP Message uniquely within the IOTP
skipping to change at page 249, line 18 skipping to change at page 249, line 18
specification. specification.
[Base64] Base64 Content-Transfer-Encoding. A method of [Base64] Base64 Content-Transfer-Encoding. A method of
transporting binary data defined by MIME. See: RFC 2045: transporting binary data defined by MIME. See: RFC 2045:
Multipurpose Internet Mail Extensions (MIME) Part One: Multipurpose Internet Mail Extensions (MIME) Part One:
Format of Internet Message Bodies. N. Freed & N. Format of Internet Message Bodies. N. Freed & N.
Borenstein. November 1996. Borenstein. November 1996.
[DOM-HASH] A method for generating hashes of all or part of an XML [DOM-HASH] A method for generating hashes of all or part of an XML
tree based on the DOM of that tree. See tree based on the DOM of that tree. See
<ftp://ftp.pothole.com/pub/dee3/drarft-hiroshi-com-hash- http://www.ietf.org/internet-drafts/draft-ietf-trade-
00.txt>. hiroshi-dom-hash-*.txt
[DNS] See RFC 1034: Domain names - concepts and facilities. [DNS] See RFC 1034: Domain names - concepts and facilities.
P.V. Mockapetris. Nov-01-1987, and RFC 1035: Domain names P.V. Mockapetris. Nov-01-1987, and RFC 1035: Domain names
- implementation and specification. P.V. Mockapetris. - implementation and specification. P.V. Mockapetris.
Nov-01-1987. Nov-01-1987.
[DSA] The Digital Signature Algorithm (DSA) published by the [DSA] The Digital Signature Algorithm (DSA) published by the
National Institute of Standards and Technology (NIST) in National Institute of Standards and Technology (NIST) in
the Digital Signature Standard (DSS), which is a part of the Digital Signature Standard (DSS), which is a part of
the US government's Capstone project. the US government's Capstone project.
skipping to change at page 253, line 20 skipping to change at page 253, line 20
- Mercantec - Mercantec
- Netscape - Netscape
- Nippon Telegraph and Telephone Corporation - Nippon Telegraph and Telephone Corporation
- Oracle Corporation - Oracle Corporation
- Smart Card Integrations Ltd. - Smart Card Integrations Ltd.
- Spyrus - Spyrus
- Verifone - Verifone
- Unisource nv - Unisource nv
- Wells Fargo Bank - Wells Fargo Bank
File name: draft-ietf-trade-iotp-v1.0-protocol-05.txt File name: draft-ietf-trade-iotp-v1.0-protocol-06.txt
Expires: February 2000 Expires: March 2000
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/