RFC2801 - Internet Open Trading Protocol - IOTP Version 1.0(5)

<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

RFC2434.

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 RFCdescribing 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 RFCdescribing 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 RFCdescribing 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 RFCdescribing 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 (NONEBASE64) "NONE" >

<!--

******************************************************

* TRADING COMPONENTS *

******************************************************

-->

<!ELEMENT ProtocolOptions EMPTY >

<!ATTLIST ProtocolOptions

ID ID #REQUIRED

xml:lang NMTOKEN #REQUIRED

ShortDesc CDATA #REQUIRED

SenderNetLocn CDATA #IMPLIED

SecureSenderNetLocn CDATA #IMPLIED

SuccessNetLocn CDATA #REQUIRED >

<!ELEMENT AuthReq (Algorithm, PackagedContent*)>

<!ATTLIST AuthReq

ID ID #REQUIRED

AuthenticationId CDATA #REQUIRED

ContentSoftwareId CDATA #IMPLIED >

<!ELEMENT AuthResp (PackagedContent*) >

<!ATTLIST AuthResp

ID ID #REQUIRED

AuthenticationId CDATA #REQUIRED

SelectedAlgorithmRef NMTOKEN #REQUIRED

ContentSoftwareId CDATA #IMPLIED >

<!ELEMENT TradingRoleInfoReq EMPTY>

<!ATTLIST TradingRoleInfoReq

ID ID #REQUIRED

TradingRoleList NMTOKENS #REQUIRED >

<!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 >

<!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' >

<!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 >

<!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 >

<!ELEMENT Payment EMPTY >

<!ATTLIST Payment

ID ID #REQUIRED

OkFrom CDATA #REQUIRED

OkTo CDATA #REQUIRED

BrandListRef NMTOKEN #REQUIRED

SignedPayReceipt (True False) #REQUIRED

StartAfterRefs NMTOKENS #IMPLIED >

<!ELEMENT PaySchemeData (PackagedContent+) >

<!ATTLIST PaySchemeData

ID ID #REQUIRED

PaymentRef NMTOKEN #IMPLIED

ConsumerPaymentId CDATA #IMPLIED

PaymentHandlerPayId CDATA #IMPLIED

ContentSoftwareId CDATA #IMPLIED >

<!ELEMENT PayReceipt (PackagedContent*) >

<!ATTLIST PayReceipt

ID ID #REQUIRED

PaymentRef NMTOKEN #REQUIRED

PayReceiptNameRefs NMTOKENS #IMPLIED

ContentSoftwareId CDATA #IMPLIED >

<!ELEMENT PaymentNote (PackagedContent+) >

<!ATTLIST PaymentNote

ID ID #REQUIRED

ContentSoftwareId CDATA #IMPLIED >

<!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 >

<!ELEMENT ConsumerDeliveryData EMPTY >

<!ATTLIST ConsumerDeliveryData

ID ID #REQUIRED

ConsumerDeliveryId CDATA #REQUIRED >

<!ELEMENT DeliveryNote (PackagedContent+) >

<!ATTLIST DeliveryNote

ID ID #REQUIRED

xml:lang NMTOKEN #REQUIRED

DelivHandlerDelivId CDATA #IMPLIED

ContentSoftwareId CDATA #IMPLIED >

<!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 >

<!ELEMENT TradingRoleData (PackagedContent+) >

<!ATTLIST TradingRoleData

ID ID #REQUIRED

OriginatorElRef NMTOKEN #REQUIRED

DestinationElRefs NMTOKENS #REQUIRED >

<!ELEMENT InquiryType EMPTY >

<!ATTLIST InquiryType

ID ID #REQUIRED

Type NMTOKEN #REQUIRED

ElRef NMTOKEN #IMPLIED

ProcessReference CDATA #IMPLIED >

<!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*) >

<!ATTLIST ErrorComp

ID NMTOKEN #REQUIRED

xml:lang NMTOKEN #REQUIRED

ErrorCode NMTOKEN #REQUIRED

ErrorDesc CDATA #REQUIRED

