RFC 2801
Internet Open Trading Protocol - IOTP Version 1.0
Pages: 290
Informational
Informational
Part 8 of 9 – Pages 241 to 277
9.2.2 Baseline Ping IOTP Transaction
The purpose of the Baseline IOTP Ping Transaction is to test basic connectivity between the Trading Roles that may take part in an IOTP Transaction. It enables IOTP aware application software to: o determine if the IOTP aware application at another Trading Role is operating, and o verify whether or not the two trading roles signatures can be processed. For example it can be used by a Merchant to determine if a Payment Handler or Delivery Handler is up and running prior to starting a Purchase transaction that uses those trading roles. The Trading Blocks used by the Baseline Ping IOTP Transaction are: o a Ping Request Block (see section 8.14) o a Ping Response Block (see section 8.15), and o a Signature Block (see section 8.16). PING MESSAGES The following figure outlines the message flows in the Baseline IOTP Ping Transaction.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
1st Role
| 2nd Role
STEP | |
1. The IOTP Aware Application in the first Trading Role
decides to check whether the counterparty IOTP
application is up and running. It generates a Ping
Request Block and optional Signature Block and sends them
to the second trading role.
1 --> 2 PING REQUEST. IotpMsg: Trans Ref Block; Signature Block
(Optional); Ping Request Block
2. The second Trading Role which receives the Ping Request
Block generates a Ping Response Block and sends it back
to the sender of the original Ping Request with a
signature block if required.
1 <-- 2 PING Response. IotpMsg: Trans Ref Block; Signature Block
(Optional); Ping Response Block
3. The first Trading Role checks the Ping Response Block and
takes appropriate action, if necessary
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 33 Baseline Ping Messages
The verification that signatures can be handled is indicated by the
sender of the Ping Request Block including:
o Organisation Components that identify itself and the intended
recipient of the Ping Request Block, and
o a Signature Block that signs data in the Ping Request.
In this way the receiver of the Ping Request:
o knows who is sending the Ping Request and can therefore verify the
Signature on the Request, and
o knows who to generate a signature for on the Ping Response.
Note that a Ping Request:
o does not affect any on-going transaction
o does NOT initiate an IOTP transaction, unlike other IOTP
transaction messages such as TPO or Transaction Status Inquiry.
All IOTP aware applications must return a Ping Response message to
the sender of a Ping Request message when it is received.
A Baseline IOTP Ping request can also contain an optional Signature
Block. IOTP aware applications can, for example, use the Signature
Block to check the recipient of a Ping Request can successfully
process and check signatures it has received.
For each Baseline Ping IOTP Transaction, each IOTP role shall
establish a different transport session from other IOTP transactions.
Any IOTP Trading Role can send a Ping request to any other IOTP
Trading Role at any time it wants. A Ping message has its own
IotpTransId, which is different from other IOTP transactions.
The remainder of this sub-section on the Baseline Ping IOTP
Transaction defines the contents of each Trading Block.
TRANSACTION REFERENCE BLOCK
The IotpTransId of a Ping transaction should be different from any
other IOTP transaction.
PING REQUEST BLOCK
If the Ping Transaction is anonymous then no Organisation Components
are included in the Ping Request Block (see section 8.7).
If the Ping Transaction is not anonymous then the Ping Request Block
contains Organisation Components for:
o the sender of the Ping Request Block, and
o the verifier of the Signature Component
If Organisation Components are present, then it indicates that the
sender of the Ping Request message has generated a Signature Block.
The signature block must be verified by the Trading Role that
receives the Ping Request Block.
SIGNATURE BLOCK (PING REQUEST)
The Ping Request Signature Block (see section 8.16) contains the
following components:
o one Signature Component (see section 7.19) o one or more Certificate Components, if required. PING RESPONSE BLOCK The Ping Response Block (see section 8.15) contains the following component: o the Organisation Component of the sender of the Ping Response message If the Ping Transaction is not anonymous then the Ping Response additionally contains: o copies of the Organisation Components contained in the Ping Request Block. SIGNATURE BLOCK (PING RESPONSE) The Ping Response Signature Block (see section 8.16) contains the following components: o one Signature Component (see section 7.19) o one or more Certificate Components, if required.10. Retrieving Logos
This section describes how to retrieve logos for display by IOTP aware software using the Logo Net Locations attribute contained in the Brand Element (see section 7.7.1) and the Organisation Component (see section 7.6). The full address of a logo is defined as follows: Logo_address ::= Logo_net_location "/" Logo_size Logo_color_depth ".gif" Where: o Logo_net_location is obtained from the LogoNetLocn attribute in the Brand Element (see section 7.7.1) or the Organisation Component. Note that: - the content of this attribute is dependent on the Transport Mechanism (such as HTTP) that is used. See the Transport Mechanism supplement,
- implementers should check that if the rightmost character of
Logo Net Location is set to right-slash "/" then another, right
slash should not be included when generating the Logo Address,
o Logo_size identifies the size of the logo,
o Logo_color_depth identifies the colour depth of the logo
o "gif" indicates that the logos are in "gif" format
Logo_size and Logo_color_depth are specified by the implementer of
the IOTP software that is retrieving the logo depending on the size
and colour that they want to use.
10.1 Logo Size
There are five standard sizes for logos. The sizes in pixels and the
corresponding values for Logo Size are given in the table below.
Size in Logo Size
Pixels Value
32 x 32 or exsmall
32 x 20
53 x 33 small
103 x 65 medium
180 x 114 large
263 x 166 exlarge
10.2 Logo Color Depth
There are three standard colour depths. The colour depth (including
bits per pixel) and the corresponding value for Logo_Color_Depth are
given in the table below.
Color Depth Logo Color
(bits per pixel) Depth Value
4 (16 colors) 4
8 (256 colors) nothing
24 (16 million colors) 24
Note that if Logo Color Depth is omitted then a logo with the default colour depth of 256 colours will be retrieved.10.3 Logo Net Location Examples
If Logo Net Location was set to "ftp://logos.xzpay.com", then: o "ftp://logos.xzpay.com/medium.gif" would retrieve a medium size 256 colour logo o "http://logos.xzpay.com/small4.gif" would retrieve a small size 16 colour logo Note: Organisations which make logos available for use with IOTP should always make available "small" and "medium" size logos and use the "gif" format.11. Brands
This section contains: o a definition of Brands and an outline of Brand Selection using Brand Lists, and o some XML examples of Brand Lists11.1 Brand Definitions and Brand Selection
One of the key features of IOTP is the ability for a merchant to offer a list of Brands from which a consumer may make a selection. This section provides an overview of what is involved and provides guidance on how selection of a brand and associated payment instrument can be carried out by a Consumer. It covers: o definitions of Payment Instruments and Brands - what are Payment Instruments and Brands in an IOTP context. Further categorises Brands as optionally a "Dual Brand" or a "Promotional Brand", o identification and selection of Promotional Brands - Promotional Brands offer a Consumer some additional benefit, for example loyalty points or a discount. This means that both Consumers and Merchant must be able to correctly identify that a valid Promotional Brand is being used. Also see the following sections:
o Brand List Component (section 7.7) which contains definitions of the XML elements which contain the list of Brands offered by a Merchant to a Consumer, and o Brand Selection Component (section 7.8) for details of how a Consumer records the Brand, currency, amount and payment protocol that was selected.11.1.1 Definition of Payment Instrument
A Payment Instrument is the means by which a Consumer pays for goods or services offered by a Merchant. It can be, for example: o a credit card such as MasterCard or Visa; o a debit card such as MasterCard's Maestro; o a smart card based electronic cash payment instrument such as a Mondex Card, a GeldKarte card or a Visa Cash card o a software based electronic payment account such as a CyberCash or DigiCash account. Most Payment Instruments have a number, typically an account number, by which the Payment Instrument can be identified.11.1.2 Definition of Brand
A Brand is the mark which identifies a particular type of Payment 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 selection. Each Brand may have a different Payment Handler. Examples of Brands include: o payment association and proprietary Brands, for example MasterCard, Visa, American Express, Diners Club, Mondex, GeldKarte, CyberCash, etc. o promotional brands (see below). These include: - store brands, where the Payment Instrument is issued to a Consumer by a particular Merchant, for example Walmart, Sears, or Marks and Spencer (UK) - cobrands, for example American Advantage Visa, where an Organisation uses their own brand in conjunction with, typically, a payment association Brand.
11.1.3 Definition of Dual Brand
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 "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 their own separate Payment Handlers. This means that: o the merchant treats, for example "UC" and "MasterCard" as two separate Brands when offering a list of Brands to the Consumer, o the consumer chooses a Brand, for example either "UC" or "MasterCard, o the consumer IOTP aware application determines which Payment Instrument(s) match the chosen Brand, and selects, perhaps with user assistance, the correct Payment Instrument to use. Note: Dual Brands need no special treatment by the Merchant and therefore no explicit reference is made to Dual Brands in the DTD. This is because, as far as the Merchant is concerned, each Brand in a Dual Brand is treated as a separate Brand. It is at the Consumer, that the matching of a Brand to a Dual Brand Payment Instrument needs to be done.11.1.4 Definition of Promotional Brand
A Promotional Brand means that, if the Consumer pays with that Brand, then the Consumer will receive some additional benefit which can be received in two ways: o at the time of purchase. For example if a Consumer pays with a "Walmart MasterCard" at a Walmart web site, then a 5% discount might apply, which means the consumer actually pays less, o from their Payment Instrument (card) issuer when the payment appears on their statement. For example loyalty points in a frequent flyer scheme could be awarded based on the total payments made with the Payment Instrument since the last statement was issued. Note that: o the first example (obtaining the benefit at the time of purchase), requires that: - the Consumer is informed of the benefits which arise if that Brand is selected
- if the Brand is selected, the Merchant changes the relevant
IOTP Components in the Offer Response to reflect the correct
amount to be paid
o the second (obtaining a benefit through the Payment Instrument
issuer) does not require that the Offer Response is changed
o each Promotional Brand should be identified as a separate Brand in
the list of Brands offered by the Merchant. For example:
"Walmart", "Sears", "Marks and Spencer" and "American Advantage
Visa", would each be a separate Brand.
11.1.5 Identifying Promotional Brands
There are two problems which need to handled in identifying
Promotional Brands:
o how does the Merchant or their Payment Handler positively identify
the promotional brand being used at the time of purchase
o how does the Consumer reliably identify the correct promotional
brand from the Brand List presented by the Merchant
The following is a description of how this could be achieved.
Note: Please note that the approach described here is a model
approach that solves the problem. Other equivalent methods may be
used.
11.1.5.1 Merchant/Payment Handler Identification of Promotional Brands
Correct identification that the Consumer is paying using a
Promotional Brand is important since a Consumer might fraudulently
claim to have a Promotional Brand that offers a reduced payment
amount when in reality they do not.
Two approaches seem possible:
o use some feature of the Payment Instrument or the payment method
to positively identify the Brand being used. For example, the SET
certificate for the Brand could be used, if one is available, or
o use the Payment Instrument (card) number to look up information
about the Payment Instrument on a Payment Instrument issuer
database to determine if the Payment Instrument is a promotional
brand.
Note that:
o the first assumes that SET is available.
o the second is only possible if the Merchant, or alternatively the
Payment Handler, has access to card issuer information.
IOTP does not provide the Merchant with Payment Instrument
information (e.g., a card or account number). This is only sent as
part of the encapsulated payment protocol to a Payment Handler. This
means that:
o the Merchant would have to assume that the Payment Instrument
selected was a valid Promotional Brand, or
o the Payment Handler would have to check that the Payment
Instrument was for the valid Promotional Brand and fail the
payment if it was not.
A Payment Handler checking that a brand is a valid Promotional Brand
is most likely if the Payment Handler is also the Card Issuer.
11.1.5.2 Consumer Selection of Promotional Brands
Two ways by which a Consumer can correctly select a Promotional Brand
are:
o the Consumer visually matching a logo for the Promotional Brand
which has been provided to the Consumer by the Merchant,
o the Consumer's IOTP aware application matching a code for the
Promotional Brand which the application has registered against a
similar code contained in the list of Brands offered by the
Merchant.
In the latter case, the code contained in the Consumer wallet must
match exactly the code in the list offered by the Merchant otherwise
no match will be found. Ways in which the Consumer's IOTP Aware
Application could obtain such a code include:
o the Consumer types the code in directly. This is error prone and
not user friendly, also the consumer needs to be provided with the
code. This approach is not recommended,
o using one of the Brand Identifiers defined by IOTP and pre-loaded
into the Consumers IOTP Aware application or wallet by the
developer of the Wallet,
o using some information contained in the software or other data
associated with the Payment Instrument. This could be:
- a SET certificate for Brands which use this payment method
- a code provided by the payment software which handles the
particular payment method, this could apply to, for example,
GeldKarte, Mondex, CyberCash and DigiCash,
o the consumer making an initial "manual" link between a Promotional
Brand in the list of Brands offered by the Merchant and an
individual Payment Instrument, the first time the promotional
brand is used. The IOTP Aware application would then "remember"
the code for the Promotional Brand for use in future purchases.
11.1.5.3 Consumer Software Brand Id recommendation
New Brand Ids are allocated under IANA procedures (see section 12
IANA Considerations). Which also contains an initial list of Brand
Identifiers.
It is recommended that implementers of consumer IOTP aware
applications (e.g., software wallets) pre-load their software with
the then current set of Brand Ids and provide a method by which they
can be updated. For example, by going to the software developer's web
site.
11.2 Brand List Examples
This example contains three examples of the XML for a Brand List
Component. It covers:
o a simple credit card based example
o a credit card based brand list including promotional credit card
brands, and
o a complex electronic cash based brand list
Note that:
o brand lists can be as complex or as simple as required
o all example techniques described in this appendix can be included
in one brand list.
11.2.1 Simple Credit Card Based Example
This is a simple example involving: o only major credit card payment brands o a single price in a single currency o a single Payment Handler, and o a single payment protocol <BrandList ID='M1.2' XML:Lang='us-en' ShortDesc='Purchase book including s&h' PayDirection='Debit' > <Brand ID ='M1.30' BrandId='MasterCard' BrandName='MasterCard Credit' BrandLogoNetLocn='ftp://otplogos.mastercard.com/mastercardcredit' ProtocolAmountRefs='M1.33'> </Brand> <Brand ID ='M.31' BrandId='Visa' BrandName='Visa Credit' BrandLogoNetLocn='ftp://otplogos.visa.com/visacredit' ProtocolAmountRefs='M1.33'> </Brand> <Brand ID ='M1.32' BrandId='AmericanExpress' BrandName='American Express' BrandLogoNetLocn='ftp://otplogos.amex.com' ProtocolAmountRefs ='M1.33' > </Brand > <ProtocolAmount ID ='M1.33' PayProtocolRef='M1.35' CurrencyAmountRefs='M1.34'> </ProtocolAmount> <CurrencyAmount ID ='M1.34' Amount='10.95' CurrCode='USD'/> <PayProtocol ID ='M1.35' ProtocolId='SCCD1.0' ProtocolName='Secure Channel Credit/Debit' PayReqNetLocn='http://www.example.com/etill/sccd1' > </PayProtocol> </BrandList>
11.2.2 Credit Card Brand List Including Promotional Brands
An example of a Credit Card based Brand List follows. It includes: o two ordinary card association brands and two promotional credit card brands. The promotional brands consist of one loyalty based (British Airways MasterCard) which offers additional loyalty points and one store based (Walmart) which offers a discount on purchases over a certain amount o two payment protocols: - SET (Secure Electronic Transactions) see [SET], and - SCCD (Secure Channel Credit Debit) see [SCCD]. <BrandList ID='M1.2' XML:Lang='us-en' ShortDesc='Purchase ladies coat' PayDirection='Debit' > <Brand ID ='M1.3' BrandId='MasterCard' BrandName='MasterCard Credit' BrandLogoNetLocn='ftp://otplogos.mastercard.com' ProtocolAmountRefs='M1.7 M1.8'> <ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:'> </ProtocolBrand> </Brand> <Brand ID ='M1.4' BrandId='Visa' BrandName='Visa Credit' BrandLogoNetLocn='ftp://otplogos.visa.com' ProtocolAmountRefs='M1.7 M1.8'> <ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='Visa:'> </ProtocolBrand> </Brand> <Brand ID ='M1.5' BrandId='BritishAirwaysMC' BrandName='British Airways MasterCard' BrandLogoNetLocn='ftp://otplogos.britishairways.co.uk' BrandNarrative='Double air miles with British Airways MasterCard' ProtocolAmountRefs ='M1.7 M1.8' > <ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:BA'> </ProtocolBrand> </Brand > <Brand ID ='M1.6' BrandId='Walmart' BrandName='Walmart Store Card'
BrandLogoNetLocn='ftp://otplogos.walmart.com'
BrandNarrative='5% off with your Walmart Card
on purchases over $150'
ProtocolAmountRefs='M1.8'>
</Brand>
<ProtocolAmount ID ='M1.7'
PayProtocolRef='M1.10'
CurrencyAmountRefs='M1.9' >
<PackagedContent Transform="BASE64">
238djqw1298erh18dhoire
</PackagedContent>
</ProtocolAmount>
<ProtocolAmount ID ='M1.8'
PayProtocolRef='M1.11'
CurrencyAmountRefs='M1.9' >
<PackagedContent Transform="BASE64">
238djqw1298erh18dhoire
</PackagedContent>
</ProtocolAmount>
<CurrencyAmount ID ='M1.9'
Amount='157.53'
CurrCode='USD'/>
<PayProtocol ID ='M1.10'
ProtocolId='SET1.0'
ProtocolName='Secure Electronic Transaction Version 1.0'
PayReqNetLocn='http://www.example.com/etill/set1' >
<PackagedContent Transform="BASE64">
8ueu26e482hd82he82
</PackagedContent>
</PayProtocol>
<PayProtocol ID ='M1.11'
ProtocolId='SCCD1.0'
ProtocolName='Secure Channel Credit/Debit'
PayReqNetLocn='http://www.example.com/etill/sccd1' >
<PackagedContent Transform="BASE64">
82hd82he8226e48ueu
</PackagedContent>
</PayProtocol>
</BrandList>
11.2.3 Brand Selection Example
In order to pay by 'British Airways' MasterCard using the example
above using SET and therefore getting double air miles, the Brand
Selection would be:
<BrandSelection ID='C1.2'
BrandListRef='M1.3'
BrandRef='M1.5'
ProtocolAmountRef='M1.7'
CurrencyAmountRef='M1.9' >
</BrandSelection>
11.2.4 Complex Electronic Cash Based Brand List
The following is an fairly complex example which includes:
o payments using either Mondex, GeldKarte, CyberCash or DigiCash
o in currencies including US dollars, British Pounds, Italian Lira,
German Marks and Canadian Dollars
o a discount on the price if the payment is made in Mondex using
British pounds or US dollars, and
o more than one Payment Handler is used for payments involving
Mondex or CyberCash
o support for more than one version of a CyberCash CyberCoin payment
protocol.
<BrandList ID='M1.2'
XML:Lang='us-en'
ShortDesc='Company report on XYZ Co'
PayDirection='Debit' >
<Brand ID ='M1.13'
BrandId='Mondex'
BrandName='Mondex Electronic Cash'
BrandLogoNetLocn='ftp://otplogos.mondex.com'
ProtocolAmountRefs='M1.17 M1.18'>
</Brand>
<Brand ID ='M1.14'
BrandId='GeldKarte'
BrandName='GeldKarte Electronic Cash'
BrandLogoNetLocn='ftp://otplogos.geldkarte.co.de'
ProtocolAmountRefs='M1.19'>
</Brand>
<Brand ID ='M1.15'
BrandId='CyberCoin'
BrandName='CyberCoin Eletronic Cash'
BrandLogoNetLocn='http://otplogos.cybercash.com'
ProtocolAmountRefs ='M1.20' >
</Brand >
<Brand ID ='M1.16'
BrandId='DigiCash'
BrandName='DigiCash Electronic Cash'
BrandLogoNetLocn='http://otplogos.digicash.com'
BrandNarrative='5% off with your Walmart Card
on purchases over $150'
ProtocolAmountRefs='M1.22'>
</Brand>
<ProtocolAmount ID ='M1.17'
PayProtocolRef='M1.31'
CurrencyAmountRefs='M1.25 M1.29'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.18'
PayProtocolRef='M1.32'
CurrencyAmountRefs='M1.26 M1.27 M1.28 M1.30'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.19'
PayProtocolRef='M1.35'
CurrencyAmountRefs='M1.28'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.20'
PayProtocolRef='M1.34 M1.33'
CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.21'
PayProtocolRef='M1.36'
CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>
</ProtocolAmount>
<CurrencyAmount ID ='M1.23'
Amount='20.00'
CurrCode='USD'/>
<CurrencyAmount ID ='M1.24'
Amount='12.00'
CurrCode='GBP'/>
<CurrencyAmount ID ='M1.25'
Amount='19.50'
CurrCode='USD'/>
<CurrencyAmount ID ='M1.26'
Amount='11.75'
CurrCode='GBP'/>
<CurrencyAmount ID ='M1.27'
Amount='36.00'
CurrCode='DEM'/>
<CurrencyAmount ID ='M1.28'
Amount='100.00'
CurrCode='FFR'/>
<CurrencyAmount ID ='M1.29'
Amount='22.00'
CurrCode='CAD'/>
<CurrencyAmount ID ='M1.30'
Amount='15000'
CurrCode='ITL'/>
<PayProtocol ID ='M1.31'
ProtocolId='MXv1.0'
ProtocolName='Mondex IOTP Protocol Version 1.0'
PayReqNetLocn='http://www.mxbankus.com/etill/mx' >
</PayProtocol>
<PayProtocol ID ='M1.32'
ProtocolId='MXv1.0'
ProtocolName='Mondex IOTP Protocol Version 1.0'
PayReqNetLocn='http://www.mxbankuk.com/vserver' >
</PayProtocol>
<PayProtocol ID ='M1.33'
ProtocolId='Ccashv1.0'
ProtocolName='CyberCoin Version 1.0'
PayReqNetLocn='http://www.cybercash.com/ccoin' >
</PayProtocol>
<PayProtocol ID ='M1.34'
ProtocolId='CCashv2.0'
ProtocolName='CyberCoin Version 2.0'
PayReqNetLocn='http://www.cybercash.com/ccoin' >
</PayProtocol>
<PayProtocol ID ='M1.35'
ProtocolId='GKv1.0'
ProtocolName='GeldKarte Version 1.0'
PayReqNetLocn='http://www.example.com/pgway' >
</PayProtocol>
<PayProtocol ID ='M1.36'
ProtocolId='DCashv1.0'
ProtocolName='DigiCash Protocol Version 1.0'
PayReqNetLocn='http://www.example.com/digicash' >
</PayProtocol>
</BrandList>
12. IANA Considerations
This section describes the codes that are controlled by IANA, and
also how new codes can be created for testing purposes that are not
controlled by IANA.
12.1 Codes Controlled by IANA
To help ensure interoperability, there is a need for codes used by
IOTP to be maintained in a controlled environment so that their
meaning and usage are well defined and duplicate codes avoided.
[IANA] is the mechanism to be used for this purpose as described in
RFC 2434.
The element types and attributes names to which this procedure
applies is shown in the table below together with the initial values
that are valid for these attributes.
Note that:
o the IETF Trade mailing list's email address is ietf-
trade@elistx.com
o "Designated Experts" (see [IANA]) are appointed by the IESG.
Element Type/ Attribute Values
Attribute Name
Algorithm/ "sha1" - indicates that a [SHA1] authentication
Name will apply
(When Algorithm
is a child of an "signature" - indicates that authentication
AuthReq consists of the generation of a digital signature.
Component)
"Pay:ppp" where "ppp" may be set to any valid
value for "iotpbrand" (see below)
With the exception of Algorithms that begin with
"pay:", new values are allocated following review
on the IETF Trade mailing list and by the
Designated Expert.
Note: The Algorithm element is likely to be eventually defined
within the [DSIG] name space. It is likely that the maintenance
procedure defined here may need to vary over time, as the DSIG
proposals become more widely adopted.
Element Type/ Attribute Values
Attribute Name
Brand/BrandId The following list of initial BrandIds have been
taken from those Organisations that have applied
for SET certificates as at 1st June 1999:
"Amex" - American Express
"Dankort" - Dankort
"JCB" - JCB
"Maestro" - Maestro
"MasterCard" - MasterCard
"NICOS" - NICOS
"VISA" - Visa
In addition the following Brand Id values are
defined:
"Mondex"
"GeldKarte"
New values of BrandId must be announced to the
IETF Trade mailing list and, if there are no
objections within three weeks, are allocated on a
"first come first served" basis.
CurrencyAmount/ Currency codes are dependent on CurrCodeType (see
CurrCode below).
If CurrCodeType is "ISO4217-A" then the currency
code is an alphabetic currency code as defined by
[ISO4217].
If CurrCodeType is "IOTP" then new values must be
announced to the IETF Trade mailing list and, if
there are no objections within three weeks, are
allocated on a "first come first served" basis.
Note: The Currency Code Type of IOTP, is designed to allow the
support of "new" psuedo currencies such as loyalty or frequent flyer
points. At the time of writing this specification, no currency codes
of this type have been defined.
Element Type/ Attribute Values
Attribute Name
CurrencyAmount/ "ISO4217-A"
CurrCodeType
"IOTP"
New values of CurrCodeType attribute are allocated
following review on the IETF Trade mailing list
and by the Designated Expert.
DeliveryData/ "Post"
DelivMethod
"Web"
"Email"
New values of Delivery Method attribute are
allocated following review on the IETF Trade
mailing list and by the Designated Expert. This
may require the publication of additional
documentation to describe how the delivery method
is used.
PackagedContent/ "PCDATA"
Content
"MIME"
"MIME:mimetype" (where mimetype must be the same
as content-type as defined by [MIME] )
"XML"
If the Content attribute is of the form
"MIME"mimetype", then control of new values for
"mimetype" is as defined in [MIME].
Otherwise, new values of the Content attribute are
allocated following review on the IETF Trade
mailing list and by the Designated Expert. This
may require the publication of additional
documentation to describe how the new attribute is
used within a Packaged Content element.
RelatedTo/ "IotpTransaction"
RelationshipType
"Reference"
New values of the RelationshipType attribute are
allocated following review on the IETF Trade
Working Group mailing list and by the Designated
Expert. This may require the publication of
additional documentation to describe how the
Element Type/ Attribute Values
Attribute Name
delivery method is used.
Status/ Offer
StatusType
Payment
Delivery
Authentication
Unidentified
New values of the Status Type attribute are
allocated following:
o publication to the IETF Trade Working Group,
of an RFC describing the Trading Exchange,
Trading Roles and associated components that
relate to the Status, and
o review of the document on the IETF Trade
mailing list and by the Designated Expert.
Note: The document describing new values for the Status Type
attribute may be combined with documents that describe new Trading
Roles and types of signatures (see below).
TradingRole/ "Consumer"
TradingRole
"Merchant"
"PaymentHandler"
"DeliveryHandler"
"DelivTo"
"CustCare"
New values of the Trading Role attribute are
allocated following:
o publication to the IETF Trade Working Group,
of an RFC describing the Trading Exchange,
Trading Roles and associated components that
relate to the Trading Role, and
o review of the document on the IETF Trade
mailing list and by the Designated Expert.
Note: The document describing new values for the Trading Role
attribute may be
Element Type/ Attribute Values
Attribute Name
combined with documents that describe
new Status Types (see above) and
types of signatures (see below).
TransId/ "BaselineAuthentication"
IotpTransType
"BaselineDeposit"
"BaselinePurchase"
"BaselineRefund"
"BaselineWithdrawal"
"BaselineValueExchange"
"BaselineInquiry"
"BaselinePing"
New values of the IotpTransType attribute are
allocated following:
o publication to the IETF Trade mailing list, of
an RFC describing the new IOTP Transaction, and
o review of the document on the IETF Trade
Working Group mailing list and by the
Designated Expert.
Attribute/ Content
(see Signature
"OfferResponse"
Component) "PaymentResponse"
"DeliveryResponse"
"AuthenticationRequest"
"AuthenticationResponse"
"PingRequest"
"PingResponse"
New values of the code that define the type of a
signature are allocated following:
o publication to the IETF Trade Working Group,
of an RFC describing the Trading Exchange where
the signature is being used, and
o review of the document on the IETF Trade
mailing list and by the Designated Expert.
Element Type/ Attribute Values
Attribute Name
Note: The document describing new values for the types of signatures
may be combined with documents that describe new Status Types and
Trading Roles (see above).
12.2 Codes not controlled by IANA
In addition to the formal development and registration of codes as
described above, there is still a need for developers to experiment
using new IOTP codes. For this reason, "user defined codes" may be
used to identify additional values for the codes contained within
this specification without the need for them to be registered with
IANA.
The definition of a user defined code is as follows:
user_defined_code ::= ( "x-" | "X-" ) NameChar (NameChar)*
NameChar NameChar has the same definition as the [XML]
definition of NameChar
Use of domain names (see [DNS]) to make user defined codes unique is
recommended although this method cannot be relied upon.
13. Internet Open Trading Protocol Data Type Definition
This section contains the XML DTD for the Internet Open Trading
Protocols.
<!--
******************************************************
* *
* INTERNET OPEN TRADING PROTOCOL VERSION 1.0 DTD *
* Filename: ietf.org/rfc/rfc2801.dtd *
* *
* Changes from version 07 (iotp-v1.0-protocol-07.dtd)*
* - NO CHANGES *
* *
* *
* *
* *
* Copyright Internet Engineering Task Force 1998-2000*
* *
******************************************************
******************************************************
* IOTP MESSAGE DEFINITION *
******************************************************
-->
<!ELEMENT IotpMessage
( TransRefBlk,
IotpSignatures?,
ErrorBlk?,
( AuthReqBlk |
AuthRespBlk |
AuthStatusBlk |
CancelBlk |
DeliveryReqBlk |
DeliveryRespBlk |
InquiryReqBlk |
InquiryRespBlk |
OfferRespBlk |
PayExchBlk |
PayReqBlk |
PayRespBlk |
PingReqBlk |
PingRespBlk |
TpoBlk |
TpoSelectionBlk
)*
) >
<!ATTLIST IotpMessage
xmlns CDATA
'iotp:ietf.org/iotp-v1.0' >
<!--
******************************************************
* TRANSACTION REFERENCE BLOCK DEFINITION *
******************************************************
-->
<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) >
<!ATTLIST TransRefBlk
ID ID #REQUIRED >
<!ELEMENT TransId EMPTY >
<!ATTLIST TransId
ID ID #REQUIRED
Version NMTOKEN #FIXED '1.0'
IotpTransId CDATA #REQUIRED
IotpTransType CDATA #REQUIRED
TransTimeStamp CDATA #REQUIRED >
<!ELEMENT MsgId EMPTY >
<!ATTLIST MsgId
ID ID #REQUIRED
RespIotpMsg NMTOKEN #IMPLIED
xml:lang NMTOKEN #REQUIRED
LangPrefList NMTOKENS #IMPLIED
CharSetPrefList NMTOKENS #IMPLIED
SenderTradingRoleRef NMTOKEN #IMPLIED
SoftwareId CDATA #REQUIRED
TimeStamp CDATA #IMPLIED >
<!ELEMENT RelatedTo (PackagedContent) >
<!ATTLIST RelatedTo
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
RelationshipType NMTOKEN #REQUIRED
Relation CDATA #REQUIRED
RelnKeyWords NMTOKENS #IMPLIED >
<!--
******************************************************
* Packaged Content Common Element *
******************************************************
-->
<!ELEMENT PackagedContent (#PCDATA) >
<!ATTLIST PackagedContent
Name CDATA #IMPLIED
Content NMTOKEN "PCDATA"
Transform (NONE|BASE64) "NONE" >
<!--
******************************************************
* TRADING COMPONENTS *
******************************************************
-->
<!-- PROTOCOL OPTIONS COMPONENT -->
<!ELEMENT ProtocolOptions EMPTY >
<!ATTLIST ProtocolOptions
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
ShortDesc CDATA #REQUIRED
SenderNetLocn CDATA #IMPLIED
SecureSenderNetLocn CDATA #IMPLIED
SuccessNetLocn CDATA #REQUIRED >
<!-- AUTHENTICATION DATA COMPONENT -->
<!ELEMENT AuthReq (Algorithm, PackagedContent*)>
<!ATTLIST AuthReq
ID ID #REQUIRED
AuthenticationId CDATA #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- AUTHENTICATION RESPONSE COMPONENT -->
<!ELEMENT AuthResp (PackagedContent*) >
<!ATTLIST AuthResp
ID ID #REQUIRED
AuthenticationId CDATA #REQUIRED
SelectedAlgorithmRef NMTOKEN #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- TRADING ROLE INFO REQUEST COMPONENT -->
<!ELEMENT TradingRoleInfoReq EMPTY>
<!ATTLIST TradingRoleInfoReq
ID ID #REQUIRED
TradingRoleList NMTOKENS #REQUIRED >
<!-- ORDER COMPONENT -->
<!ELEMENT Order (PackagedContent*) >
<!ATTLIST Order
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
OrderIdentifier CDATA #REQUIRED
ShortDesc CDATA #REQUIRED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
ApplicableLaw CDATA #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- ORGANISATION COMPONENT -->
<!ELEMENT Org (TradingRole+, ContactInfo?,
PersonName?, PostalAddress?)>
<!ATTLIST Org
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
OrgId CDATA #REQUIRED
LegalName CDATA #IMPLIED
ShortDesc CDATA #IMPLIED
LogoNetLocn CDATA #IMPLIED >
<!ELEMENT TradingRole EMPTY >
<!ATTLIST TradingRole
ID ID#REQUIRED
TradingRole NMTOKEN #REQUIRED
IotpMsgIdPrefix NMTOKEN #REQUIRED
CancelNetLocn CDATA #IMPLIED
ErrorNetLocn CDATA #IMPLIED
ErrorLogNetLocn CDATA #IMPLIED >
<!ELEMENT ContactInfo EMPTY >
<!ATTLIST ContactInfo
xml:lang NMTOKEN #IMPLIED
Tel CDATA #IMPLIED
Fax CDATA #IMPLIED
Email CDATA #IMPLIED
NetLocn CDATA #IMPLIED >
<!ELEMENT PersonName EMPTY >
<!ATTLIST PersonName
xml:lang NMTOKEN #IMPLIED
Title CDATA #IMPLIED
GivenName CDATA #IMPLIED
Initials CDATA #IMPLIED
FamilyName CDATA #IMPLIED >
<!ELEMENT PostalAddress EMPTY >
<!ATTLIST PostalAddress
xml:lang NMTOKEN #IMPLIED
AddressLine1 CDATA #IMPLIED
AddressLine2 CDATA #IMPLIED
CityOrTown CDATA #IMPLIED
StateOrRegion CDATA #IMPLIED
PostalCode CDATA #IMPLIED
Country CDATA #IMPLIED
LegalLocation (True | False) 'False' >
<!-- BRAND LIST COMPONENT -->
<!ELEMENT BrandList (Brand+, ProtocolAmount+,
CurrencyAmount+, PayProtocol+) >
<!ATTLIST BrandList
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
ShortDesc CDATA #REQUIRED
PayDirection (Debit | Credit) #REQUIRED >
<!ELEMENT Brand (ProtocolBrand*, PackagedContent*) >
<!ATTLIST Brand
ID ID #REQUIRED
xml:lang NMTOKEN #IMPLIED
BrandId CDATA #REQUIRED
BrandName CDATA #REQUIRED
BrandLogoNetLocn CDATA #REQUIRED
BrandNarrative CDATA #IMPLIED
ProtocolAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT ProtocolBrand (PackagedContent*) >
<!ATTLIST ProtocolBrand
ProtocolId CDATA #REQUIRED
ProtocolBrandId CDATA #REQUIRED >
<!ELEMENT ProtocolAmount (PackagedContent*) >
<!ATTLIST ProtocolAmount
ID ID #REQUIRED
PayProtocolRef IDREF #REQUIRED
CurrencyAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount
ID ID #REQUIRED
Amount CDATA #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED >
<!ELEMENT PayProtocol (PackagedContent*) >
<!ATTLIST PayProtocol
ID ID #REQUIRED
xml:lang NMTOKEN #IMPLIED
ProtocolId NMTOKEN #REQUIRED
ProtocolName CDATA #REQUIRED
ActionOrgRef NMTOKEN #REQUIRED
PayReqNetLocn CDATA #IMPLIED
SecPayReqNetLocn CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
<!-- BRAND SELECTION COMPONENT -->
<!ELEMENT BrandSelection (BrandSelBrandInfo?,
BrandSelProtocolAmountInfo?,
BrandSelCurrencyAmountInfo?) >
<!ATTLIST BrandSelection
ID ID #REQUIRED
BrandListRef NMTOKEN #REQUIRED
BrandRef NMTOKEN #REQUIRED
ProtocolAmountRef NMTOKEN #REQUIRED
CurrencyAmountRef NMTOKEN #REQUIRED >
<!ELEMENT BrandSelBrandInfo (PackagedContent+) >
<!ATTLIST BrandSelBrandInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent+) >
<!ATTLIST BrandSelProtocolAmountInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent+) >
<!ATTLIST BrandSelCurrencyAmountInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- PAYMENT COMPONENT -->
<!ELEMENT Payment EMPTY >
<!ATTLIST Payment
ID ID #REQUIRED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
BrandListRef NMTOKEN #REQUIRED
SignedPayReceipt (True | False) #REQUIRED
StartAfterRefs NMTOKENS #IMPLIED >
<!-- PAYMENT SCHEME COMPONENT -->
<!ELEMENT PaySchemeData (PackagedContent+) >
<!ATTLIST PaySchemeData
ID ID #REQUIRED
PaymentRef NMTOKEN #IMPLIED
ConsumerPaymentId CDATA #IMPLIED
PaymentHandlerPayId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
<!-- PAYMENT RECEIPT COMPONENT -->
<!ELEMENT PayReceipt (PackagedContent*) >
<!ATTLIST PayReceipt
ID ID #REQUIRED
PaymentRef NMTOKEN #REQUIRED
PayReceiptNameRefs NMTOKENS #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
<!-- PAYMENT NOTE COMPONENT -->
<!ELEMENT PaymentNote (PackagedContent+) >
<!ATTLIST PaymentNote
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- DELIVERY COMPONENT -->
<!ELEMENT Delivery (DeliveryData?, PackagedContent*) >
<!ATTLIST Delivery
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
DelivExch (True | False) #REQUIRED
DelivAndPayResp (True | False) #REQUIRED
ActionOrgRef NMTOKEN #IMPLIED >
<!ELEMENT DeliveryData (PackagedContent*) >
<!ATTLIST DeliveryData
xml:lang NMTOKEN #IMPLIED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
DelivMethod NMTOKEN #REQUIRED
DelivToRef NMTOKEN #REQUIRED
DelivReqNetLocn CDATA #IMPLIED
SecDelivReqNetLocn CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
<!-- CONSUMER DELIVERY DATA COMPONENT -->
<!ELEMENT ConsumerDeliveryData EMPTY >
<!ATTLIST ConsumerDeliveryData
ID ID #REQUIRED
ConsumerDeliveryId CDATA #REQUIRED >
<!-- DELIVERY NOTE COMPONENT -->
<!ELEMENT DeliveryNote (PackagedContent+) >
<!ATTLIST DeliveryNote
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
DelivHandlerDelivId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
<!-- STATUS COMPONENT -->
<!ELEMENT Status EMPTY >
<!ATTLIST Status
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
StatusType NMTOKEN #REQUIRED
ElRef NMTOKEN #IMPLIED
ProcessState (NotYetStarted | InProgress |
CompletedOk | Failed | ProcessError) #REQUIRED
CompletionCode NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIED
StatusDesc CDATA #IMPLIED >
<!-- TRADING ROLE DATA COMPONENT -->
<!ELEMENT TradingRoleData (PackagedContent+) >
<!ATTLIST TradingRoleData
ID ID #REQUIRED
OriginatorElRef NMTOKEN #REQUIRED
DestinationElRefs NMTOKENS #REQUIRED >
<!-- INQUIRY TYPE COMPONENT -->
<!ELEMENT InquiryType EMPTY >
<!ATTLIST InquiryType
ID ID #REQUIRED
Type NMTOKEN #REQUIRED
ElRef NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIED >
<!-- ERROR COMPONENT -->
<!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*) >
<!ATTLIST ErrorComp
ID NMTOKEN #REQUIRED
xml:lang NMTOKEN #REQUIRED
ErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED
Severity (Warning|TransientError|HardError) #REQUIRED
MinRetrySecs CDATA #IMPLIED
SwVendorErrorRef CDATA #IMPLIED >
<!ELEMENT ErrorLocation EMPTY >
<!ATTLIST ErrorLocation
ElementType NMTOKEN #REQUIRED
IotpMsgRef NMTOKEN #IMPLIED
BlkRef NMTOKEN #IMPLIED
CompRef NMTOKEN #IMPLIED
ElementRef NMTOKEN #IMPLIED
AttName NMTOKEN #IMPLIED >
<!--
******************************************************
* TRADING BLOCKS *
******************************************************
-->
<!-- TRADING PROTOCOL OPTIONS BLOCK -->
<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* ) >
<!ATTLIST TpoBlk
ID ID #REQUIRED >
<!-- TPO SELECTION BLOCK -->
<!ELEMENT TpoSelectionBlk (BrandSelection+) >
<!ATTLIST TpoSelectionBlk
ID ID #REQUIRED >
<!-- OFFER RESPONSE BLOCK -->
<!ELEMENT OfferRespBlk (Status, Order?, Payment*,
Delivery?, TradingRoleData*) >
<!ATTLIST OfferRespBlk
ID ID #REQUIRED >
<!-- AUTHENTICATION REQUEST BLOCK -->
<!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?) >
<!ATTLIST AuthReqBlk
ID ID #REQUIRED >
<!-- AUTHENTICATION RESPONSE BLOCK -->
<!ELEMENT AuthRespBlk (AuthResp?, Org*) >
<!ATTLIST AuthRespBlk
ID ID #REQUIRED >
<!-- AUTHENTICATION STATUS BLOCK -->
<!ELEMENT AuthStatusBlk (Status) >
<!ATTLIST AuthStatusBlk
ID ID #REQUIRED >
<!-- PAYMENT REQUEST BLOCK -->
<!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection,
Payment, PaySchemeData?, Org*, TradingRoleData*) >
<!ATTLIST PayReqBlk
ID ID #REQUIRED >
<!-- PAYMENT EXCHANGE BLOCK -->
<!ELEMENT PayExchBlk (PaySchemeData) >
<!ATTLIST PayExchBlk
ID ID #REQUIRED >
<!-- PAYMENT RESPONSE BLOCK -->
<!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,
PaymentNote?, TradingRoleData*) >
<!ATTLIST PayRespBlk
ID ID #REQUIRED >
<!-- DELIVERY REQUEST BLOCK -->
<!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
ConsumerDeliveryData?, TradingRoleData*) >
<!ATTLIST DeliveryReqBlk
ID ID #REQUIRED >
<!-- DELIVERY RESPONSE BLOCK -->
<!ELEMENT DeliveryRespBlk (Status, DeliveryNote) >
<!ATTLIST DeliveryRespBlk
ID ID #REQUIRED >
<!-- INQUIRY REQUEST BLOCK -->
<!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) >
<!ATTLIST InquiryReqBlk
ID ID #REQUIRED >
<!-- INQUIRY RESPONSE BLOCK -->
<!ELEMENT InquiryRespBlk (Status, PaySchemeData?) >
<!ATTLIST InquiryRespBlk
ID ID #REQUIRED
LastReceivedIotpMsgRef NMTOKEN #IMPLIED
LastSentIotpMsgRef NMTOKEN #IMPLIED >
<!-- PING REQUEST BLOCK -->
<!ELEMENT PingReqBlk (Org*)>
<!ATTLIST PingReqBlk
ID ID #REQUIRED>
<!-- PING RESPONSE BLOCK -->
<!ELEMENT PingRespBlk (Org+)>
<!ATTLIST PingRespBlk
ID ID #REQUIRED
PingStatusCode (Ok | Busy | Down) #REQUIRED
SigVerifyStatusCode (Ok | NotSupported | Fail) #IMPLIED
xml:lang NMTOKEN #IMPLIED
PingStatusDesc CDATA #IMPLIED>
<!-- ERROR BLOCK -->
<!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) >
<!ATTLIST ErrorBlk
ID ID #REQUIRED >
<!-- CANCEL BLOCK -->
<!ELEMENT CancelBlk (Status) >
<!ATTLIST CancelBlk
ID ID #REQUIRED >
<!--
******************************************************
* IOTP SIGNATURES BLOCK DEFINITION *
******************************************************
-->
<!ELEMENT IotpSignatures (Signature+ ,Certificate*) >
<!ATTLIST IotpSignatures
ID ID #IMPLIED
>
<!--
******************************************************
* IOTP SIGNATURE COMPONENT DEFINITION *
******************************************************
-->
<!ELEMENT Signature (Manifest, Value+) >
<!ATTLIST Signature
ID ID #IMPLIED
>
<!ELEMENT Manifest
( Algorithm+,
Digest+,
Attribute*,
OriginatorInfo,
RecipientInfo+
)
>
<!ATTLIST Manifest
LocatorHRefBase CDATA #IMPLIED
>
<!ELEMENT Algorithm (Parameter*) >
<!ATTLIST Algorithm
ID ID #REQUIRED
type (digest|signature) #IMPLIED
name NMTOKEN #REQUIRED
>
<!ELEMENT Digest (Locator, Value) >
<!ATTLIST Digest
DigestAlgorithmRef IDREF #REQUIRED
>
<!ELEMENT Attribute ( ANY ) >
<!ATTLIST Attribute
type NMTOKEN #REQUIRED
critical ( true | false ) #REQUIRED
>
<!ELEMENT OriginatorInfo ANY >
<!ATTLIST OriginatorInfo
OriginatorRef NMTOKEN #IMPLIED
>
<!ELEMENT RecipientInfo ANY >
<!ATTLIST RecipientInfo
SignatureAlgorithmRef IDREF #REQUIRED
SignatureValueRef IDREF #IMPLIED
SignatureCertRef IDREF #IMPLIED
RecipientRefs NMTOKENS #IMPLIED
>
<!ELEMENT KeyIdentifier EMPTY>
<!ATTLIST KeyIdentifier
value CDATA #REQUIRED
>
<!ELEMENT Parameter ANY >
<!ATTLIST Parameter
type CDATA #REQUIRED
>
<!--
******************************************************
* IOTP CERTIFICATE COMPONENT DEFINITION *
******************************************************
-->
<!ELEMENT Certificate
( IssuerAndSerialNumber, ( Value | Locator ) )
>
<!ATTLIST Certificate
ID ID #IMPLIED
type NMTOKEN #REQUIRED
>
<!ELEMENT IssuerAndSerialNumber EMPTY >
<!ATTLIST IssuerAndSerialNumber
issuer CDATA #REQUIRED
number CDATA #REQUIRED
>
<!--
******************************************************
* IOTP SHARED COMPONENT DEFINITION *
******************************************************
-->
<!ELEMENT Value ( #PCDATA ) >
<!ATTLIST Value
ID ID #IMPLIED
encoding (base64|none) 'base64'
>
<!ELEMENT Locator EMPTY>
<!ATTLIST Locator
xml:link CDATA #FIXED 'simple'
href CDATA #REQUIRED
>
(page 277 continued on part 9)