Severity (WarningTransientErrorHardError) #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 *

******************************************************

-->

<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* ) >

<!ATTLIST TpoBlk

ID ID #REQUIRED >

<!ELEMENT TpoSelectionBlk (BrandSelection+) >

<!ATTLIST TpoSelectionBlk

ID ID #REQUIRED >

<!ELEMENT OfferRespBlk (Status, Order?, Payment*,

Delivery?, TradingRoleData*) >

<!ATTLIST OfferRespBlk

ID ID #REQUIRED >

<!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?) >

<!ATTLIST AuthReqBlk

ID ID #REQUIRED >

<!ELEMENT AuthRespBlk (AuthResp?, Org*) >

<!ATTLIST AuthRespBlk

ID ID #REQUIRED >

<!ELEMENT AuthStatusBlk (Status) >

<!ATTLIST AuthStatusBlk

ID ID #REQUIRED >

<!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection,

Payment, PaySchemeData?, Org*, TradingRoleData*) >

<!ATTLIST PayReqBlk

ID ID #REQUIRED >

<!ELEMENT PayExchBlk (PaySchemeData) >

<!ATTLIST PayExchBlk

ID ID #REQUIRED >

<!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,

PaymentNote?, TradingRoleData*) >

<!ATTLIST PayRespBlk

ID ID #REQUIRED >

<!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,

ConsumerDeliveryData?, TradingRoleData*) >

<!ATTLIST DeliveryReqBlk

ID ID #REQUIRED >

<!ELEMENT DeliveryRespBlk (Status, DeliveryNote) >

<!ATTLIST DeliveryRespBlk

ID ID #REQUIRED >

<!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) >

<!ATTLIST InquiryReqBlk

ID ID #REQUIRED >

<!ELEMENT InquiryRespBlk (Status, PaySchemeData?) >

<!ATTLIST InquiryRespBlk

ID ID #REQUIRED

LastReceivedIotpMsgRef NMTOKEN #IMPLIED

LastSentIotpMsgRef NMTOKEN #IMPLIED >

<!ELEMENT PingReqBlk (Org*)>

<!ATTLIST PingReqBlk

ID ID #REQUIRED>

<!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>

<!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) >

<!ATTLIST ErrorBlk

ID ID #REQUIRED >

<!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 (digestsignature) #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 (base64none) 'base64'

<!ELEMENT Locator EMPTY>

<!ATTLIST Locator

xml:link CDATA #FIXED 'simple'

href CDATA #REQUIRED

14. Glossary

This section contains a glossary of some of the terms used within

this specification in alphabetical order.

NAME DESCRIPTION

Authenticator The Organisation which is requesting the

authentication of another Organisation, and

Authenticatee The Organisation being authenticated by an

Authenticator

Business Error See Status Component.

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, American Express, Mondex,

GeldKarte, CyberCash, etc.

o Promotional Brands (see below). These include:

o store Brands, where the Payment Instrument is

issued to a Consumer by a particular Merchant,

for example Walmart, Sears, or Marks and

Spencer (UK)

o coBrands, for example American Advantage Visa,

where an a company uses their own Brand in

conjunction with, typically, a payment

association Brand.

Consumer The Organisation which is to receive the benefit

of and typically pay for the goods or services.

ContentSoftwareId This contains information which identifies the

software which generated the content of the

element. Its purpose is to help resolve

interoperability problems that might occur as a

result of incompatibilities between messages

produced by different software. It is a single

text string in the language defined by xml:lang.

It must contain, as a minimum:

o the name of the software manufacturer

o the name of the software

o the version of the software, and

o the build of the software

It is recommended that this attribute is included

whenever the software which generated the content

cannot be identified from the SoftwareId attribute

on the Message Id Component (see section 3.3.2)

Customer Care An Organisation that is providing customer care

Provider typically on behalf of a Merchant. Examples of

customer care include, responding to problems

raised by a Consumer arising from an IOTP

Transaction that the Consumer took part in.

Delivery Handler The Organisation that directly delivers the goods

or services to the Consumer on behalf of the

Merchant. Delivery can be in the form of either

digital goods (e.g., a [MIME] message), or

physically delivered using the post or a courier.

Document Exchange A Document Exchange consists of a set of IOTP

Messages exchanged between two parties that

implement part or all of two Trading Exchanges

simultaneously in order to minimise the number of

actual IOTP Messages which must be sent over the

Internet.

Document Exchanges are combined together in

sequence to implement a particular IOTP

Transaction.

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.

Error Block An Error Block reports that a Technical Error was

found in an IOTP Message that was previously

received. Typically Technical Errors are caused by

errors in the XML which has been received or some

technical failure of the processing of the IOTP

Message. Frequently the generation or receipt of

an Error Block will result in failure of the IOTP

Transaction. They are distinct from Business

Errors, reported in a Status Component, which can

also cause failure of an IOTP Transaction.

Exchange Block An Exchange Block is sent between the two Trading

Roles involved in a Trading Exchange. It contains

one or more Trading Components. Exchange Blocks

are always sent after a Request Block and before a

Response Block in a Trading Exchange. The content

of an Exchange Block is dependent on the type of

Trading Exchange being carried out.

IOTP Message An IOTP Message is the outermost wrapper for the

document(s) which are sent between Trading Roles

that are taking part in a trade. It is a well

formed XML document. The documents it contains

consist of:

o a Transaction Reference Block to uniquely

identify the IOTP Transaction of which the IOTP

Message is part,

o an optional Signature Block to digitally sign

the Trading Blocks or Trading Components

associated with the IOTP Transaction

o an optional Error Block to report on technical

errors contained in a previously received IOTP

Message, and

o a collection of IOTP Trading Blocks which

carries the data required to carry out an IOTP

Transaction.

IOTP Transaction An instance of an Internet Open Trading Protocol

Transaction consists of a set of IOTP Messages

transferred between Trading Roles. The rules for

what may be contained in the IOTP Messages is

defined by the Transaction Type of the IOTP

Transaction.

IOTP Transaction A Transaction Type identifies the type an of IOTP

Type Transaction. Examples of Transaction Type include:

Purchase, Refund, Authentication, Withdrawal,

Deposit (of electronic cash). The Transaction Type

specifies for an IOTP Transaction:

o the Trading Exchanges which may be included in

the transaction,

o how those Trading Exchanges may be combined to

meet the business needs of the transaction

o which Trading Blocks may be included in the

IOTP Messages that make up the transaction

o Consult this specification for the rules that

apply for each Transaction Type.

Merchant The Organisation from whom the service or goods

are being obtained, who is legally responsible for

providing the goods or services and receives the

benefit of any payment made

Merchant Customer The Organisation that is involved with customer

Care Provider dispute negotiation and resolution on behalf of

the Merchant

Organisation A company or individual that takes part in a Trade

as a Trading Role. The Organisations may take one

or more of the roles involved in the Trade

Payment Handler The Organisation that physically receives the

payment from the Consumer on behalf of the

Merchant

Payment A Payment Instrument is the means by which

Instrument 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's CyberCoin or DigiCash

account.

All Payment Instruments have a number, typically

an account number, by which the Payment Instrument

can be identified.

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.

Each Promotional Brand should be identified as a

separate Brand in the list of Brands offered by

the Merchant.

Receipt Component A Receipt Component is a record of the successful

completion of a Trading Exchange. Examples of

Receipt Components include: Payment Receipts, and

Delivery Notes. It's content may dependent on the

technology used to perform the Trading Exchange.

For example a Secure Electronic Transaction (SET)

payment receipt consists of SET payment messages

which record the result of the payment.

Request Block A Request Block is Trading Block that contains a

request for a Trading Exchange to start. The

Trading Components in a Request Block may be

signed by a Signature Block so that their

authenticity may be checked and to determine that

the Trading Exchange being requested is

authorised. Authorisation for a Trading Exchange

to start can be provided by the signatures

contained on Receipt Components contained in

Response Blocks resulting from previously

completed Trading Exchanges. Examples of Request

Blocks are Payment Request and Delivery Request

Response Block A Response Block is a Trading Block that indicates

that a Trading Exchange is complete. It is sent by

the Trading Role that received a Request Block to

the Trading Role that sent the Request Block. The

Response Block contains a Status Component that

contains information about the completion of the

Trading Exchange, for example it indicates whether

or not the Trading Exchange completed

successfully. For some Trading Exchanges the

Response Block contains a Receipt Component that

forms a record of the Trading Exchange. Receipt

Components may be digitally signed using a

Signature Block to make completion non-refutable.

Examples of Response Blocks include Offer

Response, Payment Response and Delivery Response.

Signature Block A Signature Block is a Trading Block that contains

one or more digital signatures in the form of

Signature Components. A Signature Component may

digitally sign any Block or Component in any IOTP

Message in the same IOTP Transaction.

Status Component A Status Component contains information that

describes the state of a Trading Exchange.

Before the Trading Exchange is complete the Status

Component can indicate information about how the

Trading Exchange is progressing.

Once a Trading Exchange is complete the Status

Component can only indicate the success of the

Trading Exchange or that a Business Error has

occurred.

A Business Error indicates that continuation with

the Trading Exchange was not possible because of

some business rule or logic, for example,

"insufficient funds available", rather than any

Technical Error associated with the content or

format of the IOTP Messages in the IOTP

Transaction.

Technical Error See Error Block.

Trading Block A Trading Block consists of one or more Trading

Components. One or more Trading Blocks may be

contained within the IOTP Messages which are

physically sent in the form of [XML] documents

between the different Trading Roles that are

taking part in a trade. Trading Blocks are of

three main types:

o a Request Block,

o an Exchange Block, or a

o a Response Block

Trading Component A Trading Component is a collection of XML

elements and attributes. Trading Components are

the child elements of the Trading Blocks. Examples

of Trading Components are: Offer, Brand List,

Payment Receipt, Delivery [information], Payment

Amount [information]

Trading Exchange A Trading Exchange consists of the exchange,

between two Trading Roles, of a sequence of

documents. The documents may be in the form of

Trading Blocks or they may be transferred by some

other means, for example through entering data

into a web page. Each Trading Exchange consists of

three main parts:

o the sending of a Request Block by one Trading

Role (the initiator) to another Trading Role

(the recipient),

o the optional exchange of one or more Exchange

Blocks between the recipient and the initiator,

until eventually,

o the Trading Role that received the Request

Block sends a Response Block to the initiator.

A Trading Exchange is designed to implement a

useful service of some kind. Examples of Trading

Exchanges/services are:

o Offer, which results in a Consumer receiving

an offer from a Merchant to carry out a

business transaction of some kind,

o Payment, where a Consumer makes a payment to a

Payment Handler,

o Delivery, where a Consumer requests, and

optionally obtains, delivery of goods or

services from a Delivery Handler, and

o Authentication, where any Trading Role may

request and receive information about another

Trading Role.

Trading Role A Trading Role identifies the different ways in

which Organisations can participate in a trade.

There are five Trading Roles: Consumer, Merchant,

Payment Handler, Delivery Handler, and Merchant

Customer Care Provider.

Transaction A Transaction Reference Block identifies an IOTP

Reference Block Transaction. It contains data that identifies:

o the Transaction Type,

o the IOTP Transaction uniquely, through a

globally unique transaction identifier

o the IOTP Message uniquely within the IOTP

Transaction, through a message identifier

The Transaction Reference Block may also contain

references to other transactions which may or may

not be IOTP Transactions

15. References

This section contains references to related documents identified in

this specification.

[Base64] Freed, N. and N. Borenstein, "Multipurpose Internet Mail

Extensions (MIME) Part One: Format of Internet Message

Bodies", RFC2045, November 1996.

[DOM-HASH] Maruyama, H., Tamura, K. and N. Uramoto, "Digest Values

for DOM (DOMHASH)", RFC2803, April 2000.

[DNS] Mockapetris, P., "Domain names - concepts and

facilities", STD 13, RFC1034, November 1987.

[DNS] Mockapetris, P., "Domain names - implementation and

specification", STD 13, RFC1035, November 1987.

[DSA] The Digital Signature Algorithm (DSA) published by the

National Institute of Standards and Technology (NIST) in

the Digital Signature Standard (DSS), which is a part of

the US government's Capstone project.

[ECCDSA] Elliptic Curve Cryptosystems Digital Signature Algorithm

(ECCDSA). Elliptic curve cryptosystems are analogues of

public-key cryptosystems such as RSA in which modular

multiplication is replaced by the elliptic curve addition

operation. See: V. S. Miller. Use of elliptic curves in

cryptography. In Advances in Cryptology - Crypto '85,

pages 417-426, Springer-Verlag, 1986.

[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-

Hashing for Message Authentication", RFC2104, February

1997.

[HTML] Berners-Lee, T. and D. Connolly, "Hypertext Markup

Language - 2.0", RFC1866, November 1995.

[HTML] Hyper Text Mark Up Language. The Hypertext Mark-up

Language (HTML) is a simple mark-up language used to

create hypertext documents that are platform independent.

See the World Wide Web (W3C) consortium web site at:

http://www.w3.org/MarkUp/

[HTTP] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext

Transfer Protocol -- HTTP/1.0", RFC1945, May 1996.

[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, T. and T.

Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1.",

RFC2616, June 1999.

[IANA] The Internet Assigned Numbers Authority. The organisation

responsible for co-ordinating the names and numbers

associated with the Internet. See http://www.iana.org/

[ISO4217] ISO 4217: Codes for the Representation of Currencies.

Available from ANSI or ISO.

[IOTPDSIG] Davidson, K. and Y. Kawatsura, "Digital Signatures for

the v1.0 Internet Open Trading Protocol (IOTP)", RFC

2802, April 2000.

[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321,

April 1992.

[MIME] Crocker, D., "Standard for the Format of ARPA Internet

Text Messages", STD 11, RFC822, August 1982.

[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail

Extensions (MIME) Part One: Format of Internet Message

Bodies", RFC2045, November 1996.

[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail

Extensions (MIME) Part Two: Media Types", RFC2046,

November 1996.

[MIME] Moore, K., "MIME (Multipurpose Internet Mail Extensions)

Part Three: Message Header Extensions for Non-ASCII Text"

RFC2047, November 1996.

[MIME] Freed, N., Klensin, J. and J. Postel, "Multipurpose

Internet Mail Extensions (MIME) Part Four: Registration

Procedures", RFC2048, November 1996.

[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail

Extensions (MIME) Part Five: Conformance Criteria and

Examples" RFC2049, November 1996.

[OPS] Open Profiling Standard. A proposed standard which

provides a framework with built-in privacy safeguards for

the trusted exchange of profile information between

individuals and web sites. Being developed by Netscape

and Microsoft amongst others.

[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform

Resource Locators (URL)", RFC1738, December 1994.

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an

IANA Considerations Section in RFCs", BCP 26, RFC2434,

October 1998.

[RSA] RSA is a public-key cryptosystem for both encryption and

authentication supported by RSA Data Security Inc. See:

R. L. Rivest, A. Shamir, and L.M. Adleman. A method for

obtaining digital signatures and public-key

cryptosystems. Communications of the ACM, 21(2): 120-126,

February 1978.

[SCCD] Secure Channel Credit Debit. A method of conducting a

credit or debit card payment where unauthorised access to

account information is prevented through use of secure

channel transport mechanisms such as SSL/TLS. An IOTP

supplement describing how SCCD works is under

development.

[SET] Secure Electronic Transaction Specification, Version 1.0,

May 31, 1997. Supports credit and debit card payments

using certificates at the Consumer and Merchant to help

ensure authenticity. Download from:

<http://www.setco.org>.

[SSL/TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",

RFC2246, January 1999.

[SHA1] [FIPS-180-1]"Secure Hash Standard", National Institute of

Standards and Technology, US Department Of Commerce,

April 1995. Also known as: 59 Fed Reg. 35317 (1994). See

http://www.itl.nist.gov/div897/pubs/fip180-1.htm

[UTC] Universal Time Co-ordinated. A method of defining time

absolutely relative to Greenwich Mean Time (GMT).

Typically of the form: "CCYY-MM-DDTHH:MM:SS.sssZ+n"

where the "+n" defines the number of hours from GMT. See

ISO DIS8601.

[UTF16] The Unicode Standard, Version 2.0. The Unicode

Consortium, Reading, Massachusetts. See ISO/IEC 10646 1

Proposed Draft Amendment 1

[X.509] ITU Recommendation X.509 1993 ISO/IEC 9594-8: 1995,

Including Draft Amendment 1: Certificate Extensions

(Version 3 Certificate)

[XML Recommendation for Namespaces in XML, World Wide Web

Namespace] Consortium, 14 January 1999, "http://www.w3.org/TR/REC-

xml-names"

[XML] Extensible Mark Up Language. A W3C recommendation. See

http://www.w3.org/TR/1998/REC-xml-19980210 for the 10

February 1998 version.

16. Author's Address

The author of this document is:

David Burdett

Commerce One

4440 Rosewood Drive, Bldg 4

Pleasanton

California 94588

USA

Phone: +1 (925) 520 4422

EMail: david.burdett@commerceone.com

The author of this document particularly wants to thank Mondex

International Limited (www.mondex.com) for the tremendous support

provided in the formative stages of the development of this

specification.

In addition the author appreciates the following contributors to this

protocol (in alphabetic order of company) without which it could not

have been developed.

- Phillip Mullarkey, British Telecom plc

- Andrew Marchewka, Canadian Imperial Bank of Commerce

- Brian Boesch, CyberCash Inc.

- Tom Arnold, CyberSource

- Terry Allen, Commerce One (formally Veo Systems)

- Richard Brown, GlobeSet Inc.

- Peter Chang, Hewlett Packard

- Masaaki Hiroya, Hitachi Ltd

- Yoshiaki Kawatsura, Hitachi Ltd

- Mark Linehan, International Business Machines

- Jonathan Sowler, JCP Computer Services Ltd

- John Wankmueller, MasterCard International

- Steve Fabes, Mondex International Ltd

- Donald Eastlake 3rd, Motorola Inc (formerly International

Business Machines Inc)

- Surendra Reddy, Oracle Corporation

- Akihiro Nakano, Plat Home, Inc. (ex Hitachi Ltd)

- Chris Smith, Royal Bank of Canada

- Hans Bernhard-Beykirch, SIZ (IT Development and Coordination

Centre of the German Savings Banks Organisation)

- W. Reid Carlisle, Spyrus (ex Citibank Universal Card Services,

formally AT&T Universal Card Services)

- Efrem Lipkin, Sun Microsystems

- Tony Lewis, Visa International

The author would also like to thank the following organisations for

their support:

- Amino Communications

- DigiCash

- Fujitsu

- General Information Systems

- Globe Id Software

- Hyperion

- InterTrader

- Nobil I T Corp

- Mercantec

- Netscape

- Nippon Telegraph and Telephone Corporation

- Oracle Corporation

- Smart Card Integrations Ltd.

- Spyrus

- Verifone

- Unisource nv

- Wells Fargo Bank

17. Full Copyright Statement

This document and translations of it may be copied and furnished to

others, and derivative works that comment on or otherwise explain it

or assist in its implementation may be prepared, copied, published

and distributed, in whole or in part, without restriction of any

kind, provided that the above copyright notice and this paragraph are

included on all such copies and derivative works. However, this

document itself may not be modified in any way, such as by removing

the copyright notice or references to the Internet Society or other

Internet organizations, except as needed for the purpose of

developing Internet standards in which case the procedures for

copyrights defined in the Internet Standards process must be

followed, or as required to translate it into languages other than

English.

The limited permissions granted above are perpetual and will not be

revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an

"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFCEditor function is currently provided by the

Internet Society.