Subject: Tentative schedule of TRADE WG in Oslo
From: "Donald E. Eastlake 3rd" <[email-masked]>
To: [email-masked]
Date: Mon, 31 May 1999 12:08:31 -0400

Date:  Fri, 28 May 1999 14:53:54 -0400
Subject:  45th IETF-OSLO, NORWAY: TRADE
In-Reply-To:  <[email-masked]>

TRADE is tentatively scheduled as follows:

	Wednesday, July 14 at 1300-1500
		other groups scheduled at that time: ipfc, manet,
pkix, sigtran, mboned

...

Thanks,
Marcia
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Date: Mon, 31 May 1999 22:26:13 +0900
To: David Burdett <[email-masked]>,  Ietf Trade WG <[email-masked]>
From: Masaaki Hiroya <[email-masked]>
Subject: RE: Error Handling
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I have an addtional comment on the last mail I sent about
transient business error handling. 

Transient business errors may occur during PayExch message processing
after PayReq messages are processed normally: for example,

In SET, AuthReq messages are sent to the SET payment gateway by the SET
merchant server connected to the IOTP Payment Handler server after 
the Payment Handler receives PReq messages included in PayExch 
messages from the Consumer.

If an AuthRes message with AuthCode=Declined is returned as a response
from the SET payment gateway, the SET payment bridge may return a 
business error to the IOTP Payment Handler.

Therefore, I think it is necessary to describe which message the IOTP 
client should send to the server and which messages should not stored
by the server, depending on the completion code.

The IOTP client should send the new message defined below or abort
the transaction when business errors occur.

For example,
Offer Exchange
"AuthError": AuthResp message

Payment Exchange
"BrandNotSupp" : PayReq message
"CurrNotSupp" : PayReq message
"AuthError" : PayReq message
"InsuffFunds" : PayReq message
"InstrumentBrandInvalid" : PayReq message
"InstNotValid" : PayReq message
"BadInstrument" : PayReq message

The IOTP servers should not store the following messages and
the new messages can be processed as if they had never been received
before when business transient errors occur.

For example,
Offer Exchange Phase
"AuthError": received AuthResp message

Payment Exchange Phase
"BrandNotSupp" : received PayReq and PayExch messages
"CurrNotSupp" : received PayReq and PayExch messages
"AuthError" : received PayReq and PayExch messages
"InsuffFunds" : received PayReq and PayExch messages
"InstrumentBrandInvalid" : receivedPayReq and PayExch messages
"InstNotValid" : received PayReq and PayExch messages
"BadInstrument" : received PayReq and PayExch messages

Any comments?

If I misunderstand the specifications about transient 
business errors, please let me know.

Massaki

At 02:45 99/05/28 +0900, Masaaki Hiroya wrote:
> 
> I have additional questions regarding transient business errors.
> 
> In 4.4.1.9 of the IOTP specification and your previous mail,
> >"If any of the previous steps resulted in an error being detected and an
> > Error Component being created then generate an Error Block (step 9)
> > containing the Error Components that describe the error(s).
> > 
> > Unless the error is a "Transient Error", the Error Component(s) and the
> > previous Request or Exchange block that caused the Error Components to be
> > generated should be stored so that it can be reused if the action request
> > is
> > received again (step 6a).
> > 
> > "Transient Errors" are not stored so that if the original Request or
> > Exchange Block is received again, then it can be processed as if it had
> > never been received before."
> 
> The above sentences seem descriptions about how to handle technical errors,
> but is the last sentence applicable to the transient business errors? 
> 
> If so, do the transient (payment) business errors occur only while the 
> server entities process received PayReq messages but not received PayExch 
> messages?
> 
> In this case, when the server entities receive PayExch messages, PayReq
> messages should have been processed normally, so I think that the server
> entities reject new PayReq messages including new payment brands and 
> protocols selected by the Consumers.
> 
> Otherwise, is it allowed to receive new PayReq messages even after 
> processing original PayReq messages normally and sending back
> PayExch messages to the client? 
> If so, the business errors may occur during processing PayExch messages.
> 
> In this case, it is necessary to define which message should be send
> by the client and be waited for by the server depending on each completion
> code when a transient business error occurs.  For example,
> if the "insufficient funds" business error occurs, the Consumer client
> should send a new PayReq message including a new payment brand and 
> protocol in it or a cancel message to the Payment Handler server, and
> the Payment Handler server should wait for them. 
> 
> I think it is better to add how to handle business errors to Fig.10
> and Fig.11 in the IOTP specification, which show Server Role Processing
> Sequence and Client Role Processing Sequence respectively.
> 
> I would like to make clear the differences between transient technical 
> errors and transient business errors in detail regarding the Server
> Role bahavior and the Client Role behavior.
> 
> Thank you in advance
> Masaaki
> 
> 
> At 20:43 99/5/26 +0100, David Burdett wrote:
> > In my last email on Error Handling it said in the description of Payment
> > Completion codes that:
> > 
> > > If the Payment is Brand Independent, then recovery may be possible for
> > > some values of the Completion Code, by the Consumer selecting a differ
ent
> > > payment brand. Note that this might involve a different Payment Handler.
> > > The codes to which this applies are: BrandNotSupp, PaymtCancelled,
> > > InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument and
> > > Unspecified.
> > > 
> > 	Recovery from Payments associated with Brand Dependent purchases is
> > not possible, since the Offer is dependent on a the entries selected from
> > the Brand List. A changed selection will invalidate the Offer Response.
> > 
> > This is not quite correct. It should have said ...
> > 
> > > If the Payment is Brand Independent, then recovery may be possible for
> > > some values of the Completion Code, by the Consumer selecting either a
> > > different payment brand or a different payment instrument for the same
> > > brand. Note that this might involve a different Payment Handler. The c
odes
> > > to which this applies are: BrandNotSupp, PaymtCancelled, InsuffFunds,
> > > InstBrandInvalid, InstNotValid, BadInstrument and Unspecified.
> > > 
> > 	Recovery from Payments associated with Brand Dependent purchases is
> > only possible, if the Brand Selection component sent by the Merchant to 
the
> > Consumer does not change. In practice this means that the same Brand,
> > Protocol Amount and PayProtocol elements must be used. All that can change
> > is the Payment Instrument. Any other change will invalidate the Merchant's
> > Offer as a changed selection will invalidate the Offer Response.
> > 
> > > ----------
> > > From: 	David Burdett[SMTP:[email-masked]]
> > > Sent: 	25 May 1999 14:05
> > > To: 	Ietf Trade WG; [email-masked]
> > > Subject: 	RE: Error Handling
> > > 
> > > Most of Masaaki's questions are to do with "Transient Errors" and how to
> > > handle them. I think that Transient Errors can be caused by either
> > > business
> > > or technical reasons. For example:
> > > *	if a server that is handling a payment (e.g. a SET server, or a SCCD
> > > server) is busy, even if the IOTP server is not, then the valid response
> > > might be to tell the consumer to retry re-send exactly the same message
> > > some
> > > time later. This is a transient technical error.
> > > *	on the other hand if the payment instrument is not usable, for
> > > example there are insufficient funds on a credit card, then the consumer
> > > needs to select a different payment instrument. This is a transient
> > > business
> > > error since the transaction can continue with a different payment
> > > instrument.
> > > 
> > > This is consistent with the current defintions of the two types of err
or.
> > > *	"technical errors" which are independent of the meaning of the IOTP
> > > Message, and
> > > *	"business errors" which indicate that there is a problem specific to
> > > the process (e.g. payment or delivery) which is being carried out
> > > 
> > > Therefore I think that these two types of "transient" error need handl
ing
> > > differently with:
> > > *	"transient technical errors" being handled by sending an Error
> > > Component to the the other Trading Role which results in the
> > > re-transmission
> > > of the original message at some slightly later point in time, and 
> > > *	"transient business errors" where a "response" message is sent which
> > > allows the other role, e.g. a Consumer, to retry with, for example,
> > > another
> > > payment instrument
> > > 
> > > Below are detailed changes to the IOTP spec, and responses to Masaaki's
> > > individual questions.
> > > 
> > > David
> > > 
> > > CHANGES TO THE SPEC
> > > 
> > > NEW SECTION - TRANSIENT TECHNICAL ERRORS
> > > Add a new section on "Transient Technical Errors" after the section
> > > 4.3.3.2
> > > on "Block and Component Consistency Checks" that says:
> > > 
> > > "If the block passes the "Block Level Attribute and Element Checks" and
> > > the
> > > "Block and Component Consistency Checks" then it is processed either by
> > > the
> > > IOTP Aware application or perhaps by some "back-end" system such as a
> > > payment server. During this processing some temporary failure may occur
> > > that
> > > can potentially be recovered by the other trading role re-transmitting
, at
> > > some slightly later time, the original message that they sent. 
> > > 
> > > In this case the other role is informed of the Transient Error by send
ing
> > > them an Error Component (see section 6.19) with the Severity Attribute
 set
> > > to TransientError and the MinRetrySecs attribute set to some value
> > > suitable
> > > for the Transport Mechanism being used (see appropriate Transport
> > > Supplement).
> > > 
> > > Note that transient technical errors can be sent by any of the Trading
> > > Roles
> > > involved in transaction."
> > > 
> > > UPDATED SECTION - BLOCK BUSINESS ERRORS
> > > Clarify the section on Block Business Errors (section 4.3.3.3) to read
 ...
> > > 
> > > "If a business error occurs in a process such as a Payment or a Delive
ry,
> > > then the appropriate type of response block is returned containing a
> > > Status
> > > Component (see section 6.14) with the ProcessState attribute set to Fa
iled
> > > and the CompletionCode indicating the nature of the problem.
> > > 
> > > Some business errors may be "transient" in that the Consumer role may be
> > > able to recover and complete the transaction in some other way. For
> > > example
> > > if the Credit Card that a consumer provided had insufficient funds for a
> > > purchase, then the Consumer may recover by using a different credit ca
rd.
> > > 
> > > Recovery from "transient" business errors is dependent on the
> > > CompletionCode. See the definition of the Status Component for what is
> > > possible.
> > > 
> > > Note that no Error Component or Error Block is generated for business
> > > errors."
> > > 
> > > REVISED COMPLETION CODES FOR STATUS COMPONENT
> > > Change the defintion of the CompletionCode attribute in the Status
> > > component
> > > to read ...
> > > 
> > > 	"Indicates how the process completed. Valid values for the
> > > CompletionCode are given below together with the conditions when it must
> > > be
> > > present and indications on when recovery from failures are possible."
> > > 
> > > Update sections 6.14.1 to 6.14.4 to indicate where recovery from trans
ient
> > > business errors are possible, as follows:
> > > 
> > > 6.14.1 Offer Completion Codes
> > > The Completion Code is only required if the ProcessState attribute is 
set
> > > to
> > > Failed. The following table contains the valid values for the
> > > CompletionCode
> > > that may be used and indicates whether or not recovery might be possib
le.
> > > It
> > > is recommended that the StatusDesc attribute is used to provide further
> > > explanation where appropriate.
> > > *	Value		Description	
> > > *	"AuthError"	Authentication Error. The check of the
> > > Authentication Response which was carried out has failed. Recovery may
 be
> > > possible by the Consumer re-submitting a new Authentication Response B
lock
> > > with corrected information.	
> > > *	"ConsCancelled"	Consumer Cancelled. The Consumer decides to cancel
> > > the transaction for some reason. This code is only valid in a Status
> > > Component contained in a Cancel Block or an Inquiry Response Block. No
> > > recovery possible.	
> > > *	"MerchCancelled"	Offer Cancelled. The Merchant declines to
> > > generate an offer for some reason and cancels the transaction. This code
> > > is
> > > only valid in a Status Component contained in a Cancel Block or an Inq
uiry
> > > Response Block. No recovery possible.	
> > > *	"Unspecified"	Unspecified error. There is some unknown problem or
> > > error which does not fall into one of the other CompletionCodes. No
> > > recovery
> > > possible	
> > > 
> > > 6.14.2 Payment Completion Codes
> > > The CompletionCode is only required if the ProcessState attribute is set
> > > to
> > > Failed. The following table contains the valid values for the
> > > CompletionCode
> > > that may be used and indicates where recovery may be possible. It is
> > > recommended that the StatusDesc attribute is used by individual payment
> > > schemes to provide further explanation where appropriate.
> > > *	Value		Description	
> > > *	"BrandNotSupp"	Brand not supported. The payment brand is not
> > > supported by the Payment Handler. See below for recovery options.	
> > > *	"CurrNotSupp"	Currency not supported. The currency in which the
> > > payment is to be made is not supported by either the Payment Instrumen
t or
> > > the Payment Handler. If the payment is Brand Independent, then the
> > > Consumer
> > > may recover by selecting a different currency, if available, or a
> > > different
> > > brand. Note that this may involve a different Payment Handler.	
> > > *	"ConsCancelled"	Consumer Cancelled. The Consumer decides to cancel
> > > the payment for some reason. This code is only valid in a Status Compo
nent
> > > contained in a Cancel Block or an Inquiry Response Block. Recovery is 
not
> > > possible.	
> > > *	"PaymtCancelled"	Payment Cancelled. The Payment Handler
> > > declines to complete the payment for some reason and cancels the
> > > transaction. This code is only valid in a Status Component contained i
n a
> > > Cancel Block or an Inquiry Response Block. See below for recovery opti
ons.
> > > 
> > > *	"AuthError"	Authentication Error. The Payment Scheme specific
> > > authentication check which was carried out has failed. Recovery may be
> > > possible. See the payment scheme supplement to determine what is allow
ed.
> > > 
> > > *	"InsuffFunds"	Insufficient funds. There are insufficient funds
> > > available for the payment to be made. See below for recovery options.	
> > > *	"InstBrandInvalid"	Payment Instrument not valid for Brand. A
> > > Payment Instrument is being used which does not correspond with the Br
and
> > > selected. For example a Visa credit card is being used when MasterCard
 was
> > > selected as the Brand. See below for recovery options.	
> > > *	"InstNotValid"	Payment instrument not valid for trade. The Payment
> > > Instrument cannot be used for the proposed type of trade, for some rea
son.
> > > See below for recovery options.	
> > > *	"BadInstrument"	Bad instrument. There is a problem with the Payment
> > > Instrument being used which means that it is unable to be used for the
> > > payment. See below for recovery options.	
> > > *	"Unspecified"	Unspecified error. There is some unknown problem or
> > > error which does not fall into one of the other CompletionCodes. The
> > > StatusDesc attribute should provide the explanation of the cause. See
> > > below
> > > for recovery options.	
> > > 
> > > If the Payment is Brand Independent, then recovery may be possible for
> > > some
> > > values of the Completion Code, by the Consumer selecting a different
> > > payment
> > > brand. Note that this might involve a different Payment Handler. The c
odes
> > > to which this applies are: BrandNotSupp, PaymtCancelled, InsuffFunds,
> > > InstBrandInvalid, InstNotValid, BadInstrument and Unspecified.
> > > 
> > > Recovery from Payments associated with Brand Dependent purchases is not
> > > possible, since the Offer is dependent on a the entries selected from 
the
> > > Brand List. A changed selection will invalidate the Offer Response.
> > > 
> > > 6.14.3 Delivery Completion Codes
> > > The following table contains the valid values for the CompletionCode
> > > attribute for a Delivery. It is recommended that the StatusDesc attrib
ute
> > > is
> > > used to provide further explanation where appropriate.
> > > *	Value		Description	
> > > *	"BackOrdered"	Back Ordered. The goods to be delivered are on order
> > > but they have not yet been received. Shipping will be arranged when they
> > > are
> > > received. This is only valid if ProcessState is CompletedOk. Recovery is
> > > not
> > > possible.	
> > > *	"PermNotAvail"	Permanently Not Available. The goods are permanently
> > > unavailable and cannot be re-ordered. This is only valid if ProcessState
> > > is
> > > Failed. Recovery is not possible.	
> > > *	"TempNotAvail"	Temporarily Not Available. The goods are temporarily
> > > unavailable and may become available if they can be ordered. This is o
nly
> > > valid if ProcessState is CompletedOk. Recovery is not possible.	
> > > *	"ShipPending"	Shipping Pending. The goods are available and are
> > > scheduled for shipping but they have not yet been shipped. This is only
> > > valid if ProcessState is CompletedOk. Recovery is not possible.	
> > > *	"Shipped"	Goods Shipped. The goods have been shipped.
> > > Confirmation of delivery is awaited. This is only valid if ProcessStat
e is
> > > CompletedOk. Recovery is not possible.	
> > > *	"ShippedNoConf"	Shipped - No Delivery Confirmation. The goods have
> > > been shipped but it is not possible to confirm delivery of the goods. 
This
> > > is only valid if ProcessState is CompletedOk. Recovery is not possible.
> > > 
> > > *	"ConsCancelled"	Consumer Cancelled. The Consumer decides to cancel
> > > the delivery for some reason. This code is only valid in a Status
> > > Component
> > > contained in a Cancel Block or an Inquiry Response Block. Recovery is 
not
> > > possible.	
> > > *	"DelivCancelled"	Delivery Cancelled. The Delivery Handler
> > > declines to complete the Delivery for some reason and cancels the
> > > transaction. This code is only valid in a Status Component contained i
n a
> > > Cancel Block or an Inquiry Response Block. 	
> > > *	"Confirmed"	Confirmed. All goods have been delivered and
> > > confirmation of their delivery has been received. This is only valid if
> > > ProcessState is CompletedOk. 	
> > > *	"Unspecified"	Unspecified error. There is some unknown problem or
> > > error which does not fall into one of the other CompletionCodes. The
> > > StatusDesc attribute should provide the explanation of the cause. Reco
very
> > > is not possible.	
> > > 
> > > 	[Note]	Recovery from failed, or partially completed deliveries is
> > > not possible. The Consumer should use the Transaction Status Inquiry
> > > Transaction (see section 9.2.1) to determine up-to-date information on
 the
> > > current state.
> > > 	[Note End]	
> > > 
> > > 6.14.4 Authentication Completion Codes
> > > The Completion Code is only required if the ProcessState attribute is 
set
> > > to
> > > Failed. The following table contains the valid values for the
> > > CompletionCode
> > > that may be used. It is recommended that the StatusDesc attribute is u
sed
> > > to
> > > provide further explanation where appropriate.
> > > *	Value	Description	
> > > *	"AutEeCancel"	Authenticatee Cancel. The organisation being
> > > authenticated declines to be authenticated for some reason. This could
 be,
> > > for example because the signature on an Authentication Request was inv
alid
> > > or the Authenticator was not known or acceptable to the Authenticatee.
> > > Recovery is not possible.	
> > > *	"AutOrCancel"	Authenticator Cancel. The organisation requesting
> > > authentication declines to validate the Authentication Response received
> > > for
> > > some reason and cancels the transaction. Recovery is not possible.	
> > > *	"NoAuthData"	Authentication Request Not Available. The
> > > Authenticatee does not have the data that must be provided so that they
> > > may
> > > be successfully authenticated. For example a password may have been
> > > forgotten, the Authenticatee has not yet become a member, or a smart c
ard
> > > token is not present. Recovery is not possible	
> > > *	"AuthFailed"	Authentication Failed. The Authenticator checked the
> > > Authentication Response but the authentication failed for some reason.
 For
> > > example a password may have been incorrect. Recovery may be possible by
> > > the
> > > Authenticatee re-sending a revised Authentication Response with correc
ted
> > > data.	
> > > *	"TradRolesIncon"	Trading Roles Inconsistent. The Trading
> > > Roles contained within the TradingRoleList attribute of the Authentica
tion
> > > Request Component are inconsistent with the Trading Role which the
> > > Authenticatee is taking in the IOTP Transaction or is able to take.
> > > Examples
> > > of inconsistencies include: asking a PaymentHandler for DeliveryHandler
> > > information asking a Consumer for Merchant information Recovery may be
> > > possible by the Authenticator re-sending a revised Authentication Requ
est
> > > Block with corrected information.	
> > > *	"Unspecified"	Unspecified error. There is some unknown problem or
> > > error which does not fall into one of the other CompletionCodes. Recov
ery
> > > is
> > > not possible.	
> > > 
> > > Comments on questions below ...
> > > > ----------
> > > > From: 	Masaaki Hiroya[SMTP:[email-masked]]
> > > > Reply To: 	[email-masked]
> > > > Sent: 	23 May 1999 00:59
> > > > To: 	[email-masked]
> > > > Subject: 	Error Handling
> > > > 
> > > > David and Werner
> > > > 
> > > > I have some questions about error handling.
> > > > 
> > > > [Question 1]
> > > > The business error handling described in IOTP Payment API Supplement
> > > > v1.0.1a
> > > > is inconsistent with the one described in IOTP specification v1.0-03.
> > > > 
> > > > In 4.3.3.3 Block Business Errors in the IOTP specification, there is
 a 
> > > > description as follows:
> > > > "If a business error occurs in a process such as a Payment or a
> > > >  Delivery, then the appropriate type of response block is returned. 
The
> > > >  Status Component (see section 6.14) within that response block
> > > >  indicates the error and its severity. No Error Component or Error B
lock
> > > >  is generated for business errors."
> > > > 
> > > > In 8.5.2 Intermediate Failures in the Payment API Supplement, there 
is a
> > > > description as follows:
> > > > "Transient Error: Failures, that might be resolved by the retransmis
sion
> > > > of 
> > > > the appropriate IOTP message, belong to this class. 
> > > > ......
> > > > The behavior of the IOTP Application Core and IOTP Payment Bridge does
> > > not
> > > > depend on any further classification of this failure
> > > > (technical/business)."
> > > > 
> > > > In Fig.31 in 8.5.2, an business error with severity "TransientError"
 is 
> > > > notified from the Payment Handler to the Consumer by using an Error
> > > > message.
> > > > 
> > > > Which should be used, ErrorBlk and Error Component or PayRespBlk and
> > > > Status
> > > > Component in the case of business errors with "TransientError" sever
ity?
> > > >  
> > > > If the Status Component should be used in any business error, it is
> > > > necessary
> > > > to add a "Severity" attribute to the Status Component, since there i
s no
> > > 
> > > > "Severity" attribute in the Status Component defined in 6.14 of the 
IOTP
> > > 
> > > > specification.
> > > ## Should be answered by earlier comments ##
> > > 
> > > > [Question 2]
> > > > This is a confirmation rather than a question.
> > > > After the Consumer receives the PayResp message with Severity "Trans
ient
> > > > Error", the Consumer sends the retrying PayExch message in order to
> > > > continue
> > > > the transaction, doesn't it?
> > > > I think the answer is "yes" since there is the Server Role descripti
on 
> > > > in 4.4.1.9 of the IOTP specification as follows:
> > > >   "Transient Errors" are not stored so that if the original Response
> > > >   Block is received again, then it can be processed as if it had never
> > > >   been received before.
> > > > (In the above sentence, I think that "the original Response Block"
> > > should 
> > > >  be "the original Request Block" because the Server Role receives
> > > request
> > > >  blocks.)
> > > > ## Also answered by earlier comments and correct 4.4.1.9 to read ...
> > > "If any of the previous steps resulted in an error being detected and an
> > > Error Component being created then generate an Error Block (step 9)
> > > containing the Error Components that describe the error(s).
> > > 
> > > Unless the error is a "Transient Error", the Error Component(s) and the
> > > previous Request or Exchange block that caused the Error Components to
 be
> > > generated should be stored so that it can be reused if the action requ
est
> > > is
> > > received again (step 6a).
> > > 
> > > "Transient Errors" are not stored so that if the original Request or
> > > Exchange Block is received again, then it can be processed as if it had
> > > never been received before."
> > > >  ##
> > > > 
> > > > [Question 3]
> > > > Additional Confirmation.  It is allowed to set different values from
 the
> > > > original request message to the retrying request message in the case
 of
> > > > business errors with "TransientError" severity, isn't it?
> > > > I think the answer should be "yes" since in the case of "Insufficient
> > > > Fund"
> > > > the Consumer may replace the e-cash card and then retry the transact
ion
> > > > so PaySchemeData in the original may be different from the one in the
> > > > retrying message.
> > > > 
> > > > The reason why I am confused is there is a description in 4.4.2.8 of
> > > > IOTP specification as follows:
> > > >   "Transient errors may be used to provide a manual or automatic
> > > >   resending (step 8b) of a block previously stored or alternatively 
may
> > > >   result in transaction cancellation."
> > > ## Answered by earlier comments ##
> > > 
> > > > [Question 4]
> > > > Some errors are not easy to classify as technical errors or business
> > > > errors.
> > > > If the payment server such as the SET Merchant connected to IOTP Pay
ment
> > > > Handler server through its payment bridge has an internel processing
> > > > error,
> > > > is it a technical error or a business error with an completion code of
> > > > "BadInstrument"?  If the SET Merchant server doesn't respond to the
> > > > request
> > > > from the payment bridge of the Payment Handler, is it a technical er
ror
> > > or
> > > > a business error with "BadInstrument" completion code?
> > > ## Answered by earlier comments ##
> > > 
> > > > [Question 5]
> > > > Accoring to the IOTP specification, PayReceipt Component is mandator
y in
> > > 
> > > > PayRespBlk and it is required to use PayRespBlk in the case of busin
ess 
> > > > errors, 
> > > > But I think most payment schemes doesn't generate payment receipts w
hen
> > > > errors
> > > > occur.  Taking it into consideration, the PayReceipt should be optio
nal
> > > in
> > > > the 
> > > > PayRespBlk.  What do you think about it?
> > > ## I agree, Pay Receipt Component is only required if the Status compo
nent
> > > is "Completed OK".
> > > 
> > > The DTD is changed from ...
> > > 
> > > <!ELEMENT PayRespBlk (Status, PayReceipt, PaySchemeData?,
> > >      PaymentNote?, TradingRoleData*) >
> > > 
> > > ... to ...
> > > 
> > > <!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,
> > >      PaymentNote?, TradingRoleData*) >
> > > 
> > > ... and the description of the PayReceipt in the Pay Response Block is
> > > changed to ...
> > > 
> > > 	"Contains payment scheme specific data which can be used to verify
> > > the payment occurred. See section 7.10 Payment Receipt Component. It m
ust
> > > be
> > > present if the ProcessState attribute of the Status Component is set to
> > > CompletedOk. PayReceipt is optional for other values as specified by the
> > > appropriate Payment Scheme supplement."
> > > 
> > > 
> > > > Regards
> > > > Masaaki
> > > > -----
> > > > Masaaki Hiroya
> > > > Systems Development Laboratory
> > > > Hitachi, Ltd.
> > > > tel: +81-44-959-0874
> > > > fax: +81-44-959-0856
> > > > email: [email-masked]
> > > > --------------------------------------------------------------------
---
> > > > Message addressed to: [email-masked]
> > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
 the
> > > > body to: [email-masked]
> > > > 
> > > 
> > > **********************************************************************
****
> > > ********************
> > > 
> > > This Email and any attached files are confidential and may also be
> > > privileged. 
> > > If you are not the intended recipient, please notify the postmaster us
ing
> > > email 
> > > address [email-masked] or call +44 171 557 5000 and ask for the 
> > > IT Helpdesk.  You should not copy this email and any attached files, use
> > > them 
> > > for any purpose or disclose the contents to any other person; all copies
> > > of the 
> > > Email and associated files in your possession should be destroyed.
> > > 
> > > Mondex International Limited
> > > 47-53 Cannon Street
> > > London EC4M 5SQ
> > > United Kingdom
> > > Registered No: 3122085, England
> > > 
> > > Phone:          +44 171 557 5000
> > > Fax:            +44 171 557 5200
> > > Email:          [email-masked]
> > > WebSite:        http://www.mondexinternational.com
> > > 
> > > **********************************************************************
****
> > > *******************
> > > -----------------------------------------------------------------------
> > > Message addressed to: [email-masked]
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > > body to: [email-masked]
> > > 
> > 
> > ************************************************************************
****
> > ******************
> > 
> > This Email and any attached files are confidential and may also be 
> > privileged. 
> > If you are not the intended recipient, please notify the postmaster usin
g email 
> > address [email-masked] or call +44 171 557 5000 and ask for the 
> > IT Helpdesk.  You should not copy this email and any attached files, use
 them 
> > for any purpose or disclose the contents to any other person; all copies
 of the 
> > Email and associated files in your possession should be destroyed.
> > 
> > Mondex International Limited
> > 47-53 Cannon Street
> > London EC4M 5SQ
> > United Kingdom
> > Registered No: 3122085, England
> > 
> > Phone:          +44 171 557 5000
> > Fax:            +44 171 557 5200
> > Email:          [email-masked]
> > WebSite:        http://www.mondexinternational.com
> > 
> > ************************************************************************
****
> > *****************
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> > 
> -----
> Masaaki Hiroya
> Systems Development Laboratory
> Hitachi, Ltd.
> tel: +81-44-959-0874
> fax: +81-44-959-0856
> email: [email-masked]
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
>  
-----
Masaaki Hiroya
Systems Development Laboratory
Hitachi, Ltd.
email: [email-masked]
tel: +81-44-966-9111(ext.3552)
fax: +81-44-966-1796
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: OECD PDA Tag
Date: Sat, 29 May 1999 18:55:27 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The summary of the OECD Professional Data Assessment Tag meeting held in
Washington in April is available on the public side of the OECD web site at
...

http://appli1.oecd.org/daf/TaxandEl.nsf/ae6ab2df50d9aa54c12567460045d5c8/c53
6ae18ca96227ec125677f0058ce98?OpenDocument

... although you might find it easier to get there by going to the forum
home page first at ...

	http://appli1.oecd.org/daf/taxandel.nsf

David
> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Reply-To: [email-masked]
Date: Fri, 28 May 1999 02:45:37 +0900
To: David Burdett <[email-masked]>,  Ietf Trade WG <[email-masked]>
From: Masaaki Hiroya <[email-masked]>
Subject: RE: Error Handling
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I have additional questions regarding transient business errors.

In 4.4.1.9 of the IOTP specification and your previous mail,
>"If any of the previous steps resulted in an error being detected and an
> Error Component being created then generate an Error Block (step 9)
> containing the Error Components that describe the error(s).
> 
> Unless the error is a "Transient Error", the Error Component(s) and the
> previous Request or Exchange block that caused the Error Components to be
> generated should be stored so that it can be reused if the action request
> is
> received again (step 6a).
> 
> "Transient Errors" are not stored so that if the original Request or
> Exchange Block is received again, then it can be processed as if it had
> never been received before."

The above sentences seem descriptions about how to handle technical errors,
but is the last sentence applicable to the transient business errors? 

If so, do the transient (payment) business errors occur only while the 
server entities process received PayReq messages but not received PayExch 
messages?

In this case, when the server entities receive PayExch messages, PayReq
messages should have been processed normally, so I think that the server
entities reject new PayReq messages including new payment brands and 
protocols selected by the Consumers.

Otherwise, is it allowed to receive new PayReq messages even after 
processing original PayReq messages normally and sending back
PayExch messages to the client? 
If so, the business errors may occur during processing PayExch messages.

In this case, it is necessary to define which message should be send
by the client and be waited for by the server depending on each completion
code when a transient business error occurs.  For example,
if the "insufficient funds" business error occurs, the Consumer client
should send a new PayReq message including a new payment brand and 
protocol in it or a cancel message to the Payment Handler server, and
the Payment Handler server should wait for them. 

I think it is better to add how to handle business errors to Fig.10
and Fig.11 in the IOTP specification, which show Server Role Processing
Sequence and Client Role Processing Sequence respectively.

I would like to make clear the differences between transient technical 
errors and transient business errors in detail regarding the Server
Role bahavior and the Client Role behavior.

Thank you in advance
Masaaki

At 20:43 99/5/26 +0100, David Burdett wrote:
> In my last email on Error Handling it said in the description of Payment
> Completion codes that:
> 
> > If the Payment is Brand Independent, then recovery may be possible for
> > some values of the Completion Code, by the Consumer selecting a different
> > payment brand. Note that this might involve a different Payment Handler.
> > The codes to which this applies are: BrandNotSupp, PaymtCancelled,
> > InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument and
> > Unspecified.
> > 
> 	Recovery from Payments associated with Brand Dependent purchases is
> not possible, since the Offer is dependent on a the entries selected from
> the Brand List. A changed selection will invalidate the Offer Response.
> 
> This is not quite correct. It should have said ...
> 
> > If the Payment is Brand Independent, then recovery may be possible for
> > some values of the Completion Code, by the Consumer selecting either a
> > different payment brand or a different payment instrument for the same
> > brand. Note that this might involve a different Payment Handler. The codes
> > to which this applies are: BrandNotSupp, PaymtCancelled, InsuffFunds,
> > InstBrandInvalid, InstNotValid, BadInstrument and Unspecified.
> > 
> 	Recovery from Payments associated with Brand Dependent purchases is
> only possible, if the Brand Selection component sent by the Merchant to the
> Consumer does not change. In practice this means that the same Brand,
> Protocol Amount and PayProtocol elements must be used. All that can change
> is the Payment Instrument. Any other change will invalidate the Merchant's
> Offer as a changed selection will invalidate the Offer Response.
> 
> > ----------
> > From: 	David Burdett[SMTP:[email-masked]]
> > Sent: 	25 May 1999 14:05
> > To: 	Ietf Trade WG; [email-masked]
> > Subject: 	RE: Error Handling
> > 
> > Most of Masaaki's questions are to do with "Transient Errors" and how to
> > handle them. I think that Transient Errors can be caused by either
> > business
> > or technical reasons. For example:
> > *	if a server that is handling a payment (e.g. a SET server, or a SCCD
> > server) is busy, even if the IOTP server is not, then the valid response
> > might be to tell the consumer to retry re-send exactly the same message
> > some
> > time later. This is a transient technical error.
> > *	on the other hand if the payment instrument is not usable, for
> > example there are insufficient funds on a credit card, then the consumer
> > needs to select a different payment instrument. This is a transient
> > business
> > error since the transaction can continue with a different payment
> > instrument.
> > 
> > This is consistent with the current defintions of the two types of error.
> > *	"technical errors" which are independent of the meaning of the IOTP
> > Message, and
> > *	"business errors" which indicate that there is a problem specific to
> > the process (e.g. payment or delivery) which is being carried out
> > 
> > Therefore I think that these two types of "transient" error need handling
> > differently with:
> > *	"transient technical errors" being handled by sending an Error
> > Component to the the other Trading Role which results in the
> > re-transmission
> > of the original message at some slightly later point in time, and 
> > *	"transient business errors" where a "response" message is sent which
> > allows the other role, e.g. a Consumer, to retry with, for example,
> > another
> > payment instrument
> > 
> > Below are detailed changes to the IOTP spec, and responses to Masaaki's
> > individual questions.
> > 
> > David
> > 
> > CHANGES TO THE SPEC
> > 
> > NEW SECTION - TRANSIENT TECHNICAL ERRORS
> > Add a new section on "Transient Technical Errors" after the section
> > 4.3.3.2
> > on "Block and Component Consistency Checks" that says:
> > 
> > "If the block passes the "Block Level Attribute and Element Checks" and
> > the
> > "Block and Component Consistency Checks" then it is processed either by
> > the
> > IOTP Aware application or perhaps by some "back-end" system such as a
> > payment server. During this processing some temporary failure may occur
> > that
> > can potentially be recovered by the other trading role re-transmitting, at
> > some slightly later time, the original message that they sent. 
> > 
> > In this case the other role is informed of the Transient Error by sending
> > them an Error Component (see section 6.19) with the Severity Attribute set
> > to TransientError and the MinRetrySecs attribute set to some value
> > suitable
> > for the Transport Mechanism being used (see appropriate Transport
> > Supplement).
> > 
> > Note that transient technical errors can be sent by any of the Trading
> > Roles
> > involved in transaction."
> > 
> > UPDATED SECTION - BLOCK BUSINESS ERRORS
> > Clarify the section on Block Business Errors (section 4.3.3.3) to read ...
> > 
> > "If a business error occurs in a process such as a Payment or a Delivery,
> > then the appropriate type of response block is returned containing a
> > Status
> > Component (see section 6.14) with the ProcessState attribute set to Failed
> > and the CompletionCode indicating the nature of the problem.
> > 
> > Some business errors may be "transient" in that the Consumer role may be
> > able to recover and complete the transaction in some other way. For
> > example
> > if the Credit Card that a consumer provided had insufficient funds for a
> > purchase, then the Consumer may recover by using a different credit card.
> > 
> > Recovery from "transient" business errors is dependent on the
> > CompletionCode. See the definition of the Status Component for what is
> > possible.
> > 
> > Note that no Error Component or Error Block is generated for business
> > errors."
> > 
> > REVISED COMPLETION CODES FOR STATUS COMPONENT
> > Change the defintion of the CompletionCode attribute in the Status
> > component
> > to read ...
> > 
> > 	"Indicates how the process completed. Valid values for the
> > CompletionCode are given below together with the conditions when it must
> > be
> > present and indications on when recovery from failures are possible."
> > 
> > Update sections 6.14.1 to 6.14.4 to indicate where recovery from transient
> > business errors are possible, as follows:
> > 
> > 6.14.1 Offer Completion Codes
> > The Completion Code is only required if the ProcessState attribute is set
> > to
> > Failed. The following table contains the valid values for the
> > CompletionCode
> > that may be used and indicates whether or not recovery might be possible.
> > It
> > is recommended that the StatusDesc attribute is used to provide further
> > explanation where appropriate.
> > *	Value		Description	
> > *	"AuthError"	Authentication Error. The check of the
> > Authentication Response which was carried out has failed. Recovery may be
> > possible by the Consumer re-submitting a new Authentication Response Block
> > with corrected information.	
> > *	"ConsCancelled"	Consumer Cancelled. The Consumer decides to cancel
> > the transaction for some reason. This code is only valid in a Status
> > Component contained in a Cancel Block or an Inquiry Response Block. No
> > recovery possible.	
> > *	"MerchCancelled"	Offer Cancelled. The Merchant declines to
> > generate an offer for some reason and cancels the transaction. This code
> > is
> > only valid in a Status Component contained in a Cancel Block or an Inquiry
> > Response Block. No recovery possible.	
> > *	"Unspecified"	Unspecified error. There is some unknown problem or
> > error which does not fall into one of the other CompletionCodes. No
> > recovery
> > possible	
> > 
> > 6.14.2 Payment Completion Codes
> > The CompletionCode is only required if the ProcessState attribute is set
> > to
> > Failed. The following table contains the valid values for the
> > CompletionCode
> > that may be used and indicates where recovery may be possible. It is
> > recommended that the StatusDesc attribute is used by individual payment
> > schemes to provide further explanation where appropriate.
> > *	Value		Description	
> > *	"BrandNotSupp"	Brand not supported. The payment brand is not
> > supported by the Payment Handler. See below for recovery options.	
> > *	"CurrNotSupp"	Currency not supported. The currency in which the
> > payment is to be made is not supported by either the Payment Instrument or
> > the Payment Handler. If the payment is Brand Independent, then the
> > Consumer
> > may recover by selecting a different currency, if available, or a
> > different
> > brand. Note that this may involve a different Payment Handler.	
> > *	"ConsCancelled"	Consumer Cancelled. The Consumer decides to cancel
> > the payment for some reason. This code is only valid in a Status Component
> > contained in a Cancel Block or an Inquiry Response Block. Recovery is not
> > possible.	
> > *	"PaymtCancelled"	Payment Cancelled. The Payment Handler
> > declines to complete the payment for some reason and cancels the
> > transaction. This code is only valid in a Status Component contained in a
> > Cancel Block or an Inquiry Response Block. See below for recovery options.
> > 
> > *	"AuthError"	Authentication Error. The Payment Scheme specific
> > authentication check which was carried out has failed. Recovery may be
> > possible. See the payment scheme supplement to determine what is allowed.
> > 
> > *	"InsuffFunds"	Insufficient funds. There are insufficient funds
> > available for the payment to be made. See below for recovery options.	
> > *	"InstBrandInvalid"	Payment Instrument not valid for Brand. A
> > Payment Instrument is being used which does not correspond with the Brand
> > selected. For example a Visa credit card is being used when MasterCard was
> > selected as the Brand. See below for recovery options.	
> > *	"InstNotValid"	Payment instrument not valid for trade. The Payment
> > Instrument cannot be used for the proposed type of trade, for some reason.
> > See below for recovery options.	
> > *	"BadInstrument"	Bad instrument. There is a problem with the Payment
> > Instrument being used which means that it is unable to be used for the
> > payment. See below for recovery options.	
> > *	"Unspecified"	Unspecified error. There is some unknown problem or
> > error which does not fall into one of the other CompletionCodes. The
> > StatusDesc attribute should provide the explanation of the cause. See
> > below
> > for recovery options.	
> > 
> > If the Payment is Brand Independent, then recovery may be possible for
> > some
> > values of the Completion Code, by the Consumer selecting a different
> > payment
> > brand. Note that this might involve a different Payment Handler. The codes
> > to which this applies are: BrandNotSupp, PaymtCancelled, InsuffFunds,
> > InstBrandInvalid, InstNotValid, BadInstrument and Unspecified.
> > 
> > Recovery from Payments associated with Brand Dependent purchases is not
> > possible, since the Offer is dependent on a the entries selected from the
> > Brand List. A changed selection will invalidate the Offer Response.
> > 
> > 6.14.3 Delivery Completion Codes
> > The following table contains the valid values for the CompletionCode
> > attribute for a Delivery. It is recommended that the StatusDesc attribute
> > is
> > used to provide further explanation where appropriate.
> > *	Value		Description	
> > *	"BackOrdered"	Back Ordered. The goods to be delivered are on order
> > but they have not yet been received. Shipping will be arranged when they
> > are
> > received. This is only valid if ProcessState is CompletedOk. Recovery is
> > not
> > possible.	
> > *	"PermNotAvail"	Permanently Not Available. The goods are permanently
> > unavailable and cannot be re-ordered. This is only valid if ProcessState
> > is
> > Failed. Recovery is not possible.	
> > *	"TempNotAvail"	Temporarily Not Available. The goods are temporarily
> > unavailable and may become available if they can be ordered. This is only
> > valid if ProcessState is CompletedOk. Recovery is not possible.	
> > *	"ShipPending"	Shipping Pending. The goods are available and are
> > scheduled for shipping but they have not yet been shipped. This is only
> > valid if ProcessState is CompletedOk. Recovery is not possible.	
> > *	"Shipped"	Goods Shipped. The goods have been shipped.
> > Confirmation of delivery is awaited. This is only valid if ProcessState is
> > CompletedOk. Recovery is not possible.	
> > *	"ShippedNoConf"	Shipped - No Delivery Confirmation. The goods have
> > been shipped but it is not possible to confirm delivery of the goods. This
> > is only valid if ProcessState is CompletedOk. Recovery is not possible.
> > 
> > *	"ConsCancelled"	Consumer Cancelled. The Consumer decides to cancel
> > the delivery for some reason. This code is only valid in a Status
> > Component
> > contained in a Cancel Block or an Inquiry Response Block. Recovery is not
> > possible.	
> > *	"DelivCancelled"	Delivery Cancelled. The Delivery Handler
> > declines to complete the Delivery for some reason and cancels the
> > transaction. This code is only valid in a Status Component contained in a
> > Cancel Block or an Inquiry Response Block. 	
> > *	"Confirmed"	Confirmed. All goods have been delivered and
> > confirmation of their delivery has been received. This is only valid if
> > ProcessState is CompletedOk. 	
> > *	"Unspecified"	Unspecified error. There is some unknown problem or
> > error which does not fall into one of the other CompletionCodes. The
> > StatusDesc attribute should provide the explanation of the cause. Recovery
> > is not possible.	
> > 
> > 	[Note]	Recovery from failed, or partially completed deliveries is
> > not possible. The Consumer should use the Transaction Status Inquiry
> > Transaction (see section 9.2.1) to determine up-to-date information on the
> > current state.
> > 	[Note End]	
> > 
> > 6.14.4 Authentication Completion Codes
> > The Completion Code is only required if the ProcessState attribute is set
> > to
> > Failed. The following table contains the valid values for the
> > CompletionCode
> > that may be used. It is recommended that the StatusDesc attribute is used
> > to
> > provide further explanation where appropriate.
> > *	Value	Description	
> > *	"AutEeCancel"	Authenticatee Cancel. The organisation being
> > authenticated declines to be authenticated for some reason. This could be,
> > for example because the signature on an Authentication Request was invalid
> > or the Authenticator was not known or acceptable to the Authenticatee.
> > Recovery is not possible.	
> > *	"AutOrCancel"	Authenticator Cancel. The organisation requesting
> > authentication declines to validate the Authentication Response received
> > for
> > some reason and cancels the transaction. Recovery is not possible.	
> > *	"NoAuthData"	Authentication Request Not Available. The
> > Authenticatee does not have the data that must be provided so that they
> > may
> > be successfully authenticated. For example a password may have been
> > forgotten, the Authenticatee has not yet become a member, or a smart card
> > token is not present. Recovery is not possible	
> > *	"AuthFailed"	Authentication Failed. The Authenticator checked the
> > Authentication Response but the authentication failed for some reason. For
> > example a password may have been incorrect. Recovery may be possible by
> > the
> > Authenticatee re-sending a revised Authentication Response with corrected
> > data.	
> > *	"TradRolesIncon"	Trading Roles Inconsistent. The Trading
> > Roles contained within the TradingRoleList attribute of the Authentication
> > Request Component are inconsistent with the Trading Role which the
> > Authenticatee is taking in the IOTP Transaction or is able to take.
> > Examples
> > of inconsistencies include: asking a PaymentHandler for DeliveryHandler
> > information asking a Consumer for Merchant information Recovery may be
> > possible by the Authenticator re-sending a revised Authentication Request
> > Block with corrected information.	
> > *	"Unspecified"	Unspecified error. There is some unknown problem or
> > error which does not fall into one of the other CompletionCodes. Recovery
> > is
> > not possible.	
> > 
> > Comments on questions below ...
> > > ----------
> > > From: 	Masaaki Hiroya[SMTP:[email-masked]]
> > > Reply To: 	[email-masked]
> > > Sent: 	23 May 1999 00:59
> > > To: 	[email-masked]
> > > Subject: 	Error Handling
> > > 
> > > David and Werner
> > > 
> > > I have some questions about error handling.
> > > 
> > > [Question 1]
> > > The business error handling described in IOTP Payment API Supplement
> > > v1.0.1a
> > > is inconsistent with the one described in IOTP specification v1.0-03.
> > > 
> > > In 4.3.3.3 Block Business Errors in the IOTP specification, there is a 
> > > description as follows:
> > > "If a business error occurs in a process such as a Payment or a
> > >  Delivery, then the appropriate type of response block is returned. The
> > >  Status Component (see section 6.14) within that response block
> > >  indicates the error and its severity. No Error Component or Error Block
> > >  is generated for business errors."
> > > 
> > > In 8.5.2 Intermediate Failures in the Payment API Supplement, there is a
> > > description as follows:
> > > "Transient Error: Failures, that might be resolved by the retransmission
> > > of 
> > > the appropriate IOTP message, belong to this class. 
> > > ......
> > > The behavior of the IOTP Application Core and IOTP Payment Bridge does
> > not
> > > depend on any further classification of this failure
> > > (technical/business)."
> > > 
> > > In Fig.31 in 8.5.2, an business error with severity "TransientError" is 
> > > notified from the Payment Handler to the Consumer by using an Error
> > > message.
> > > 
> > > Which should be used, ErrorBlk and Error Component or PayRespBlk and
> > > Status
> > > Component in the case of business errors with "TransientError" severity?
> > >  
> > > If the Status Component should be used in any business error, it is
> > > necessary
> > > to add a "Severity" attribute to the Status Component, since there is no
> > 
> > > "Severity" attribute in the Status Component defined in 6.14 of the IOTP
> > 
> > > specification.
> > ## Should be answered by earlier comments ##
> > 
> > > [Question 2]
> > > This is a confirmation rather than a question.
> > > After the Consumer receives the PayResp message with Severity "Transient
> > > Error", the Consumer sends the retrying PayExch message in order to
> > > continue
> > > the transaction, doesn't it?
> > > I think the answer is "yes" since there is the Server Role description 
> > > in 4.4.1.9 of the IOTP specification as follows:
> > >   "Transient Errors" are not stored so that if the original Response
> > >   Block is received again, then it can be processed as if it had never
> > >   been received before.
> > > (In the above sentence, I think that "the original Response Block"
> > should 
> > >  be "the original Request Block" because the Server Role receives
> > request
> > >  blocks.)
> > > ## Also answered by earlier comments and correct 4.4.1.9 to read ...
> > "If any of the previous steps resulted in an error being detected and an
> > Error Component being created then generate an Error Block (step 9)
> > containing the Error Components that describe the error(s).
> > 
> > Unless the error is a "Transient Error", the Error Component(s) and the
> > previous Request or Exchange block that caused the Error Components to be
> > generated should be stored so that it can be reused if the action request
> > is
> > received again (step 6a).
> > 
> > "Transient Errors" are not stored so that if the original Request or
> > Exchange Block is received again, then it can be processed as if it had
> > never been received before."
> > >  ##
> > > 
> > > [Question 3]
> > > Additional Confirmation.  It is allowed to set different values from the
> > > original request message to the retrying request message in the case of
> > > business errors with "TransientError" severity, isn't it?
> > > I think the answer should be "yes" since in the case of "Insufficient
> > > Fund"
> > > the Consumer may replace the e-cash card and then retry the transaction
> > > so PaySchemeData in the original may be different from the one in the
> > > retrying message.
> > > 
> > > The reason why I am confused is there is a description in 4.4.2.8 of
> > > IOTP specification as follows:
> > >   "Transient errors may be used to provide a manual or automatic
> > >   resending (step 8b) of a block previously stored or alternatively may
> > >   result in transaction cancellation."
> > ## Answered by earlier comments ##
> > 
> > > [Question 4]
> > > Some errors are not easy to classify as technical errors or business
> > > errors.
> > > If the payment server such as the SET Merchant connected to IOTP Payment
> > > Handler server through its payment bridge has an internel processing
> > > error,
> > > is it a technical error or a business error with an completion code of
> > > "BadInstrument"?  If the SET Merchant server doesn't respond to the
> > > request
> > > from the payment bridge of the Payment Handler, is it a technical error
> > or
> > > a business error with "BadInstrument" completion code?
> > ## Answered by earlier comments ##
> > 
> > > [Question 5]
> > > Accoring to the IOTP specification, PayReceipt Component is mandatory in
> > 
> > > PayRespBlk and it is required to use PayRespBlk in the case of business 
> > > errors, 
> > > But I think most payment schemes doesn't generate payment receipts when
> > > errors
> > > occur.  Taking it into consideration, the PayReceipt should be optional
> > in
> > > the 
> > > PayRespBlk.  What do you think about it?
> > ## I agree, Pay Receipt Component is only required if the Status component
> > is "Completed OK".
> > 
> > The DTD is changed from ...
> > 
> > <!ELEMENT PayRespBlk (Status, PayReceipt, PaySchemeData?,
> >      PaymentNote?, TradingRoleData*) >
> > 
> > ... to ...
> > 
> > <!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,
> >      PaymentNote?, TradingRoleData*) >
> > 
> > ... and the description of the PayReceipt in the Pay Response Block is
> > changed to ...
> > 
> > 	"Contains payment scheme specific data which can be used to verify
> > the payment occurred. See section 7.10 Payment Receipt Component. It must
> > be
> > present if the ProcessState attribute of the Status Component is set to
> > CompletedOk. PayReceipt is optional for other values as specified by the
> > appropriate Payment Scheme supplement."
> > 
> > 
> > > Regards
> > > Masaaki
> > > -----
> > > Masaaki Hiroya
> > > Systems Development Laboratory
> > > Hitachi, Ltd.
> > > tel: +81-44-959-0874
> > > fax: +81-44-959-0856
> > > email: [email-masked]
> > > -----------------------------------------------------------------------
> > > Message addressed to: [email-masked]
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > > body to: [email-masked]
> > > 
> > 
> > **************************************************************************
> > ********************
> > 
> > This Email and any attached files are confidential and may also be
> > privileged. 
> > If you are not the intended recipient, please notify the postmaster using
> > email 
> > address [email-masked] or call +44 171 557 5000 and ask for the 
> > IT Helpdesk.  You should not copy this email and any attached files, use
> > them 
> > for any purpose or disclose the contents to any other person; all copies
> > of the 
> > Email and associated files in your possession should be destroyed.
> > 
> > Mondex International Limited
> > 47-53 Cannon Street
> > London EC4M 5SQ
> > United Kingdom
> > Registered No: 3122085, England
> > 
> > Phone:          +44 171 557 5000
> > Fax:            +44 171 557 5200
> > Email:          [email-masked]
> > WebSite:        http://www.mondexinternational.com
> > 
> > **************************************************************************
> > *******************
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> > 
> 
> ****************************************************************************
> ******************
> 
> This Email and any attached files are confidential and may also be 
> privileged. 
> If you are not the intended recipient, please notify the postmaster using email 
> address [email-masked] or call +44 171 557 5000 and ask for the 
> IT Helpdesk.  You should not copy this email and any attached files, use them 
> for any purpose or disclose the contents to any other person; all copies of the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> ****************************************************************************
> *****************
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 
-----
Masaaki Hiroya
Systems Development Laboratory
Hitachi, Ltd.
tel: +81-44-959-0874
fax: +81-44-959-0856
email: [email-masked]
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Tony Lewis <[email-masked]>,  Yoshiaki KAWATSURA <[email-masked]>
Cc: Ietf Trade WG <[email-masked]>
Subject: RE: Initial IOTP Brand Ids
Date: Thu, 27 May 1999 18:44:02 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Yoshiaki raises an interesting point. Brand names such as Visa, MasterCard,
JCB, etc, are actually owned by their respective companies. Can we, in the
IETF Trade WG, just define what these Brands' BrandIds for IOTP will be
without getting their permission first?

One approach might be to go through SETCo and get blanket permission to
adopt SETCo's BrandIds in order to save the companies having to individually
register them through IANA later.

Thoughts?

David

> ----------
> From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> Sent: 	26 May 1999 22:56
> To: 	[email-masked]
> Cc: 	[email-masked]; [email-masked]
> Subject: 	RE: Initial IOTP Brand Ids
> 
> Hello,
> 
> >>>>> Wed, 26 May 1999 16:54:57 -0700,
> 	"Lewis, Tony" <[email-masked]> said:
> 
> > The list of brands who have requested a SET object identifier (the list
> you
> > found in Book 3) is not the same as the list of brands who have
> requested a
> > SET brand certificate.
> Absolutely.
> 
> But basically I think IOTP Brand ID registration should be requested by
> each brand-owner. There is no problem if the JCB Card registers
> "JCB_Card" as the IOTP Brand ID, not "JCB".
> 
> Furthermore, there is no problem if the UC Card registers
> "Visa_UC" as the IOTP Brand ID, not same as the SET brand(in this
> case, "Visa" brand is used as the SET Brand. In this case, the Brand
> Element
> is became as follows.
> 
> <Brand ID = 'xxx'
>     BrandId='Visa_UC'
>     BrandName='UC Visa Card'
>     BrandLogoNetLocn='http://otplogos.uccard.com'
>     ProtocolAmountRefs='xxx xxx'>
>     <ProtocolBrand 
>         ProtocolId='SETv1.0' 
>         ProtocolBrandId='Visa' />
> </Brand>
> 
> As this case we can discount for each the dual brand (even if the
> promotional brand). 
> 
> P.S.
> We have to be able to check the consistency between IOTP brand and
> payment scheme specific brand because there are defined separately.
> We have to have the table of relationship between them in the
> Payment Bridge....
> 
> ----
> Yoshiaki Kawatsura : E-mail [email-masked]
>  Business & Information Systems Development Division, Hitachi,Ltd.
> Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
> 
> > I will try to get you a list of those brands.
> > 
> > Tony
> > > ----------
> > > From: 	David Burdett[SMTP:[email-masked]]
> > > Sent: 	Wednesday, May 26, 1999 12:43 PM
> > > To: 	Ietf Trade WG
> > > Subject: 	Initial IOTP Brand Ids
> > > 
> > > We need to build a list of IOTP Brand Ids for inclusion in the IOTP
> spec.
> > > 
> > > The initial list I have developed is as follows:
> > > *	from SET Book 3 Formal Protocol Definition:
> > > 	- "IATA"
> > > 	- "Diners"
> > > 	- "AmericanExpress"
> > > 	- "JCB"
> > > 	- "Visa"
> > > 	- "MasterCard"
> > > 	- "Novus"
> > > 
> > > *	none SET brand ids:
> > > 	- "Mondex"
> > > 	- "Maestro"
> > > 	- "GeldKarte"
> > > 
> > > It would be good if the initial list is reasonably comprehensive and
> > > accurate so if anyone wants more Brand Ids added (or any taken off !!)
> > > then
> > > please let me know. Also do you think we need to specify a contact or
> > > "owner" of the Brand as SET does.
> > > 
> > > Additional brands can, of course,  be added later using IANA
> procedures.
> > > 
> > > David
> > > 
> > > > mailto:<[email-masked]>
> > > > Mondex International, US Advanced Technology Office
> > > > 111 Pine St, 6th Floor, San Francisco, CA 94111
> > > > Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> > > > 
> > > 
> > >
> **************************************************************************
> > > ********************
> > > 
> > > This Email and any attached files are confidential and may also be
> > > privileged. 
> > > If you are not the intended recipient, please notify the postmaster
> using
> > > email 
> > > address [email-masked] or call +44 171 557 5000 and ask for the
> 
> > > IT Helpdesk.  You should not copy this email and any attached files,
> use
> > > them 
> > > for any purpose or disclose the contents to any other person; all
> copies
> > > of the 
> > > Email and associated files in your possession should be destroyed.
> > > 
> > > Mondex International Limited
> > > 47-53 Cannon Street
> > > London EC4M 5SQ
> > > United Kingdom
> > > Registered No: 3122085, England
> > > 
> > > Phone:          +44 171 557 5000
> > > Fax:            +44 171 557 5200
> > > Email:          [email-masked]
> > > WebSite:        http://www.mondexinternational.com
> > > 
> > >
> **************************************************************************
> > > *******************
> > >
> -----------------------------------------------------------------------
> > > Message addressed to: [email-masked]
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > body to: [email-masked]
> > > 
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> > 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: RE: Initial IOTP Brand Ids
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 27 May 1999 14:56:51 +0900 (JST)
Lines: 124
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Hello,

>>>>> Wed, 26 May 1999 16:54:57 -0700,
	"Lewis, Tony" <[email-masked]> said:

> The list of brands who have requested a SET object identifier (the list you
> found in Book 3) is not the same as the list of brands who have requested a
> SET brand certificate.
Absolutely.

But basically I think IOTP Brand ID registration should be requested by
each brand-owner. There is no problem if the JCB Card registers
"JCB_Card" as the IOTP Brand ID, not "JCB".

Furthermore, there is no problem if the UC Card registers
"Visa_UC" as the IOTP Brand ID, not same as the SET brand(in this
case, "Visa" brand is used as the SET Brand. In this case, the Brand Element
is became as follows.

<Brand ID = 'xxx'
    BrandId='Visa_UC'
    BrandName='UC Visa Card'
    BrandLogoNetLocn='http://otplogos.uccard.com'
    ProtocolAmountRefs='xxx xxx'>
    <ProtocolBrand 
        ProtocolId='SETv1.0' 
        ProtocolBrandId='Visa' />
</Brand>

As this case we can discount for each the dual brand (even if the
promotional brand). 

P.S.
We have to be able to check the consistency between IOTP brand and
payment scheme specific brand because there are defined separately.
We have to have the table of relationship between them in the
Payment Bridge....

----
Yoshiaki Kawatsura : E-mail [email-masked]
 Business & Information Systems Development Division, Hitachi,Ltd.
Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721

> I will try to get you a list of those brands.
> 
> Tony
> > ----------
> > From: 	David Burdett[SMTP:[email-masked]]
> > Sent: 	Wednesday, May 26, 1999 12:43 PM
> > To: 	Ietf Trade WG
> > Subject: 	Initial IOTP Brand Ids
> > 
> > We need to build a list of IOTP Brand Ids for inclusion in the IOTP spec.
> > 
> > The initial list I have developed is as follows:
> > *	from SET Book 3 Formal Protocol Definition:
> > 	- "IATA"
> > 	- "Diners"
> > 	- "AmericanExpress"
> > 	- "JCB"
> > 	- "Visa"
> > 	- "MasterCard"
> > 	- "Novus"
> > 
> > *	none SET brand ids:
> > 	- "Mondex"
> > 	- "Maestro"
> > 	- "GeldKarte"
> > 
> > It would be good if the initial list is reasonably comprehensive and
> > accurate so if anyone wants more Brand Ids added (or any taken off !!)
> > then
> > please let me know. Also do you think we need to specify a contact or
> > "owner" of the Brand as SET does.
> > 
> > Additional brands can, of course,  be added later using IANA procedures.
> > 
> > David
> > 
> > > mailto:<[email-masked]>
> > > Mondex International, US Advanced Technology Office
> > > 111 Pine St, 6th Floor, San Francisco, CA 94111
> > > Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> > > 
> > 
> > **************************************************************************
> > ********************
> > 
> > This Email and any attached files are confidential and may also be
> > privileged. 
> > If you are not the intended recipient, please notify the postmaster using
> > email 
> > address [email-masked] or call +44 171 557 5000 and ask for the 
> > IT Helpdesk.  You should not copy this email and any attached files, use
> > them 
> > for any purpose or disclose the contents to any other person; all copies
> > of the 
> > Email and associated files in your possession should be destroyed.
> > 
> > Mondex International Limited
> > 47-53 Cannon Street
> > London EC4M 5SQ
> > United Kingdom
> > Registered No: 3122085, England
> > 
> > Phone:          +44 171 557 5000
> > Fax:            +44 171 557 5200
> > Email:          [email-masked]
> > WebSite:        http://www.mondexinternational.com
> > 
> > **************************************************************************
> > *******************
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> > 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Lewis, Tony" <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: Initial IOTP Brand Ids
Date: Wed, 26 May 1999 16:54:57 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The list of brands who have requested a SET object identifier (the list you
found in Book 3) is not the same as the list of brands who have requested a
SET brand certificate.

I will try to get you a list of those brands.

Tony
> ----------
> From: 	David Burdett[SMTP:[email-masked]]
> Sent: 	Wednesday, May 26, 1999 12:43 PM
> To: 	Ietf Trade WG
> Subject: 	Initial IOTP Brand Ids
> 
> We need to build a list of IOTP Brand Ids for inclusion in the IOTP spec.
> 
> The initial list I have developed is as follows:
> *	from SET Book 3 Formal Protocol Definition:
> 	- "IATA"
> 	- "Diners"
> 	- "AmericanExpress"
> 	- "JCB"
> 	- "Visa"
> 	- "MasterCard"
> 	- "Novus"
> 
> *	none SET brand ids:
> 	- "Mondex"
> 	- "Maestro"
> 	- "GeldKarte"
> 
> It would be good if the initial list is reasonably comprehensive and
> accurate so if anyone wants more Brand Ids added (or any taken off !!)
> then
> please let me know. Also do you think we need to specify a contact or
> "owner" of the Brand as SET does.
> 
> Additional brands can, of course,  be added later using IANA procedures.
> 
> David
> 
> > mailto:<[email-masked]>
> > Mondex International, US Advanced Technology Office
> > 111 Pine St, 6th Floor, San Francisco, CA 94111
> > Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> > 
> 
> **************************************************************************
> ********************
> 
> This Email and any attached files are confidential and may also be
> privileged. 
> If you are not the intended recipient, please notify the postmaster using
> email 
> address [email-masked] or call +44 171 557 5000 and ask for the 
> IT Helpdesk.  You should not copy this email and any attached files, use
> them 
> for any purpose or disclose the contents to any other person; all copies
> of the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> **************************************************************************
> *******************
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>,  David Burdett <[email-masked]>,  Chris Smith <[email-masked]>
Subject: RE: Otp -> Iotp ??
Date: Wed, 26 May 1999 20:43:33 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I thought it might be simpler if I sent the latest, partially updated,
version of the DTD. Note that I've added DRAFT and todays date to the top,
so that this version can be distinguished from later versions.

As far as changed attribute values are concerned. The only one to change is,
as Chris says, the RelationshipType attribute of the RelatedTo element.

Note that some of the changes still under discussion have not yet been
implemented in the attached DTD. The changes that have been made are
itemised in comments at the start.

David
PS. The DTD is at the END of this email.

> ----------
> From: 	Smith, Chris[SMTP:[email-masked]]
> Sent: 	26 May 1999 06:55
> To: 	"Ietf Trade WG" ; "David Burdett" 
> Subject: 	RE: Otp -> Iotp ??
> 
> 
> As a courtesy, could you mail a (non-normative) list of these changes to 
> the mailing list? It seems that the indicated Elements, Attributes and 
> the single attribute value "OtpTransaction" are the only items, right? 
> 
> It would help those of us who are actually starting to use the other 
> values. DRAFT, yes, but this would guarantee a complete break between 
> DRAFT and final, affecting every piece of IOTP code that works with the 
> message. (My DOM calls regularly start at the base <OtpMessage> and work 
> down.) 
> 
> It's a simple change now, and if we use a version indicator such as 
> "DRAFT1.0" then we can easily detect the difference as final 1.0 
> versions start to show up. 
> 
> ...Chris 
> 
> ______________________________ Reply Separator
> _________________________________ 
> Subject: Otp -> Iotp ?? 
> Author:  "David Burdett" [SMTP:[email-masked]] at Internet 
> Date:    1999/05/17 09:17 PM 
> 
> 
> There are still some element or attribute names in the DTD that contain 
> "Otp" rather than "Iotp". Do we want to change them? My view is yes, 
> although if anyone strongly objects I'm open to persuasion. 
> 
> Names to which this applies are: 
> *     OtpMessage, 
> *     OtpTransId, 
> *     OtpTransType, 
> *     RespOtpMsg, 
> *     OtpMsgIdPrefix, 
> *     OtpMsgRef, 
> *     LastReceivedOtpMsgRef, 
> *     LastSentOtpMsgRef 
> 
> The first is an element. The rest are attributes. 
> 
> Thoughts? 
> 
> David 
> 
<!--
DRAFT MAY 26, 1999
******************************************************
*                                                    *
* INTERNET OPEN TRADING PROTOCOL DTD VERSION 04      *
* Filename: iotp-v1.0-protocol-04.dtd                *
*                                                    *
* Changes from version 03 (iotp-v1.0-protocol-04.dtd)*
* - changed SigBlk to Signatures in the IotpMessage  *
*   element to make consistent with the new signature*
*   definition                                       *
* - added LangPrefList and CharSetPrefList to MsgId  *
*   component to indicate language and character set *
*   preference of sender of the message              *
* - replace PayReceiptRefs attribute by              *
*   PayReceiptNameRefs in the Pay Receipt Component  *
* - add PaymentRef as required attribute of          *
*   Payment Scheme Data                              *
* - Changed 'Otp' to 'Iotp' in OtpMessage element    *
* - Changed 'Otp' to 'Iotp' in following attribute   *
*   names: OtpTransId, OtpTransType, RespOtpMsg,     *
*   OtpMsgIdPrefix, OtpMsgRef, LastReceivedOtpMsgRef,*
*   LastSentOtpMsgRef                                *
* - Added AuthenticationId after the Id attribute in *
*   the AuthResp block                               *
* - Deleted IotpMsgIdPrefix from Org Component and   *
*   added IotpMsgIdPrefix to Trading Role Component  *
* - Changed occurence of AuthData in the AuthReq     *
*   block from '?' to '*', so that each AuthData     *
*   component defines an authentication method to be *
*   chosen, and, in the AuthData Component, changed  *
*   Packaged content occurences from '?' to '*' and  *
*   removed AlgorithmRefs attribute                  *
* - Added TradingRoleInfoReq component to request    *
*   information about a Trading Role                 *
* - Changed Pay Response Block (PayRespBlk) to make  *
*   Pay Receipt Component (PayReeipt) optional       *
* - Changed occurence of PackagedContent within the  *
*   PayReceipt component from '+' to '*'             *
* - Add ProtocolBrand element defintion as child of  *
*   Brand element                                    *
*                                                    *
* Copyright Internet Engineering Task Force 1998,99  *
*                                                    *
******************************************************

******************************************************
* IOTP MESSAGE DEFINITION                            *
******************************************************
 -->

<!ELEMENT IotpMessage
   ( TransRefBlk,
     Signatures?,
     ErrorBlk?,
     ( AuthReqBlk |
       AuthRespBlk |
       AuthStatusBlk |
       CancelBlk |
       DeliveryReqBlk |
       DeliveryRespBlk |
       InquiryReqBlk |
       InquiryRespBlk |
       OfferRespBlk |
       PayExchBlk |
       PayReqBlk |
       PayRespBlk |
       PingReqBlk |
       PingRespBlk |
       TpoBlk |
       TpoSelectionBlk
     )*
   ) >
<!ATTLIST IotpMessage
  xmlns:iotp	CDATA	
   'ietf.org/draft-ietf-trade-iotp-v1.0-protocol-04' >

<!--
******************************************************
* 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        NMTOKEN #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             NMTOKEN   #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    NMTOKEN #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   #REQUIRED
 ErrorNetLocn       CDATA   #REQUIRED
 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            NMTOKEN #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'
 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
 StartAfter         NMTOKENS #IMPLIED >

<!-- PAYMENT SCHEME COMPONENT -->
<!ELEMENT PaySchemeData (PackagedContent+) >
<!ATTLIST PaySchemeData
 ID                 ID      #REQUIRED
 PaymentRef         NMTOKEN #REQUIRED
 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
 ConsumerDeliveryId CDATA   #IMPLIED >

<!ELEMENT DeliveryData (PackagedContent*) >
<!ATTLIST DeliveryData
 xml:lang           NMTOKEN #IMPLIED
 OkFrom             CDATA   #REQUIRED
 OkTo               CDATA   #REQUIRED
 DelivMethod        NMTOKEN #REQUIRED
 DelivToRef         NMTOKEN #REQUIRED
 DelivReqNetLocn    CDATA   #REQUIRED
 SecDelivReqNetLocn CDATA   #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

<!-- 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 #REQUIRED
 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 #REQUIRED
 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,
     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 SIGNAUTRE COMPPONENT DEFINITION               *
******************************************************
 -->

<!ELEMENT Signature (Manifest, Value+) >
<!ATTLIST Signature
  ID                ID      #IMPLIED >

<!ELEMENT Manifest 
  (Algorithm+,
   Digest+,
   Attributes?,
   OriginatorInfo,
   RecipientInfo+,
  )
<!ATTLIST Manifest
  LocatorHRefBase   CDATA   #IMPLIED >

<!ELEMENT Algorithm (Parameter*) >
<!ATTRLIST Algorithm
 ID                 ID      #REQUIRED
 type  (digest|signature|keyagreement) #IMPLIED
 name               NMTOKEN #REQUIRED >
 
<!ELEMENT Digest (Value) >
<!ATTLIST Digest
 LocatorHREF        NMTOKEN #REQUIRED
 DigestAlgorithmRef IDREF   #REQUIRED >

<!ELEMENT Attributes (Attribute+) >

<!ELEMENT Attribute ( #PCDATA ) >
<!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    #REQUIRED
 SignatureCertRef   IDREF    #IMPLIED
 RecipientRefs      NMTOKENS #IMPLIED >

<!ELEMENT Parameter ANY >
<!ATTLIST Parameter
 type               PCDATA  #REQUIRED >

<!--
******************************************************
* IOTP CERTIFICATE COMPPONENT 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 >

<!ELEMENT Value ( #PCDATA ) >
<!ATTLIST Value
 id                 ID      #IMPLIED
 encoding ( base64 | none ) #REQUIRED >

<!ELEMENT Locator EMPTY>
<!ATTLIST Locator
 href               CDATA   #REQUIRED >

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: Brand IDs & their registration.
Date: Wed, 26 May 1999 20:43:44 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

As there have been no further comments, I plan to make this change. I'd
particularly someone with SET experience to review the revised Brand example
below.

Details follow ...

David

BRAND ELEMENT DEFINTION

Changed to ...

	<!ELEMENT Brand (ProtocolBrand*, PackagedContent*) >

Definition of BrandId attribute now reads:

	This contains a unique identifier for the brand (or promotional
brand). It is used to match against a list of Payment Instruments which the
Consumer holds to determine whether or not the Consumer can pay using the
Brand.

	Values of BrandId are managed under the procedure described in
section 12 IANA Considerations.

	As values of BrandId are controlled under the procedures defined in
section 12 IANA Considerations user defined values may be defined.

PROTOCOL BRAND ELEMENT DEFINTION

The Protocol Brand Element contains information that is specific to the use
of a particular Protocol with a Brand. Its definition is as follows.

<!ELEMENT ProtocolBrand (PackagedContent*) >
<!ATTLIST ProtocolBrand
 ProtocolId         CDATA   #REQUIRED
 ProtocolBrandId    CDATA   #REQUIRED >

Attributes:
*	ProtocolId	This must match the value of a ProtocolId attribute
in a Pay Protocol Element (see section 7.7.5). The values of ProtocolId
should be unique within a Brand Element otherwise there is an error.	
*	ProtocolBrandId	This is the Payment Brand Id to be used with a
particular payment protocol. For example, SET and EMV have their own well
defined, yet different, values for the Brand Id to be used with each
protocol. The valid values of this attribute are defined in the supplement
for the payment protocol identified by ProtocolId that describes how the
payment protocol works with IOTP.	
Content:
*	PackagedContent	Optional Packaged Content (see section 3.7) elements
containing information about the protocol/brand which may be used by the
payment protocol. The content of this information is defined in the
supplement for a payment protocol which describes how the payment protocol
works with IOTP.	

BRAND LISTS AND BRAND SELECTION

Add another couple of paragraphs in section 11 that say ...

11.x.x.x 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. 

BRAND LIST EXAMPLE

Comments from people with SET knowledge are welcome on this.

The second Brand List Example changes to become ...

<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 >
   ...
</BrandList>

> ----------
> From: 	David Burdett[SMTP:[email-masked]]
> Sent: 	20 May 1999 14:46
> To: 	Ietf Trade WG; Tony Lewis
> Subject: 	RE: Brand IDs & their registration.
> 
> I've been reading the emails on this topic and *think* I have a solution.
> Details follow. But I really would like feedback on this before changing
> the
> spec.
> 
> David
> 
> INTRODUCTION
> As I see it the requirement is as follows:
> 1. We need to have a unique "brand id" so that we can link things like the
> brand name, URL for the logo, etc to it.
> 2. In addition for *some* payment protocols, we also need a protocol
> specific version of a "brand id". For example for SET the payment protocol
> specific of the Brand Id must be of the form "brand:[product]" and for EMV
> it must be "RID+PIX", yet SCCD (I think) doesn't need a ProtocolBrandId at
> all.
> 
> Currently the specification does not have a suitable "slot" into which to
> put a payment protocol specific brand id. So how about the following as an
> approach. It involves:
> *	adding a new optional child element within the Brand elememt which
> is protocol specific to hold the ProtocolBrandId, and
> *	amending the definition of Brand Id in the Brand element of a Brand
> list so that it becomes a pure IOTP defined brand id.
> 
> Detailed changes below ... 
> 
> BRAND ELEMENT.
> 
> Change the Brand Element definition (the ATTLIST doesn't change) from ...
> 
> 	<!ELEMENT Brand (PackagedContent*) >
> 
> ... to ...
> 
> 	<!ELEMENT Brand (ProtocolBrand*, PackagedContent*) >
> 
> The only other change to the Brand element is to change the definition of
> the BrandId attribute to simply read ...
> 
> 	This contains a unique identifier for the brand (or promotional
> brand). It is used to match against a list of Payment Instruments which
> the
> Consumer holds to determine whether or not the Consumer can pay with the
> Brand.
> 
> 	BrandIds are controlled under the procedures defined in section 12
> IANA Considerations. User defined values of BrandId may be used.
> 
> PROTOCOL BRAND ELEMENT.
> The new ProtocolBrand element is then defined as ...
> 
> 	<!ELEMENT ProtocolBrand EMPTY>
> 	<!ATTLIST ProtocolBrand
> 	   ProtocolId         CDATA   #REQUIRED
> 	   ProtocolBrandId    CDATA   #REQUIRED >
> 
> ... where ProtcolId must match the ProtocolId within a PayProtocol
> element,
> and ProtocolBrandId is the ProtocolBrandId to be used with that brand and
> protocol.
> 
> EXAMPLE
> For example a Visa gold card could be defined as follows ...
> 
>   <Brand ID = 'xxx'
>     BrandId='VisaGold'
>     BrandName='Visa Gold'
>     BrandLogoNetLocn='http://otplogos.visa.com'
>     ProtocolAmountRefs='xxx xxx'>
>     <ProtocolBrand 
>         ProtocolId='SETv1.0' 
>         ProtocolBrandId='Visa:Gold' />
>     <ProtocolBrand 
>         ProtocolId='EMVv1.0' 
>         ProtocolBrandId='0xA000000004:0xA000000032' />
>   </Brand>
> 
> Responsibility for defining valid values of ProtocolId and the structure
> of
> the ProtocolBrandId (if there is one) that should be used with that
> version
> of the payment protocol would lie with the payment protocol supplement for
> IOTP.
> 
> Initial values for BrandIds would be defined in the main IOTP
> specification
> and initial values for ProtocolBrandId in the payment protocol supplement.
> In the future, new values of BrandId and their associated
> ProtocolBrandId's
> would use IANA procedures. More precisely ...
> 
> 	"New values of BrandId and their associated ProtocolBrandIds (if
> any) 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."
> 
> In practice this means that if an established organisation (e.g
> MasterCard,
> Visa or Amex) wants to implement a new brand and give it a ProtocolBrandId
> for each protocol to be used with it, then they can. It also means that
> new
> organisations with new brands can do the same sort of thing.
> 
> > ----------
> > From: 	Lewis, Tony[SMTP:[email-masked]]
> > Sent: 	18 May 1999 09:39
> > To: 	Ietf Trade WG
> > Subject: 	RE: Brand IDs & their registration. Was: RE: Comments on
> > draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > 
> > This chain has taken so many turns, I'm not convinced that I know what
> > problem we're trying to solve anymore.
> > 
> > I think the problem is: How do we identify the brand that will be used
> in
> > a
> > transaction regardless of payment protocol?
> > 
> > For SET, this is "brand[:product]". For EMV, this is RID+PIX. Other
> > protocols will have their own internal method of encoding the brand. In
> > all
> > cases, the user will want to see a graphical representation of the Visa,
> > MasterCard, Maestro, Mondex, etc. logo.
> > 
> > Do we need a new registry for brands? If we create such a registry, how
> do
> > we correlate those registrations with other schemes that know about the
> > same
> > brands? Are we going to have a big table somewhere that correlates IOTP
> > brand, SET brand, EMV brand, etc.?
> > 
> > By the way, Visa does not imply "credit". It can be credit or debit.
> > 
> > Tony
> > > ----------
> > > From: 	David Burdett[SMTP:[email-masked]]
> > > Sent: 	Monday, May 17, 1999 6:17 PM
> > > To: 	[email-masked]; Lewis, Tony
> > > Cc: 	Ietf Trade WG
> > > Subject: 	RE: Brand IDs & their registration. Was: RE: Comments on
> > > draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > 
> > > John/Tony
> > > 
> > > I don't think the RID+PIX is the way to go. Surely all we need is a
> > > clearly
> > > defined name declared in a public forum (e.g. the Trade WG or its
> > > successor). For example we could declare:
> > > *	MasterCard (implies credit)
> > > *	Maestro (MasterCard debit)
> > > *	Mondex (electronic cash)
> > > *	Visa (implies credit)
> > > *	VisaCash (electronic cash)
> > > 
> > > The "protocols" that can be used with each brand, e.g. SETv1.0, SCCD,
> > etc.
> > > are then separately specified with their own individual "payment
> > > protocol/version no" identifiers. 
> > > 
> > > There is still the need to know which payment protocols can be used
> with
> > > each brand. However I don't think this an IOTP issue since:
> > > *	Merchant's will know when they create a Brand List which protocols
> > > are applicable for each Brand
> > > *	Consumer's will know when they add a new brand what type of payment
> > > instrument it is (e.g. Credit) and the consumer software can then
> decide
> > > which payment protocols apply.
> > > 
> > > Do you both agree?
> > > 
> > > David
> > > 
> > > > ----------
> > > > From:
> > > >
> [email-masked][SMTP:[email-masked]]
> > > > Sent: 	05 May 1999 23:01
> > > > To: 	Ietf Trade WG
> > > > Subject: 	RE: Brand IDs & their registration. Was: RE:
> Comments on
> > > > draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > > 
> > > > 
> > > > 
> > > > My understanding is that a RID (Registered ID obtained from ISO) is
> > > > assigned
> > > > more to an organization or association.
> > > > 
> > > > It is not easy to distinguish between
> > > > a RID, a brand, and a consumer acceptance mark.
> > > > 
> > > > For MasterCard, the same RID is used for:
> > > >    - MasterCard International chip credit cards,
> > > >    - and Maestro International pin based debit cards - which uses a
> > > > different
> > > >    acceptance "mark" for what some consumers may consider a "brand".
> > > > 
> > > > For MasterCard's RID the hexadecimal characters 0xA000000004 have
> been
> > > > assigned
> > > > by ISO to MasterCard.  The RID does not differentiate between our
> > > > MasterCard and
> > > > Maestro marks,
> > > > but it is only the full RID + PIX (AID) that distinguishes what
> > "brand"
> > > or
> > > > mark
> > > > is involved.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > "Lewis, Tony" <[email-masked]> on 05/04/99 08:09:25 PM
> > > > 
> > > > To:   Ietf Trade WG <[email-masked]>
> > > > cc:    (bcc: John Wankmueller/NYC/MASTERCARD)
> > > > Subject:  RE: Brand IDs & their registration. Was: RE: Comments on
> > > > draft-ie tf-t
> > > >       rade-iotp-v1.0-protocol-03.txt, part 1
> > > > 
> > > > 
> > > > 
> > > > 
> > > > In fact, Europay, MasterCard, and Visa have established EMVCo.
> (EMVCo
> > > does
> > > > not currently have a web site so I can't point you there. I'm told
> the
> > > > site
> > > > won't be up until July.)
> > > > 
> > > > EMV does not have brands in the same way that SET or IOTP do. EMV
> > deals
> > > > with
> > > > application identifiers or AIDs. An AID consists of two parts: a
> > > > Registered
> > > > ID (RID) obtained from ISO and a Proprietary Extension (PIX). The
> RID
> > is
> > > > roughly analogous to a brand. For example, Visa has an RID with a
> > value
> > > of
> > > > 0xA000000003. Visa then assigns PIX values for various applications,
> > > e.g.,
> > > > Credit/Debit, VisaCash, etc.
> > > > 
> > > > Typically, an RID will be obtained by a payment brand, but there is
> no
> > > > guarantee that there is a one to one correspondence between a brand
> > and
> > > a
> > > > RID.
> > > > 
> > > > As we look at a way to integrate EMV cards with SET, we expect to
> add
> > > AIDs
> > > > to the SET Initiation message, which will ultimately be replaced by
> > > IOTP.
> > > > 
> > > > Tony
> > > > > ----------
> > > > > From:   Steve Fabes[SMTP:[email-masked]]
> > > > > Sent:   Tuesday, May 04, 1999 10:33 AM
> > > > > To:     [email-masked]; Ietf Trade WG
> > > > > Subject:     Re: Brand IDs & their registration. Was: RE: Comments
> > on
> > > > > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > > >
> > > > > Donald, I do not have much to add but when looking at the actions
> of
> > > > SETCo
> > > > > we should also anticipate that the EMV world will establish EMVCo
> > and
> > > > its
> > > > > rules will need to be considered along side those of SETCo's. The
> > > > > membership
> > > > > of the two Co's will overlap but be different and to assume the
> same
> > > > brand
> > > > > and operating rules may be optimistic.
> > > > > -----Original Message-----
> > > > > From: [email-masked] <[email-masked]>
> > > > > To: Ietf Trade WG <[email-masked]>
> > > > > Date: Tuesday, May 04, 1999 09:33
> > > > > Subject: RE: Brand IDs & their registration. Was: RE: Comments on
> > > > > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > > >
> > > > >
> > > > > >Regardless of EMV or whatever, it seems to me that we have a
> > "brand"
> > > > > registry
> > > > > >problem to solve.  Credit/Debit cards are sort of odd creatures
> > > because
> > > > > they can
> > > > > >be used in payments via multiple different protocols.  Most
> stored
> > > > value
> > > > > cards
> > > > > >can be used via only a single protocol.
> > > > > >
> > > > > >SETco clearly operates a card brand regisgration operations,
> > however
> > > > > limited and
> > > > > >even if it's only expressed in the brand level certificates that
> > > SETco
> > > > > allows to
> > > > > >be created under its root.  I think the hope was that the SET
> > > > > registration
> > > > > could
> > > > > >be used in IOTP for all credit/debit cards.  This would at least
> > > avoid
> > > > > the
> > > > > >problem where some brand was registered under different names at
> > > > > different
> > > > > >registries (where "different" could just be things like whether
> > there
> > > > is
> > > > > really
> > > > > >a space between American and Express or whether the C is
> > capitalized
> > > in
> > > > > >Mastercard or whether Visa is all caps, ...).  Is there a list of
> > > bands
> > > > > >officially supported by SETco and their official names?
> > > > > >
> > > > > >However, if SETco is inappropriate for this, because they won't
> > > > > "register"
> > > > > >brands that haven't joined", then we need a separate solution.
> It
> > > > > certainly
> > > > > >isn't very difficult to set up regsitration via IANA, probably
> > using
> > > > the
> > > > > same
> > > > > >Designated Expert criteria being used for other things.  The only
> > > > > difficulty I
> > > > > >can see is that some brand might get registered there for IOTP
> use
> > > and
> > > > > then
> > > > > >later join SETco or otherwise get registered in some other system
> > > under
> > > > > some
> > > > > >other name.  Various messyness with Discover/Novus, AT&T
> Universal
> > > Card
> > > > > changing
> > > > > >to CitiBank Universal Card and the like occur to me.  I'm not
> sure
> > > > those
> > > > > cases
> > > > > >are actually name change problems but one can image such.
> > > > > >
> > > > > >All this seems to imply that we need to be prepared to register
> > > > > credit/debit
> > > > > >card brands under "IOTP:".  I'm a bit reluctant to drop the
> "SET:"
> > > > branch
> > > > > of the
> > > > > >brand tree in IOTP.  If some brand exists under SETco but hasn't
> > yet
> > > > been
> > > > > >registered under IOTP, it seems like it should be usable.  Of
> > course,
> > > > > this
> > > > > means
> > > > > >that some brand registered under IOTP could later join SETco and
> > > could
> > > > > exist as
> > > > > >both IOTP:BrandX and SET:BrandX or SET:Brand-ex.  So you might
> get
> > > into
> > > > > >equivalence tables but these are really just an artifact of the
> > real
> > > > > world
> > > > > being
> > > > > >messy and not particularly worse than brands splitting or
> merging.
> > > > > >
> > > > > >I don't see a major problem with us using
> > > > > brand:[product]:[promotional-name] if
> > > > > >we want, even after "SET:", although we should make it clear in
> > that
> > > > case
> > > > > that
> > > > > >these values differ from those permitted in the SET protocol.
> The
> > > > other
> > > > > >possibility that occurs to me would be to use brand[:product] and
> > > have
> > > > a
> > > > > >separate [promotional=xxx] optional attribute.
> > > > > >
> > > > > >What do people think?
> > > > > >
> > > > > >Thanks,
> > > > > >Donald
> > > > > >
> > > > > >Donald E. Eastlake, 3rd
> > > > > >17 Skyline Drive, Hawthorne, NY 10532 USA
> > > > > >[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
> > > > > >
> > > > > >home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
> > > > > >[email-masked]   tel: 1-914-276-2668
> > > > > >
> > > > > >
> > > > > >
> > > > > >David Burdett <[email-masked]> on 04/29/99 12:17:01 PM
> > > > > >
> > > > > >To:   Ietf Trade WG <[email-masked]>
> > > > > >cc:   "Lewis, Tony" <[email-masked]> (bcc: Donald
> > > > > Eastlake/Hawthorne/IBM)
> > > > > >Subject:  RE: Brand IDs & their registration. Was: RE: Comments
> on
> > > > > draft-ie
> > > > > >      tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >I agree with Tony. Smart card based EMV transactions will be the
> > > > dominant
> > > > > >payment model within a decade, probably even earlier especially
> in
> > > the
> > > > > >non-US part of the world. The main reasons being, in my view:
> > > > > >*    it will reduce fraud as it's much much harder to copy a
> smart
> > > card
> > > > > >than a mag stripe card
> > > > > >*    it makes internet credit card payments "card present"
> > > transactions
> > > > > >which should result in lower merchant fees. This also means that
> it
> > > > will
> > > > > be
> > > > > >much harder for customers to claim they never made an internet
> > > purchase
> > > > > >*    using a multi-application smart card you will be able to use
> > > just
> > > > > >one smart card for debit, credit, electronic cash, a loyalty
> scheme
> > > as
> > > > > well
> > > > > >as hold electronic tickets for anything from local cinema to your
> > > next
> > > > > >flight.
> > > > > >
> > > > > >To rephrase a MasterCard ad line, "smart cards are the future of
> > > > money".
> > > > > >
> > > > > >David
> > > > > >
> > > > > >> ----------
> > > > > >> From:   Lewis, Tony[SMTP:[email-masked]]
> > > > > >> Sent:   28 April 1999 20:30
> > > > > >> To:     Ietf Trade WG
> > > > > >> Subject:     RE: Brand IDs & their registration. Was: RE:
> > Comments
> > > on
> > > > > >> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > > > >>
> > > > > >> My point is that the brand is "Visa" no matter whether using
> > IOTP,
> > > > SET
> > > > > or
> > > > > >> any other protocol.
> > > > > >>
> > > > > >> As for EMV, the very first live SET 1.0 transaction was made
> > using
> > > an
> > > > > EMV
> > > > > >> card with the EMV data carried inside a SET message extension.
> > EMV
> > > > > credit
> > > > > >> and debit products are a significant part of the future of
> > > electronic
> > > > > >> commerce. I expect they will be the dominant model for payment
> in
> > a
> > > > > >> decade.
> > > > > >>
> > > > > >> Tony
> > > > > >> > ----------
> > > > > >> > From:      Steve Fabes[SMTP:[email-masked]]
> > > > > >> > Sent:      Wednesday, April 28, 1999 3:43 PM
> > > > > >> > To:   Lewis, Tony; Ietf Trade WG
> > > > > >> > Subject:   Re: Brand IDs & their registration. Was: RE:
> > Comments
> > > on
> > > > > >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > > > >> >
> > > > > >> > Tony - do your comments infer that SET.Visa will be the only
> > > > > e-Commerce
> > > > > >> > product that an IOTP product supplier can expect to see. Can
> > you
> > > > see
> > > > > a
> > > > > >> day
> > > > > >> > when a Visa EMV 3.1.1 (or 3.x.x) based credit product could
> > also
> > > be
> > > > > used
> > > > > >> > inside an IOTP product?
> > > > > >> > -----Original Message-----
> > > > > >> > From: Lewis, Tony <[email-masked]>
> > > > > >> > To: Ietf Trade WG <[email-masked]>
> > > > > >> > Date: Wednesday, April 28, 1999 13:21
> > > > > >> > Subject: RE: Brand IDs & their registration. Was: RE:
> Comments
> > on
> > > > > >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > > > >> >
> > > > > >> >
> > > > > >> > >David,
> > > > > >> > >
> > > > > >> > >I am new to this group and do not know what lead to the
> > current
> > > > > >> approach.
> > > > > >> > >There are undoubtedly some issues that I don't know about.
> > > > However,
> > > > > it
> > > > > >> > seems
> > > > > >> > >to me that a brand is a brand no matter what payment
> protocol
> > is
> > > > > being
> > > > > >> > used.
> > > > > >> > >The only difference I see between "IOTP:Visa" and "SET:Visa"
> > is
> > > > that
> > > > > >> the
> > > > > >> > >latter indicates that the brand is supported by a specific
> > > payment
> > > > > >> > protocol.
> > > > > >> > >Since you need to support brands other than those supported
> by
> > > > SET,
> > > > > >> there
> > > > > >> > >will need to be a registry. It seems to me that there should
> > > only
> > > > be
> > > > > >> one
> > > > > >> > >such registry rather than the two being proposed. I
> recommend
> > > > having
> > > > > a
> > > > > >> > >single domain for these brands. It seems reasonable to
> > initially
> > > > > >> populate
> > > > > >> > it
> > > > > >> > >using the brands registered with SET and those non-SET
> brands
> > > you
> > > > > >> listed
> > > > > >> > in
> > > > > >> > >your note.
> > > > > >> > >
> > > > > >> > >Tony
> > > > > >> > >> ----------
> > > > > >> > >> From: David Burdett[SMTP:[email-masked]]
> > > > > >> > >> Sent: Wednesday, April 28, 1999 11:36 AM
> > > > > >> > >> To: Ietf Trade WG; Lewis, Tony
> > > > > >> > >> Subject: Brand IDs & their registration. Was: RE: Comments
> > on
> > > > > >> > >> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > > > >> > >>
> > > > > >> > >> In the current specification the basic idea for
> identifying
> > > > brands
> > > > > is
> > > > > >> > that
> > > > > >> > >> they should be of the form "xxx:brandid" where "xxx" can
> be
> > > > "SET"
> > > > > >> which
> > > > > >> > >> indicates that the brandid is any valid brandid that is
> > > accepted
> > > > > by
> > > > > >> > SET,
> > > > > >> > >> or
> > > > > >> > >> alternatively "IOTP" which can be used to define any brand
> > not
> > > > > >> defined
> > > > > >> > by
> > > > > >> > >> SET. The idea was that we should not need to define
> "Visa",
> > > > > >> > "MasterCard",
> > > > > >> > >> "American Express", etc more than once since they are
> > already
> > > > > defined
> > > > > >> > and
> > > > > >> > >> registered by SET.
> > > > > >> > >>
> > > > > >> > >> However a couple of problems may arise ...
> > > > > >> > >>
> > > > > >> > >> USING THE SET BRAND ID FOR NON-SET PAYMENTS
> > > > > >> > >> Although IOTP can support SET as a payment protocol, it
> can
> > > also
> > > > > >> > support
> > > > > >> > >> credit card payments (using Secure Channel Credit Debit -
> > > SCCD)
> > > > > where
> > > > > >> > the
> > > > > >> > >> credit card information (no, name, expiration date, etc)
> is
> > > > coded
> > > > > >> > >> effectively in the clear but with privacy protection
> > provided
> > > by
> > > > > >> using
> > > > > >> > a
> > > > > >> > >> secure channel such as SSL. In this way it provides a
> > similar
> > > > > level
> > > > > >> of
> > > > > >> > >> privacy/security as for credit card payments that occur
> now
> > > > where
> > > > > a
> > > > > >> web
> > > > > >> > >> page
> > > > > >> > >> form is completed by the user.
> > > > > >> > >>
> > > > > >> > >> My question is, will it be reasonable to use the SET
> brandid
> > > in
> > > > > this
> > > > > >> > way
> > > > > >> > >> to
> > > > > >> > >> cover non-SET credit card payments. I *think* the answer
> is
> > > > "yes"
> > > > > as
> > > > > >> > you
> > > > > >> > >> can
> > > > > >> > >> quite imagine a situation where a consumer is offered a
> > choice
> > > > of
> > > > > >> using
> > > > > >> > >> their VISA credit card to pay using either SET or SCCD.
> > > > > >> > >>
> > > > > >> > >> WHAT BRAND ID SHOULD BE USED FOR CO BRANDS
> > > > > >> > >> If a payment brand, such as a local brand or co-brand,
> > > chooses,
> > > > > >> > initiall
> > > > > >> > >> to
> > > > > >> > >> use just SCCD rather than SET then they would not (I
> think)
> > > need
> > > > > to
> > > > > >> > >> register
> > > > > >> > >> their brand with SET. In this case, they might register
> > their
> > > > > brand
> > > > > >> as
> > > > > >> > an
> > > > > >> > >> "IOTP" brand. However if they later adopted SET, they
> would
> > > end
> > > > up
> > > > > >> with
> > > > > >> > >> potentially two equivalent Brand IDs. Do you think we
> might
> > be
> > > > > better
> > > > > >> > off
> > > > > >> > >> with a straight IOTP brand and keep all the names under
> the
> > > > > >> procedures
> > > > > >> > >> defined by IANA? I'm not sure?
> > > > > >> > >>
> > > > > >> > >> REGISTERING NEW BRAND IDs
> > > > > >> > >> To help assist in answering the last point, the following
> is
> > > > what
> > > > > I'm
> > > > > >> > >> currently writing as the proposed IANA procedure for
> > > registering
> > > > > new
> > > > > >> > brand
> > > > > >> > >> ids. Any comments:
> > > > > >> > >>
> > > > > >> > >> >>>Clip>>>
> > > > > >> > >> The format of the Brand ID is either:
> > > > > >> > >> * SET:setbrand where setbrand is a brand which is accepted
> > by
> > > > the
> > > > > >> > >> [SET] payment protocol
> > > > > >> > >> * IOTP:iotpbrand where iotpbrand may be:
> > > > > >> > >> - GeldKarte
> > > > > >> > >> - Mondex
> > > > > >> > >>
> > > > > >> > >> New values of the high level prefix (SET or IOTP) should
> be
> > > > > allocated
> > > > > >> > >> following review on the IETF Trade Working Group mailing
> > list
> > > > and
> > > > > by
> > > > > >> > the
> > > > > >> > >> Designated Expert.
> > > > > >> > >>
> > > > > >> > >> Values of "setbrand" are allocated as defined in the [SET]
> > > > > >> > specifications.
> > > > > >> > >>
> > > > > >> > >> New values of "iotpbrand" must be announced to the IETF
> > Trade
> > > WG
> > > > > >> > mailing
> > > > > >> > >> list and, if there are no objections within three weeks,
> be
> > > > > allocated
> > > > > >> > on
> > > > > >> > a
> > > > > >> > >> "first come first served" basis.
> > > > > >> > >> <<<End Clip<<<
> > > > > >> > >>
> > > > > >> > >> Regards
> > > > > >> > >>
> > > > > >> > >> David
> > > > > >> > >> > ----------
> > > > > >> > >> > From: Lewis, Tony[SMTP:[email-masked]]
> > > > > >> > >> > Sent: 28 April 1999 08:14
> > > > > >> > >> > To: Ietf Trade WG
> > > > > >> > >> > Subject: RE: Comments on
> > > > > >> draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> > > > > >> > >> > part  1
> > > > > >> > >> >
> > > > > >> > >> > In SET, the BrandID is either "brand" or
> "brand:product".
> > > > > >> > >> >
> > > > > >> > >> > In Japan, there are products that are co-branded.
> > > Essentially
> > > > > these
> > > > > >> > >> > products
> > > > > >> > >> > are private label cards for domestic transactions with
> an
> > > > > >> > international
> > > > > >> > >> > brand for non-domestic transactions. The private label
> can
> > > be
> > > > > >> > reflected
> > > > > >> > >> in
> > > > > >> > >> > a
> > > > > >> > >> > SET cardholder certificate as the "promotional card
> name"
> > > > under
> > > > > the
> > > > > >> > >> > international brand's hierarchy and/or the cardholder
> can
> > > have
> > > > a
> > > > > >> > >> > certificate
> > > > > >> > >> > issued under the private label hierarchy.
> > > > > >> > >> >
> > > > > >> > >> > There is no provision to carry both the private label
> (of
> > > the
> > > > > >> > Japanese
> > > > > >> > >> > credit card company) and the international brand as part
> > of
> > > > the
> > > > > SET
> > > > > >> > >> > BrandID.
> > > > > >> > >> >
> > > > > >> > >> > Tony
> > > > > >
> > > > > >
> > > > >
> > >
> >-----------------------------------------------------------------------
> > > > > >Message addressed to: [email-masked]
> > > > > >Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > > >To (un)subscribe send a message with "subscribe" or "unsubscribe"
> > in
> > > > the
> > > > > >body to: [email-masked]
> > > > > >
> > > > >
> > > > >
> > >
> -----------------------------------------------------------------------
> > > > > Message addressed to: [email-masked]
> > > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > > To (un)subscribe send a message with "subscribe" or "unsubscribe"
> in
> > > the
> > > > > body to: [email-masked]
> > > > >
> > > >
> > -----------------------------------------------------------------------
> > > > Message addressed to: [email-masked]
> > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> > the
> > > > body to: [email-masked]
> > > > 
> > > > 
> > > > 
> > > > 
> > > >
> > -----------------------------------------------------------------------
> > > > Message addressed to: [email-masked]
> > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> > the
> > > > body to: [email-masked]
> > > > 
> > > 
> > >
> >
> **************************************************************************
> > > ********************
> > > 
> > > This Email and any attached files are confidential and may also be
> > > privileged. 
> > > If you are not the intended recipient, please notify the postmaster
> > using
> > > email 
> > > address [email-masked] or call +44 171 557 5000 and ask for the
> 
> > > IT Helpdesk.  You should not copy this email and any attached files,
> use
> > > them 
> > > for any purpose or disclose the contents to any other person; all
> copies
> > > of the 
> > > Email and associated files in your possession should be destroyed.
> > > 
> > > Mondex International Limited
> > > 47-53 Cannon Street
> > > London EC4M 5SQ
> > > United Kingdom
> > > Registered No: 3122085, England
> > > 
> > > Phone:          +44 171 557 5000
> > > Fax:            +44 171 557 5200
> > > Email:          [email-masked]
> > > WebSite:        http://www.mondexinternational.com
> > > 
> > >
> >
> **************************************************************************
> > > *******************
> > > 
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> > 
> 
> **************************************************************************
> ********************
> 
> This Email and any attached files are confidential and may also be
> privileged. 
> If you are not the intended recipient, please notify the postmaster using
> email 
> address [email-masked] or call +44 171 557 5000 and ask for the 
> IT Helpdesk.  You should not copy this email and any attached files, use
> them 
> for any purpose or disclose the contents to any other person; all copies
> of the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> **************************************************************************
> *******************
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: Error Handling
Date: Wed, 26 May 1999 20:43:37 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

In my last email on Error Handling it said in the description of Payment
Completion codes that:

> If the Payment is Brand Independent, then recovery may be possible for
> some values of the Completion Code, by the Consumer selecting a different
> payment brand. Note that this might involve a different Payment Handler.
> The codes to which this applies are: BrandNotSupp, PaymtCancelled,
> InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument and
> Unspecified.
> 
	Recovery from Payments associated with Brand Dependent purchases is
not possible, since the Offer is dependent on a the entries selected from
the Brand List. A changed selection will invalidate the Offer Response.

This is not quite correct. It should have said ...

> If the Payment is Brand Independent, then recovery may be possible for
> some values of the Completion Code, by the Consumer selecting either a
> different payment brand or a different payment instrument for the same
> brand. Note that this might involve a different Payment Handler. The codes
> to which this applies are: BrandNotSupp, PaymtCancelled, InsuffFunds,
> InstBrandInvalid, InstNotValid, BadInstrument and Unspecified.
> 
	Recovery from Payments associated with Brand Dependent purchases is
only possible, if the Brand Selection component sent by the Merchant to the
Consumer does not change. In practice this means that the same Brand,
Protocol Amount and PayProtocol elements must be used. All that can change
is the Payment Instrument. Any other change will invalidate the Merchant's
Offer as a changed selection will invalidate the Offer Response.

> ----------
> From: 	David Burdett[SMTP:[email-masked]]
> Sent: 	25 May 1999 14:05
> To: 	Ietf Trade WG; [email-masked]
> Subject: 	RE: Error Handling
> 
> Most of Masaaki's questions are to do with "Transient Errors" and how to
> handle them. I think that Transient Errors can be caused by either
> business
> or technical reasons. For example:
> *	if a server that is handling a payment (e.g. a SET server, or a SCCD
> server) is busy, even if the IOTP server is not, then the valid response
> might be to tell the consumer to retry re-send exactly the same message
> some
> time later. This is a transient technical error.
> *	on the other hand if the payment instrument is not usable, for
> example there are insufficient funds on a credit card, then the consumer
> needs to select a different payment instrument. This is a transient
> business
> error since the transaction can continue with a different payment
> instrument.
> 
> This is consistent with the current defintions of the two types of error.
> *	"technical errors" which are independent of the meaning of the IOTP
> Message, and
> *	"business errors" which indicate that there is a problem specific to
> the process (e.g. payment or delivery) which is being carried out
> 
> Therefore I think that these two types of "transient" error need handling
> differently with:
> *	"transient technical errors" being handled by sending an Error
> Component to the the other Trading Role which results in the
> re-transmission
> of the original message at some slightly later point in time, and 
> *	"transient business errors" where a "response" message is sent which
> allows the other role, e.g. a Consumer, to retry with, for example,
> another
> payment instrument
> 
> Below are detailed changes to the IOTP spec, and responses to Masaaki's
> individual questions.
> 
> David
> 
> CHANGES TO THE SPEC
> 
> NEW SECTION - TRANSIENT TECHNICAL ERRORS
> Add a new section on "Transient Technical Errors" after the section
> 4.3.3.2
> on "Block and Component Consistency Checks" that says:
> 
> "If the block passes the "Block Level Attribute and Element Checks" and
> the
> "Block and Component Consistency Checks" then it is processed either by
> the
> IOTP Aware application or perhaps by some "back-end" system such as a
> payment server. During this processing some temporary failure may occur
> that
> can potentially be recovered by the other trading role re-transmitting, at
> some slightly later time, the original message that they sent. 
> 
> In this case the other role is informed of the Transient Error by sending
> them an Error Component (see section 6.19) with the Severity Attribute set
> to TransientError and the MinRetrySecs attribute set to some value
> suitable
> for the Transport Mechanism being used (see appropriate Transport
> Supplement).
> 
> Note that transient technical errors can be sent by any of the Trading
> Roles
> involved in transaction."
> 
> UPDATED SECTION - BLOCK BUSINESS ERRORS
> Clarify the section on Block Business Errors (section 4.3.3.3) to read ...
> 
> "If a business error occurs in a process such as a Payment or a Delivery,
> then the appropriate type of response block is returned containing a
> Status
> Component (see section 6.14) with the ProcessState attribute set to Failed
> and the CompletionCode indicating the nature of the problem.
> 
> Some business errors may be "transient" in that the Consumer role may be
> able to recover and complete the transaction in some other way. For
> example
> if the Credit Card that a consumer provided had insufficient funds for a
> purchase, then the Consumer may recover by using a different credit card.
> 
> Recovery from "transient" business errors is dependent on the
> CompletionCode. See the definition of the Status Component for what is
> possible.
> 
> Note that no Error Component or Error Block is generated for business
> errors."
> 
> REVISED COMPLETION CODES FOR STATUS COMPONENT
> Change the defintion of the CompletionCode attribute in the Status
> component
> to read ...
> 
> 	"Indicates how the process completed. Valid values for the
> CompletionCode are given below together with the conditions when it must
> be
> present and indications on when recovery from failures are possible."
> 
> Update sections 6.14.1 to 6.14.4 to indicate where recovery from transient
> business errors are possible, as follows:
> 
> 6.14.1 Offer Completion Codes
> The Completion Code is only required if the ProcessState attribute is set
> to
> Failed. The following table contains the valid values for the
> CompletionCode
> that may be used and indicates whether or not recovery might be possible.
> It
> is recommended that the StatusDesc attribute is used to provide further
> explanation where appropriate.
> *	Value		Description	
> *	"AuthError"	Authentication Error. The check of the
> Authentication Response which was carried out has failed. Recovery may be
> possible by the Consumer re-submitting a new Authentication Response Block
> with corrected information.	
> *	"ConsCancelled"	Consumer Cancelled. The Consumer decides to cancel
> the transaction for some reason. This code is only valid in a Status
> Component contained in a Cancel Block or an Inquiry Response Block. No
> recovery possible.	
> *	"MerchCancelled"	Offer Cancelled. The Merchant declines to
> generate an offer for some reason and cancels the transaction. This code
> is
> only valid in a Status Component contained in a Cancel Block or an Inquiry
> Response Block. No recovery possible.	
> *	"Unspecified"	Unspecified error. There is some unknown problem or
> error which does not fall into one of the other CompletionCodes. No
> recovery
> possible	
> 
> 6.14.2 Payment Completion Codes
> The CompletionCode is only required if the ProcessState attribute is set
> to
> Failed. The following table contains the valid values for the
> CompletionCode
> that may be used and indicates where recovery may be possible. It is
> recommended that the StatusDesc attribute is used by individual payment
> schemes to provide further explanation where appropriate.
> *	Value		Description	
> *	"BrandNotSupp"	Brand not supported. The payment brand is not
> supported by the Payment Handler. See below for recovery options.	
> *	"CurrNotSupp"	Currency not supported. The currency in which the
> payment is to be made is not supported by either the Payment Instrument or
> the Payment Handler. If the payment is Brand Independent, then the
> Consumer
> may recover by selecting a different currency, if available, or a
> different
> brand. Note that this may involve a different Payment Handler.	
> *	"ConsCancelled"	Consumer Cancelled. The Consumer decides to cancel
> the payment for some reason. This code is only valid in a Status Component
> contained in a Cancel Block or an Inquiry Response Block. Recovery is not
> possible.	
> *	"PaymtCancelled"	Payment Cancelled. The Payment Handler
> declines to complete the payment for some reason and cancels the
> transaction. This code is only valid in a Status Component contained in a
> Cancel Block or an Inquiry Response Block. See below for recovery options.
> 
> *	"AuthError"	Authentication Error. The Payment Scheme specific
> authentication check which was carried out has failed. Recovery may be
> possible. See the payment scheme supplement to determine what is allowed.
> 
> *	"InsuffFunds"	Insufficient funds. There are insufficient funds
> available for the payment to be made. See below for recovery options.	
> *	"InstBrandInvalid"	Payment Instrument not valid for Brand. A
> Payment Instrument is being used which does not correspond with the Brand
> selected. For example a Visa credit card is being used when MasterCard was
> selected as the Brand. See below for recovery options.	
> *	"InstNotValid"	Payment instrument not valid for trade. The Payment
> Instrument cannot be used for the proposed type of trade, for some reason.
> See below for recovery options.	
> *	"BadInstrument"	Bad instrument. There is a problem with the Payment
> Instrument being used which means that it is unable to be used for the
> payment. See below for recovery options.	
> *	"Unspecified"	Unspecified error. There is some unknown problem or
> error which does not fall into one of the other CompletionCodes. The
> StatusDesc attribute should provide the explanation of the cause. See
> below
> for recovery options.	
> 
> If the Payment is Brand Independent, then recovery may be possible for
> some
> values of the Completion Code, by the Consumer selecting a different
> payment
> brand. Note that this might involve a different Payment Handler. The codes
> to which this applies are: BrandNotSupp, PaymtCancelled, InsuffFunds,
> InstBrandInvalid, InstNotValid, BadInstrument and Unspecified.
> 
> Recovery from Payments associated with Brand Dependent purchases is not
> possible, since the Offer is dependent on a the entries selected from the
> Brand List. A changed selection will invalidate the Offer Response.
> 
> 6.14.3 Delivery Completion Codes
> The following table contains the valid values for the CompletionCode
> attribute for a Delivery. It is recommended that the StatusDesc attribute
> is
> used to provide further explanation where appropriate.
> *	Value		Description	
> *	"BackOrdered"	Back Ordered. The goods to be delivered are on order
> but they have not yet been received. Shipping will be arranged when they
> are
> received. This is only valid if ProcessState is CompletedOk. Recovery is
> not
> possible.	
> *	"PermNotAvail"	Permanently Not Available. The goods are permanently
> unavailable and cannot be re-ordered. This is only valid if ProcessState
> is
> Failed. Recovery is not possible.	
> *	"TempNotAvail"	Temporarily Not Available. The goods are temporarily
> unavailable and may become available if they can be ordered. This is only
> valid if ProcessState is CompletedOk. Recovery is not possible.	
> *	"ShipPending"	Shipping Pending. The goods are available and are
> scheduled for shipping but they have not yet been shipped. This is only
> valid if ProcessState is CompletedOk. Recovery is not possible.	
> *	"Shipped"	Goods Shipped. The goods have been shipped.
> Confirmation of delivery is awaited. This is only valid if ProcessState is
> CompletedOk. Recovery is not possible.	
> *	"ShippedNoConf"	Shipped - No Delivery Confirmation. The goods have
> been shipped but it is not possible to confirm delivery of the goods. This
> is only valid if ProcessState is CompletedOk. Recovery is not possible.
> 
> *	"ConsCancelled"	Consumer Cancelled. The Consumer decides to cancel
> the delivery for some reason. This code is only valid in a Status
> Component
> contained in a Cancel Block or an Inquiry Response Block. Recovery is not
> possible.	
> *	"DelivCancelled"	Delivery Cancelled. The Delivery Handler
> declines to complete the Delivery for some reason and cancels the
> transaction. This code is only valid in a Status Component contained in a
> Cancel Block or an Inquiry Response Block. 	
> *	"Confirmed"	Confirmed. All goods have been delivered and
> confirmation of their delivery has been received. This is only valid if
> ProcessState is CompletedOk. 	
> *	"Unspecified"	Unspecified error. There is some unknown problem or
> error which does not fall into one of the other CompletionCodes. The
> StatusDesc attribute should provide the explanation of the cause. Recovery
> is not possible.	
> 
> 	[Note]	Recovery from failed, or partially completed deliveries is
> not possible. The Consumer should use the Transaction Status Inquiry
> Transaction (see section 9.2.1) to determine up-to-date information on the
> current state.
> 	[Note End]	 
> 
> 6.14.4 Authentication Completion Codes
> The Completion Code is only required if the ProcessState attribute is set
> to
> Failed. The following table contains the valid values for the
> CompletionCode
> that may be used. It is recommended that the StatusDesc attribute is used
> to
> provide further explanation where appropriate.
> *	Value	Description	
> *	"AutEeCancel"	Authenticatee Cancel. The organisation being
> authenticated declines to be authenticated for some reason. This could be,
> for example because the signature on an Authentication Request was invalid
> or the Authenticator was not known or acceptable to the Authenticatee.
> Recovery is not possible.	
> *	"AutOrCancel"	Authenticator Cancel. The organisation requesting
> authentication declines to validate the Authentication Response received
> for
> some reason and cancels the transaction. Recovery is not possible.	
> *	"NoAuthData"	Authentication Request Not Available. The
> Authenticatee does not have the data that must be provided so that they
> may
> be successfully authenticated. For example a password may have been
> forgotten, the Authenticatee has not yet become a member, or a smart card
> token is not present. Recovery is not possible	
> *	"AuthFailed"	Authentication Failed. The Authenticator checked the
> Authentication Response but the authentication failed for some reason. For
> example a password may have been incorrect. Recovery may be possible by
> the
> Authenticatee re-sending a revised Authentication Response with corrected
> data.	
> *	"TradRolesIncon"	Trading Roles Inconsistent. The Trading
> Roles contained within the TradingRoleList attribute of the Authentication
> Request Component are inconsistent with the Trading Role which the
> Authenticatee is taking in the IOTP Transaction or is able to take.
> Examples
> of inconsistencies include: asking a PaymentHandler for DeliveryHandler
> information asking a Consumer for Merchant information Recovery may be
> possible by the Authenticator re-sending a revised Authentication Request
> Block with corrected information.	
> *	"Unspecified"	Unspecified error. There is some unknown problem or
> error which does not fall into one of the other CompletionCodes. Recovery
> is
> not possible.	
> 
> Comments on questions below ...
> > ----------
> > From: 	Masaaki Hiroya[SMTP:[email-masked]]
> > Reply To: 	[email-masked]
> > Sent: 	23 May 1999 00:59
> > To: 	[email-masked]
> > Subject: 	Error Handling
> > 
> > David and Werner
> > 
> > I have some questions about error handling.
> > 
> > [Question 1]
> > The business error handling described in IOTP Payment API Supplement
> > v1.0.1a
> > is inconsistent with the one described in IOTP specification v1.0-03.
> > 
> > In 4.3.3.3 Block Business Errors in the IOTP specification, there is a 
> > description as follows:
> > "If a business error occurs in a process such as a Payment or a
> >  Delivery, then the appropriate type of response block is returned. The
> >  Status Component (see section 6.14) within that response block
> >  indicates the error and its severity. No Error Component or Error Block
> >  is generated for business errors."
> > 
> > In 8.5.2 Intermediate Failures in the Payment API Supplement, there is a
> > description as follows:
> > "Transient Error: Failures, that might be resolved by the retransmission
> > of 
> > the appropriate IOTP message, belong to this class. 
> > ......
> > The behavior of the IOTP Application Core and IOTP Payment Bridge does
> not
> > depend on any further classification of this failure
> > (technical/business)."
> > 
> > In Fig.31 in 8.5.2, an business error with severity "TransientError" is 
> > notified from the Payment Handler to the Consumer by using an Error
> > message.
> > 
> > Which should be used, ErrorBlk and Error Component or PayRespBlk and
> > Status
> > Component in the case of business errors with "TransientError" severity?
> >  
> > If the Status Component should be used in any business error, it is
> > necessary
> > to add a "Severity" attribute to the Status Component, since there is no
> 
> > "Severity" attribute in the Status Component defined in 6.14 of the IOTP
> 
> > specification.
> ## Should be answered by earlier comments ##
> 
> > [Question 2]
> > This is a confirmation rather than a question.
> > After the Consumer receives the PayResp message with Severity "Transient
> > Error", the Consumer sends the retrying PayExch message in order to
> > continue
> > the transaction, doesn't it?
> > I think the answer is "yes" since there is the Server Role description 
> > in 4.4.1.9 of the IOTP specification as follows:
> >   "Transient Errors" are not stored so that if the original Response
> >   Block is received again, then it can be processed as if it had never
> >   been received before.
> > (In the above sentence, I think that "the original Response Block"
> should 
> >  be "the original Request Block" because the Server Role receives
> request
> >  blocks.)
> > ## Also answered by earlier comments and correct 4.4.1.9 to read ...
> "If any of the previous steps resulted in an error being detected and an
> Error Component being created then generate an Error Block (step 9)
> containing the Error Components that describe the error(s).
> 
> Unless the error is a "Transient Error", the Error Component(s) and the
> previous Request or Exchange block that caused the Error Components to be
> generated should be stored so that it can be reused if the action request
> is
> received again (step 6a).
> 
> "Transient Errors" are not stored so that if the original Request or
> Exchange Block is received again, then it can be processed as if it had
> never been received before."
> >  ##
> > 
> > [Question 3]
> > Additional Confirmation.  It is allowed to set different values from the
> > original request message to the retrying request message in the case of
> > business errors with "TransientError" severity, isn't it?
> > I think the answer should be "yes" since in the case of "Insufficient
> > Fund"
> > the Consumer may replace the e-cash card and then retry the transaction
> > so PaySchemeData in the original may be different from the one in the
> > retrying message.
> > 
> > The reason why I am confused is there is a description in 4.4.2.8 of
> > IOTP specification as follows:
> >   "Transient errors may be used to provide a manual or automatic
> >   resending (step 8b) of a block previously stored or alternatively may
> >   result in transaction cancellation."
> ## Answered by earlier comments ##
> 
> > [Question 4]
> > Some errors are not easy to classify as technical errors or business
> > errors.
> > If the payment server such as the SET Merchant connected to IOTP Payment
> > Handler server through its payment bridge has an internel processing
> > error,
> > is it a technical error or a business error with an completion code of
> > "BadInstrument"?  If the SET Merchant server doesn't respond to the
> > request
> > from the payment bridge of the Payment Handler, is it a technical error
> or
> > a business error with "BadInstrument" completion code?
> ## Answered by earlier comments ##
> 
> > [Question 5]
> > Accoring to the IOTP specification, PayReceipt Component is mandatory in
> 
> > PayRespBlk and it is required to use PayRespBlk in the case of business 
> > errors, 
> > But I think most payment schemes doesn't generate payment receipts when
> > errors
> > occur.  Taking it into consideration, the PayReceipt should be optional
> in
> > the 
> > PayRespBlk.  What do you think about it?
> ## I agree, Pay Receipt Component is only required if the Status component
> is "Completed OK".
> 
> The DTD is changed from ...
> 
> <!ELEMENT PayRespBlk (Status, PayReceipt, PaySchemeData?,
>      PaymentNote?, TradingRoleData*) >
> 
> ... to ...
> 
> <!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,
>      PaymentNote?, TradingRoleData*) >
> 
> ... and the description of the PayReceipt in the Pay Response Block is
> changed to ...
> 
> 	"Contains payment scheme specific data which can be used to verify
> the payment occurred. See section 7.10 Payment Receipt Component. It must
> be
> present if the ProcessState attribute of the Status Component is set to
> CompletedOk. PayReceipt is optional for other values as specified by the
> appropriate Payment Scheme supplement."
> 
> 
> > Regards
> > Masaaki
> > -----
> > Masaaki Hiroya
> > Systems Development Laboratory
> > Hitachi, Ltd.
> > tel: +81-44-959-0874
> > fax: +81-44-959-0856
> > email: [email-masked]
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> > 
> 
> **************************************************************************
> ********************
> 
> This Email and any attached files are confidential and may also be
> privileged. 
> If you are not the intended recipient, please notify the postmaster using
> email 
> address [email-masked] or call +44 171 557 5000 and ask for the 
> IT Helpdesk.  You should not copy this email and any attached files, use
> them 
> for any purpose or disclose the contents to any other person; all copies
> of the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> **************************************************************************
> *******************
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: Initial IOTP Brand Ids
Date: Wed, 26 May 1999 20:43:45 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

We need to build a list of IOTP Brand Ids for inclusion in the IOTP spec.

The initial list I have developed is as follows:
*	from SET Book 3 Formal Protocol Definition:
	- "IATA"
	- "Diners"
	- "AmericanExpress"
	- "JCB"
	- "Visa"
	- "MasterCard"
	- "Novus"

*	none SET brand ids:
	- "Mondex"
	- "Maestro"
	- "GeldKarte"

It would be good if the initial list is reasonably comprehensive and
accurate so if anyone wants more Brand Ids added (or any taken off !!) then
please let me know. Also do you think we need to specify a contact or
"owner" of the Brand as SET does.

Additional brands can, of course,  be added later using IANA procedures.

David

> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Smith, Chris" <[email-masked]>
To: Ietf Trade WG <[email-masked]>,  David Burdett <[email-masked]>
Subject: RE: Otp -> Iotp ??
Date: Wed, 26 May 1999 09:55:00 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BEA780.C31C6CA8
Content-Type: text/plain

As a courtesy, could you mail a (non-normative) list of these changes to 
the mailing list? It seems that the indicated Elements, Attributes and 
the single attribute value "OtpTransaction" are the only items, right?

It would help those of us who are actually starting to use the other 
values. DRAFT, yes, but this would guarantee a complete break between 
DRAFT and final, affecting every piece of IOTP code that works with the 
message. (My DOM calls regularly start at the base <OtpMessage> and work 
down.)

It's a simple change now, and if we use a version indicator such as 
"DRAFT1.0" then we can easily detect the difference as final 1.0 
versions start to show up.

...Chris

______________________________ Reply Separator
_________________________________
Subject: Otp -> Iotp ??
Author:  "David Burdett" [SMTP:[email-masked]] at Internet
Date:    1999/05/17 09:17 PM

There are still some element or attribute names in the DTD that contain 
"Otp" rather than "Iotp". Do we want to change them? My view is yes, 
although if anyone strongly objects I'm open to persuasion.

Names to which this applies are:
*     OtpMessage,
*     OtpTransId,
*     OtpTransType,
*     RespOtpMsg,
*     OtpMsgIdPrefix,
*     OtpMsgRef,
*     LastReceivedOtpMsgRef,
*     LastSentOtpMsgRef

The first is an element. The rest are attributes.

Thoughts?

David

------_=_NextPart_001_01BEA780.C31C6CA8
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2232.0">
<TITLE>RE: Otp -&gt; Iotp ??</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>As a courtesy, could you mail a (non-normative) list of these changes to </FONT>
<BR><FONT SIZE=2>the mailing list? It seems that the indicated Elements, Attributes and </FONT>
<BR><FONT SIZE=2>the single attribute value &quot;OtpTransaction&quot; are the only items, right?</FONT>
</P>

<P><FONT SIZE=2>It would help those of us who are actually starting to use the other </FONT>
<BR><FONT SIZE=2>values. DRAFT, yes, but this would guarantee a complete break between </FONT>
<BR><FONT SIZE=2>DRAFT and final, affecting every piece of IOTP code that works with the </FONT>
<BR><FONT SIZE=2>message. (My DOM calls regularly start at the base &lt;OtpMessage&gt; and work </FONT>
<BR><FONT SIZE=2>down.)</FONT>
</P>

<P><FONT SIZE=2>It's a simple change now, and if we use a version indicator such as </FONT>
<BR><FONT SIZE=2>&quot;DRAFT1.0&quot; then we can easily detect the difference as final 1.0 </FONT>
<BR><FONT SIZE=2>versions start to show up.</FONT>
</P>

<P><FONT SIZE=2>...Chris</FONT>
</P>

<P><FONT SIZE=2>______________________________ Reply Separator _________________________________</FONT>
<BR><FONT SIZE=2>Subject: Otp -&gt; Iotp ??</FONT>
<BR><FONT SIZE=2>Author:&nbsp; &quot;David Burdett&quot; [SMTP:[email-masked]] at Internet</FONT>
<BR><FONT SIZE=2>Date:&nbsp;&nbsp;&nbsp; 1999/05/17 09:17 PM</FONT>
</P>
<BR>

<P><FONT SIZE=2>There are still some element or attribute names in the DTD that contain </FONT>
<BR><FONT SIZE=2>&quot;Otp&quot; rather than &quot;Iotp&quot;. Do we want to change them? My view is yes, </FONT>
<BR><FONT SIZE=2>although if anyone strongly objects I'm open to persuasion.</FONT>
</P>

<P><FONT SIZE=2>Names to which this applies are:</FONT>
<BR><FONT SIZE=2>*&nbsp;&nbsp;&nbsp;&nbsp; OtpMessage,</FONT>
<BR><FONT SIZE=2>*&nbsp;&nbsp;&nbsp;&nbsp; OtpTransId,</FONT>
<BR><FONT SIZE=2>*&nbsp;&nbsp;&nbsp;&nbsp; OtpTransType,</FONT>
<BR><FONT SIZE=2>*&nbsp;&nbsp;&nbsp;&nbsp; RespOtpMsg,</FONT>
<BR><FONT SIZE=2>*&nbsp;&nbsp;&nbsp;&nbsp; OtpMsgIdPrefix,</FONT>
<BR><FONT SIZE=2>*&nbsp;&nbsp;&nbsp;&nbsp; OtpMsgRef,</FONT>
<BR><FONT SIZE=2>*&nbsp;&nbsp;&nbsp;&nbsp; LastReceivedOtpMsgRef,</FONT>
<BR><FONT SIZE=2>*&nbsp;&nbsp;&nbsp;&nbsp; LastSentOtpMsgRef</FONT>
</P>

<P><FONT SIZE=2>The first is an element. The rest are attributes.</FONT>
</P>

<P><FONT SIZE=2>Thoughts?</FONT>
</P>

<P><FONT SIZE=2>David</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BEA780.C31C6CA8--
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
cc: [email-masked]
Subject: New SET/IOTP Draft
Date: Tue, 25 May 1999 22:13:39 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The latest version of the IOTP SET Supplement draft is available at
<ftp://ftp.pothole.com/pub/ietf-trade/setiotp_ver099.zip>

Thanks,
Donald

=====================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668     [email-masked]
 65 Shindegan Hill Road, RR#1  +1 914-784-7913(work)  [email-masked]
 Carmel, NY 10512 USA
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Yoshiaki KAWATSURA <[email-masked]>,  "Kent M. Davidson" <[email-masked]>
Cc: Ietf Trade WG <[email-masked]>, [email-masked]
Subject: RE: Comments for IOTP DSIG (addition).
Date: Wed, 26 May 1999 00:01:49 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I think the detail of  how to sign (i.e. generate a hash) should be in the
Dsig document.

David

> ----------
> From: 	Kent M. Davidson[SMTP:[email-masked]]
> Sent: 	25 May 1999 10:44
> To: 	Yoshiaki KAWATSURA; [email-masked]
> Cc: 	[email-masked]; [email-masked];
> [email-masked]
> Subject: 	Re: Comments for IOTP DSIG (addition).
> 
> Yoshiaki-san:
> 
> I am revising the document today, and your suggestion to add clarity to
> the document is a good one. I will make sure it is obvious in the language
> surrounding signing.
> 
> -Kent.
> 
> At 03:23 PM 5/25/99 +0900, Yoshiaki KAWATSURA wrote:
> >David (and Kent), 
> >
> >We can understand where we have to sign because of the following
> >description in section 6.17:
> >
> >  o signs the Manifest element using the optional certificate
> >   identified in the Certificate element within the Signature
> >   Block placing the result in a Value element within a Signature
> >   Component
> >
> >But there is no description(or definition) about how to sign. 
> >
> >I and Hiroya-san think it is obvious that "signs the Manifest element"
> >means to make a hash value of the Manifest element and encrypt the
> >hash value of the Manifest element.
> >
> >In order to avoid ambiguity, it may be better to describe how to sign
> >the Manifest element such as the above or more detail in IOTP (and/or
> >IOTP DSIG) document.
> >
> >What do you think it is too obvious to describe how to sign?
> >--
> >Yoshiaki Kawatsura and Masaaki Hiroya,  Hitachi, Ltd.
> >
> >
> >
> >-----------------------------------------------------------------------
> >Message addressed to: [email-masked]
> >Archive available at: http://www.elistx.com/archives/ietf-trade/
> >To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> >body to: [email-masked]
> > 
> _____________________________________________________________
> Kent M. Davidson
> VP Engineering
> Differential, Inc.
> http://www.differential.com
> main (650)426-1100
> fax  (650)426-1101
> 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Yoshiaki KAWATSURA <[email-masked]>
Cc: Ietf Trade WG <[email-masked]>
Subject: RE: PayReceiptRefs (Problem of IOTP Spec.)
Date: Wed, 26 May 1999 00:01:40 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I agree, since it is possible that all the Packaged Contents that contain
bits of the Payment Receipt could have been sent in earlier messages,
therefore additional Packaged Content entries are not required.

So  your change as described below will be made.

David

> ----------
> From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> Sent: 	25 May 1999 00:27
> To: 	[email-masked]
> Cc: 	[email-masked]
> Subject: 	RE: PayReceiptRefs (Problem of IOTP Spec.)
> 
> David,
> 
> I believe some payment methods would use only the PayReceiptNameRefs
> in the PayReceipt Component as the payment receipt, so that
> PackagedContents does not need to be used.
>  
> Thus, would you change the PayReceipt Component as follows? :
>  
> From:
> <!-- PAYMENT RECEIPT COMPONENT -->
> <!ELEMENT PayReceipt (PackagedContent+) >
> 
> To:
> <!-- PAYMENT RECEIPT COMPONENT -->
> <!ELEMENT PayReceipt (PackagedContent*) >
> 
> And we also should add the description saying that "At least the
> PackagedContent or PayReceiptNameRefs has to exist in the
> PayReceipt Component."
>  
>   What do you think about?
>  
>  
> >>>>> Tue, 18 May 1999 02:16:57 +0100,
> 	David Burdett <[email-masked]> said:
> 
> > Yoshiaki
> > 
> > I think I understand where you're coming from. The difficulty is all
> around
> > how the payment software (you refer to it as the payment bridge)
> identifies
> > what data it has returned as packaged content, forms the "Payment
> Receipt".
> > 
> > For those reading this that are not familiar with this part of the
> > specification, there are two parts of the payment response component
> that
> > contain information about a payment:
> > *	the Payment Receipt (that Yoshiaki is discussing) that contains a
> > record of the payment either from:
> > 	*	**Payment Protocol** or other **Payment Software** generated
> > information if the payment protocol can generate this type of
> information,
> > or
> > 	*	HTML or text data if it cannot
> > *	the Payment Note, that contains only human readable information
> > about the payment - as text or HTML - and may include additional
> information
> > such as account balance after a withdrawal.
> > 
> > The key difference is that Payment Receipt data (unlike a Payment Note)
> can
> > sometines be checked by software that understands the payment method
> being
> > used, to *prove* that the payment occurred at the *payment protocol*
> level.
> > For example both SET and Mondex can digitally sign data using payment
> method
> > specific certificates that can be independently checked after the event
> by
> > SET/Mondex aware software.
> > 
> > Anyway to get back to Yoshiaki's ideas ...
> > 
> > In order to generate a Payment Receipt from a payment protocol message,
> the
> > payment software has to be able to identify which Packaged Content
> elements
> > it has returned make up the Payment Receipt. Part of the difficulty is
> that
> > the Payment Software should be unaware of IOTP, if IOTP is to transport
> a
> > payment protocol completely transparently. As the current specification
> > requires that PaymentReceiptRefs, only refers to Payment Scheme
> Components,
> > it is difficult for the software to do this.
> > 
> > I think that Yoshiaki is suggesting instead, that the Payment Software
> > returns the name, or some other code, for a payment protocol message and
> > identifies, at the same time whether or not this particular data forms
> part
> > (or potentially all) of the receipt.
> > 
> > Using the name of the Packaged Content that contains the Payment
> Protocol
> > data, is a reasonable idea as the name can be set by the Payment
> Software
> > (for example it could be message name or number of a protocol message).
> > 
> > However Yoshiaki suggests that the "Name" should be "unique within the
> > transaction". I don't think this is a good idea since, for example,
> another
> > role, such as a Delivery Handler, might coincidentally use the same name
> and
> > since he knows nothing of the detail of the payment there could be
> > duplicate. Instead I suggest that the Name must be unique within a
> Payment
> > and to facilitate this add PaymentRef as an attribute of the Payment
> Scheme
> > Component.
> > 
> > So I suggest the following as changes to the specification ...
> > 
> > 1. Change the PayReceiptRefs attribute within the PayReceipt component
> to
> > PayReceiptNameRefs
> > 
> > 2. Remove the definition of the PayReceiptRefs attribute in the Pay
> Receipt
> > Component and add a PayReceiptNameRefs attribute with a definition as
> > follows ...
> > 		"Optionally contains a list of the values of the Name
> > attributes of Packaged Content elements that together make up the
> receipt.
> > The Packaged Content elements are contained either within:
> > 		*	Payment Scheme Data components exchanged between the
> > Payment Handler and the Consumer roles during the Payment, and/or
> > 		*	the Payment Receipt component itself.
> > 		Note that:
> > 		*	each payment scheme defines in its supplement the
> > Names of the Packaged Content elements that must be listed in this
> attribute
> > (if any). 
> > 		*	if a Payment Scheme Component contains Packaged
> > Content elements with a name that matches a name within
> PaymentReceiptRefs,
> > then those Payment Scheme Components must be referenced by Digests in
> the
> > Payment Response signature component (if such a signature is being used)
> > 		The client software should save all the components
> > referenced so that the payment receipt can be reconstructed when
> required."
> > 
> > 3. Add PaymentRef as a Required attribute on PaymentSchemeComponent to
> > identify the Payment Component to which a Payment Scheme Component is
> > related, so that is easier to check that the names on the
> PackagedContent
> > elements within the Payment Scheme Components for a payment are unique.
> > 
> > 4. Change the description of the PackagedContent within the
> PaySchemeData
> > component to read ...
> > 		"Contains payment scheme protocol information as Packaged
> > Content elements (see section 3.7). See the payment scheme supplement
> for
> > the definition of its content.
> > 		Note that:
> > 		*	the values of the Name attribute of each packaged
> > content element are defined by the Payment Protocol Supplement
> > 		*	the value of each Name must be unique within a
> > Payment where a Payment is defined as all Payment Scheme or Payment
> Receipt
> > Components with the same value of the PaymentRef attribute"
> > 
> > 5. Change the description of the PackagedContent within the PayReceipt
> to
> > read ...
> > 		Contains payment scheme payment receipt information as
> > Packaged Content elements (see section 3.7). See the payment scheme
> > supplement for the definition of its content.
> > 		Note that:
> > 		*	the values of the Name attribute of each packaged
> > content element are defined by the Payment Protocol Supplement
> > 		*	the value of each Name must be unique within a
> > Payment where a Payment is defined as all Payment Scheme or Payment
> Receipt
> > Components,  with the same value of the PaymentRef attribute
> > 
> > 5. The DTD for the PaymentReceipt and PaymentSchemeData components
> become
> > ...
> > <!-- PAYMENT SCHEME COMPONENT -->
> > <!ELEMENT PaySchemeData (PackagedContent+) >
> > <!ATTLIST PaySchemeData
> >  ID                 ID      #REQUIRED
> >  PaymentRef         NMTOKEN #REQUIRED <<<<<NEW
> >  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 <<<<CHANGED
> >  ContentSoftwareId  CDATA   #IMPLIED >
> > 
> > Any questions let me know.
> > 
> > David
> > 
> > 
> > 
> > > ----------
> > > From: 	Yoshiaki KAWATSURA[SMTP:@bisd.hitachi.co.jp]
> > > Sent: 	02 May 1999 08:30
> > > To: 	[email-masked]
> > > Cc: 	[email-masked]; @bisd.hitachi.co.jp
> > > Subject: 	PayReceiptRefs (Problem of IOTP Spec.)
> > > 
> > > There is a problem for PayReceiptRefs in PayReceipt component in the
> > > current IOTP specification.
> > > 
> > > Problem:
> > > In the current specification, we can not use the PayReceiptRefs.  IOTP
> > > Payment Bridge of the Payment Handler can not set the PayReceiptRefs
> > > because the Bridge can not know IOTP Component ID.  IOTP Payment
> Bridge
> > > of the Consumer can not also get the components correspond to IDs
> > > which is included in the PayReceiptRefs.
> > > 
> > > So I suggest the following changes.
> > >  
> > > Change:
> > > (a) Change PayReceiptRefs to PayReceiptRefNames element.
> > >     (PayReceiptRefs is dropped)
> > > (b) PayReceiptRefNames defines as the list of Name element in
> > >     PackagedContent of PaySchemeData component.
> > > (c) The Name element in PackagedContent must be unique in the
> transaction.
> > > (d) The PaySchemeData Component, that Name element is the same ones 
> > > in the token of PayReceiptRefNames, must be hashed and signed in the
> > > Payment
> > > Response signature component.
> > > 
> > > Sequence of Process:
> > > (1) The Payment Hander Payment Bridge set the PayReceiptRefNames.
> > > (2) Payment Handler OAC hashes and signs to the corresponding
> > > PaySchemeData.
> > > (3) Consumer OAC checks the signatures.
> > > (4) OAC picks up the PackagedContents which include the same Name
> > >     element in PayReceiptRefNames and passes them to the Payment
> Bridge as
> > >     PayReceiptPackagedContent in the CheckPayReceipt.
> > > 
> > > What do you think this?
> > > 
> > > P.S. I can not response till 9th May because I will go to Thai Land in
> > > vacation.
> > >  
> > > Thanks,
> > > --
> > > Yoshiaki Kawatsura
> > > 
> > 
> >
> **************************************************************************
> ********************
> > 
> > This Email and any attached files are confidential and may also be
> privileged. 
> > If you are not the intended recipient, please notify the postmaster
> using email 
> > address [email-masked] or call +44 171 557 5000 and ask for the 
> > IT Helpdesk.  You should not copy this email and any attached files, use
> them 
> > for any purpose or disclose the contents to any other person; all copies
> of the 
> > Email and associated files in your possession should be destroyed.
> > 
> > Mondex International Limited
> > 47-53 Cannon Street
> > London EC4M 5SQ
> > United Kingdom
> > Registered No: 3122085, England
> > 
> > Phone:          +44 171 557 5000
> > Fax:            +44 171 557 5200
> > Email:          [email-masked]
> > WebSite:        http://www.mondexinternational.com
> > 
> >
> **************************************************************************
> *******************
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> > 
> > 
> 
> ----
> Yoshiaki Kawatsura : E-mail [email-masked]
>  Business & Information Systems Development Devision, Hitachi,Ltd.
> Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>, [email-masked]
Subject: RE: Error Handling
Date: Tue, 25 May 1999 22:05:32 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Most of Masaaki's questions are to do with "Transient Errors" and how to
handle them. I think that Transient Errors can be caused by either business
or technical reasons. For example:
*	if a server that is handling a payment (e.g. a SET server, or a SCCD
server) is busy, even if the IOTP server is not, then the valid response
might be to tell the consumer to retry re-send exactly the same message some
time later. This is a transient technical error.
*	on the other hand if the payment instrument is not usable, for
example there are insufficient funds on a credit card, then the consumer
needs to select a different payment instrument. This is a transient business
error since the transaction can continue with a different payment
instrument.

This is consistent with the current defintions of the two types of error.
*	"technical errors" which are independent of the meaning of the IOTP
Message, and
*	"business errors" which indicate that there is a problem specific to
the process (e.g. payment or delivery) which is being carried out

Therefore I think that these two types of "transient" error need handling
differently with:
*	"transient technical errors" being handled by sending an Error
Component to the the other Trading Role which results in the re-transmission
of the original message at some slightly later point in time, and 
*	"transient business errors" where a "response" message is sent which
allows the other role, e.g. a Consumer, to retry with, for example, another
payment instrument

Below are detailed changes to the IOTP spec, and responses to Masaaki's
individual questions.

David

CHANGES TO THE SPEC

NEW SECTION - TRANSIENT TECHNICAL ERRORS
Add a new section on "Transient Technical Errors" after the section 4.3.3.2
on "Block and Component Consistency Checks" that says:

"If the block passes the "Block Level Attribute and Element Checks" and the
"Block and Component Consistency Checks" then it is processed either by the
IOTP Aware application or perhaps by some "back-end" system such as a
payment server. During this processing some temporary failure may occur that
can potentially be recovered by the other trading role re-transmitting, at
some slightly later time, the original message that they sent. 

In this case the other role is informed of the Transient Error by sending
them an Error Component (see section 6.19) with the Severity Attribute set
to TransientError and the MinRetrySecs attribute set to some value suitable
for the Transport Mechanism being used (see appropriate Transport
Supplement).

Note that transient technical errors can be sent by any of the Trading Roles
involved in transaction."

UPDATED SECTION - BLOCK BUSINESS ERRORS
Clarify the section on Block Business Errors (section 4.3.3.3) to read ...

"If a business error occurs in a process such as a Payment or a Delivery,
then the appropriate type of response block is returned containing a Status
Component (see section 6.14) with the ProcessState attribute set to Failed
and the CompletionCode indicating the nature of the problem.

Some business errors may be "transient" in that the Consumer role may be
able to recover and complete the transaction in some other way. For example
if the Credit Card that a consumer provided had insufficient funds for a
purchase, then the Consumer may recover by using a different credit card.

Recovery from "transient" business errors is dependent on the
CompletionCode. See the definition of the Status Component for what is
possible.

Note that no Error Component or Error Block is generated for business
errors."

REVISED COMPLETION CODES FOR STATUS COMPONENT
Change the defintion of the CompletionCode attribute in the Status component
to read ...

	"Indicates how the process completed. Valid values for the
CompletionCode are given below together with the conditions when it must be
present and indications on when recovery from failures are possible."

Update sections 6.14.1 to 6.14.4 to indicate where recovery from transient
business errors are possible, as follows:

6.14.1 Offer Completion Codes
The Completion Code is only required if the ProcessState attribute is set to
Failed. The following table contains the valid values for the CompletionCode
that may be used and indicates whether or not recovery might be possible. It
is recommended that the StatusDesc attribute is used to provide further
explanation where appropriate.
*	Value		Description	
*	"AuthError"	Authentication Error. The check of the
Authentication Response which was carried out has failed. Recovery may be
possible by the Consumer re-submitting a new Authentication Response Block
with corrected information.	
*	"ConsCancelled"	Consumer Cancelled. The Consumer decides to cancel
the transaction for some reason. This code is only valid in a Status
Component contained in a Cancel Block or an Inquiry Response Block. No
recovery possible.	
*	"MerchCancelled"	Offer Cancelled. The Merchant declines to
generate an offer for some reason and cancels the transaction. This code is
only valid in a Status Component contained in a Cancel Block or an Inquiry
Response Block. No recovery possible.	
*	"Unspecified"	Unspecified error. There is some unknown problem or
error which does not fall into one of the other CompletionCodes. No recovery
possible	

6.14.2 Payment Completion Codes
The CompletionCode is only required if the ProcessState attribute is set to
Failed. The following table contains the valid values for the CompletionCode
that may be used and indicates where recovery may be possible. It is
recommended that the StatusDesc attribute is used by individual payment
schemes to provide further explanation where appropriate.
*	Value		Description	
*	"BrandNotSupp"	Brand not supported. The payment brand is not
supported by the Payment Handler. See below for recovery options.	
*	"CurrNotSupp"	Currency not supported. The currency in which the
payment is to be made is not supported by either the Payment Instrument or
the Payment Handler. If the payment is Brand Independent, then the Consumer
may recover by selecting a different currency, if available, or a different
brand. Note that this may involve a different Payment Handler.	
*	"ConsCancelled"	Consumer Cancelled. The Consumer decides to cancel
the payment for some reason. This code is only valid in a Status Component
contained in a Cancel Block or an Inquiry Response Block. Recovery is not
possible.	
*	"PaymtCancelled"	Payment Cancelled. The Payment Handler
declines to complete the payment for some reason and cancels the
transaction. This code is only valid in a Status Component contained in a
Cancel Block or an Inquiry Response Block. See below for recovery options.

*	"AuthError"	Authentication Error. The Payment Scheme specific
authentication check which was carried out has failed. Recovery may be
possible. See the payment scheme supplement to determine what is allowed.

*	"InsuffFunds"	Insufficient funds. There are insufficient funds
available for the payment to be made. See below for recovery options.	
*	"InstBrandInvalid"	Payment Instrument not valid for Brand. A
Payment Instrument is being used which does not correspond with the Brand
selected. For example a Visa credit card is being used when MasterCard was
selected as the Brand. See below for recovery options.	
*	"InstNotValid"	Payment instrument not valid for trade. The Payment
Instrument cannot be used for the proposed type of trade, for some reason.
See below for recovery options.	
*	"BadInstrument"	Bad instrument. There is a problem with the Payment
Instrument being used which means that it is unable to be used for the
payment. See below for recovery options.	
*	"Unspecified"	Unspecified error. There is some unknown problem or
error which does not fall into one of the other CompletionCodes. The
StatusDesc attribute should provide the explanation of the cause. See below
for recovery options.	

If the Payment is Brand Independent, then recovery may be possible for some
values of the Completion Code, by the Consumer selecting a different payment
brand. Note that this might involve a different Payment Handler. The codes
to which this applies are: BrandNotSupp, PaymtCancelled, InsuffFunds,
InstBrandInvalid, InstNotValid, BadInstrument and Unspecified.

Recovery from Payments associated with Brand Dependent purchases is not
possible, since the Offer is dependent on a the entries selected from the
Brand List. A changed selection will invalidate the Offer Response.

6.14.3 Delivery Completion Codes
The following table contains the valid values for the CompletionCode
attribute for a Delivery. It is recommended that the StatusDesc attribute is
used to provide further explanation where appropriate.
*	Value		Description	
*	"BackOrdered"	Back Ordered. The goods to be delivered are on order
but they have not yet been received. Shipping will be arranged when they are
received. This is only valid if ProcessState is CompletedOk. Recovery is not
possible.	
*	"PermNotAvail"	Permanently Not Available. The goods are permanently
unavailable and cannot be re-ordered. This is only valid if ProcessState is
Failed. Recovery is not possible.	
*	"TempNotAvail"	Temporarily Not Available. The goods are temporarily
unavailable and may become available if they can be ordered. This is only
valid if ProcessState is CompletedOk. Recovery is not possible.	
*	"ShipPending"	Shipping Pending. The goods are available and are
scheduled for shipping but they have not yet been shipped. This is only
valid if ProcessState is CompletedOk. Recovery is not possible.	
*	"Shipped"	Goods Shipped. The goods have been shipped.
Confirmation of delivery is awaited. This is only valid if ProcessState is
CompletedOk. Recovery is not possible.	
*	"ShippedNoConf"	Shipped - No Delivery Confirmation. The goods have
been shipped but it is not possible to confirm delivery of the goods. This
is only valid if ProcessState is CompletedOk. Recovery is not possible.	
*	"ConsCancelled"	Consumer Cancelled. The Consumer decides to cancel
the delivery for some reason. This code is only valid in a Status Component
contained in a Cancel Block or an Inquiry Response Block. Recovery is not
possible.	
*	"DelivCancelled"	Delivery Cancelled. The Delivery Handler
declines to complete the Delivery for some reason and cancels the
transaction. This code is only valid in a Status Component contained in a
Cancel Block or an Inquiry Response Block. 	
*	"Confirmed"	Confirmed. All goods have been delivered and
confirmation of their delivery has been received. This is only valid if
ProcessState is CompletedOk. 	
*	"Unspecified"	Unspecified error. There is some unknown problem or
error which does not fall into one of the other CompletionCodes. The
StatusDesc attribute should provide the explanation of the cause. Recovery
is not possible.	

	[Note]	Recovery from failed, or partially completed deliveries is
not possible. The Consumer should use the Transaction Status Inquiry
Transaction (see section 9.2.1) to determine up-to-date information on the
current state.
	[Note End]	 

6.14.4 Authentication Completion Codes
The Completion Code is only required if the ProcessState attribute is set to
Failed. The following table contains the valid values for the CompletionCode
that may be used. It is recommended that the StatusDesc attribute is used to
provide further explanation where appropriate.
*	Value	Description	
*	"AutEeCancel"	Authenticatee Cancel. The organisation being
authenticated declines to be authenticated for some reason. This could be,
for example because the signature on an Authentication Request was invalid
or the Authenticator was not known or acceptable to the Authenticatee.
Recovery is not possible.	
*	"AutOrCancel"	Authenticator Cancel. The organisation requesting
authentication declines to validate the Authentication Response received for
some reason and cancels the transaction. Recovery is not possible.	
*	"NoAuthData"	Authentication Request Not Available. The
Authenticatee does not have the data that must be provided so that they may
be successfully authenticated. For example a password may have been
forgotten, the Authenticatee has not yet become a member, or a smart card
token is not present. Recovery is not possible	
*	"AuthFailed"	Authentication Failed. The Authenticator checked the
Authentication Response but the authentication failed for some reason. For
example a password may have been incorrect. Recovery may be possible by the
Authenticatee re-sending a revised Authentication Response with corrected
data.	
*	"TradRolesIncon"	Trading Roles Inconsistent. The Trading
Roles contained within the TradingRoleList attribute of the Authentication
Request Component are inconsistent with the Trading Role which the
Authenticatee is taking in the IOTP Transaction or is able to take. Examples
of inconsistencies include: asking a PaymentHandler for DeliveryHandler
information asking a Consumer for Merchant information Recovery may be
possible by the Authenticator re-sending a revised Authentication Request
Block with corrected information.	
*	"Unspecified"	Unspecified error. There is some unknown problem or
error which does not fall into one of the other CompletionCodes. Recovery is
not possible.	

Comments on questions below ...
> ----------
> From: 	Masaaki Hiroya[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	23 May 1999 00:59
> To: 	[email-masked]
> Subject: 	Error Handling
> 
> David and Werner
> 
> I have some questions about error handling.
> 
> [Question 1]
> The business error handling described in IOTP Payment API Supplement
> v1.0.1a
> is inconsistent with the one described in IOTP specification v1.0-03.
> 
> In 4.3.3.3 Block Business Errors in the IOTP specification, there is a 
> description as follows:
> "If a business error occurs in a process such as a Payment or a
>  Delivery, then the appropriate type of response block is returned. The
>  Status Component (see section 6.14) within that response block
>  indicates the error and its severity. No Error Component or Error Block
>  is generated for business errors."
> 
> In 8.5.2 Intermediate Failures in the Payment API Supplement, there is a
> description as follows:
> "Transient Error: Failures, that might be resolved by the retransmission
> of 
> the appropriate IOTP message, belong to this class. 
> ......
> The behavior of the IOTP Application Core and IOTP Payment Bridge does not
> depend on any further classification of this failure
> (technical/business)."
> 
> In Fig.31 in 8.5.2, an business error with severity "TransientError" is 
> notified from the Payment Handler to the Consumer by using an Error
> message.
> 
> Which should be used, ErrorBlk and Error Component or PayRespBlk and
> Status
> Component in the case of business errors with "TransientError" severity?
>  
> If the Status Component should be used in any business error, it is
> necessary
> to add a "Severity" attribute to the Status Component, since there is no 
> "Severity" attribute in the Status Component defined in 6.14 of the IOTP 
> specification.
## Should be answered by earlier comments ##

> [Question 2]
> This is a confirmation rather than a question.
> After the Consumer receives the PayResp message with Severity "Transient
> Error", the Consumer sends the retrying PayExch message in order to
> continue
> the transaction, doesn't it?
> I think the answer is "yes" since there is the Server Role description 
> in 4.4.1.9 of the IOTP specification as follows:
>   "Transient Errors" are not stored so that if the original Response
>   Block is received again, then it can be processed as if it had never
>   been received before.
> (In the above sentence, I think that "the original Response Block" should 
>  be "the original Request Block" because the Server Role receives request
>  blocks.)
> ## Also answered by earlier comments and correct 4.4.1.9 to read ...
"If any of the previous steps resulted in an error being detected and an
Error Component being created then generate an Error Block (step 9)
containing the Error Components that describe the error(s).

Unless the error is a "Transient Error", the Error Component(s) and the
previous Request or Exchange block that caused the Error Components to be
generated should be stored so that it can be reused if the action request is
received again (step 6a).

"Transient Errors" are not stored so that if the original Request or
Exchange Block is received again, then it can be processed as if it had
never been received before."
>  ##
> 
> [Question 3]
> Additional Confirmation.  It is allowed to set different values from the
> original request message to the retrying request message in the case of
> business errors with "TransientError" severity, isn't it?
> I think the answer should be "yes" since in the case of "Insufficient
> Fund"
> the Consumer may replace the e-cash card and then retry the transaction
> so PaySchemeData in the original may be different from the one in the
> retrying message.
> 
> The reason why I am confused is there is a description in 4.4.2.8 of
> IOTP specification as follows:
>   "Transient errors may be used to provide a manual or automatic
>   resending (step 8b) of a block previously stored or alternatively may
>   result in transaction cancellation."
## Answered by earlier comments ##

> [Question 4]
> Some errors are not easy to classify as technical errors or business
> errors.
> If the payment server such as the SET Merchant connected to IOTP Payment
> Handler server through its payment bridge has an internel processing
> error,
> is it a technical error or a business error with an completion code of
> "BadInstrument"?  If the SET Merchant server doesn't respond to the
> request
> from the payment bridge of the Payment Handler, is it a technical error or
> a business error with "BadInstrument" completion code?
## Answered by earlier comments ##

> [Question 5]
> Accoring to the IOTP specification, PayReceipt Component is mandatory in 
> PayRespBlk and it is required to use PayRespBlk in the case of business 
> errors, 
> But I think most payment schemes doesn't generate payment receipts when
> errors
> occur.  Taking it into consideration, the PayReceipt should be optional in
> the 
> PayRespBlk.  What do you think about it?
## I agree, Pay Receipt Component is only required if the Status component
is "Completed OK".

The DTD is changed from ...

<!ELEMENT PayRespBlk (Status, PayReceipt, PaySchemeData?,
     PaymentNote?, TradingRoleData*) >

... to ...

<!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,
     PaymentNote?, TradingRoleData*) >

... and the description of the PayReceipt in the Pay Response Block is
changed to ...

	"Contains payment scheme specific data which can be used to verify
the payment occurred. See section 7.10 Payment Receipt Component. It must be
present if the ProcessState attribute of the Status Component is set to
CompletedOk. PayReceipt is optional for other values as specified by the
appropriate Payment Scheme supplement."

> Regards
> Masaaki
> -----
> Masaaki Hiroya
> Systems Development Laboratory
> Hitachi, Ltd.
> tel: +81-44-959-0874
> fax: +81-44-959-0856
> email: [email-masked]
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Date: Tue, 25 May 1999 10:44:35 -0700
To: Yoshiaki KAWATSURA <[email-masked]>,  [email-masked]
From: "Kent M. Davidson" <[email-masked]>
Subject: Re: Comments for IOTP DSIG (addition).
Cc: [email-masked], [email-masked],  [email-masked]
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Yoshiaki-san:

I am revising the document today, and your suggestion to add clarity to the document is a good one. I will make sure it is obvious in the language surrounding signing.

-Kent.

At 03:23 PM 5/25/99 +0900, Yoshiaki KAWATSURA wrote:
>David (and Kent), 
>
>We can understand where we have to sign because of the following
>description in section 6.17:
>
>  o signs the Manifest element using the optional certificate
>   identified in the Certificate element within the Signature
>   Block placing the result in a Value element within a Signature
>   Component
>
>But there is no description(or definition) about how to sign. 
>
>I and Hiroya-san think it is obvious that "signs the Manifest element"
>means to make a hash value of the Manifest element and encrypt the
>hash value of the Manifest element.
>
>In order to avoid ambiguity, it may be better to describe how to sign
>the Manifest element such as the above or more detail in IOTP (and/or
>IOTP DSIG) document.
>
>What do you think it is too obvious to describe how to sign?
>--
>Yoshiaki Kawatsura and Masaaki Hiroya,  Hitachi, Ltd.
>
>
>
>-----------------------------------------------------------------------
>Message addressed to: [email-masked]
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: [email-masked]
> 
_____________________________________________________________
Kent M. Davidson
VP Engineering
Differential, Inc.
http://www.differential.com
main (650)426-1100
fax  (650)426-1101

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Smith, Chris" <[email-masked]>
To: Ietf Trade WG <[email-masked]>,  David Burdett <[email-masked]>
Subject: RE: Help Please - SHA1 Authentication Algorithm Packaged Con
Date: Tue, 25 May 1999 12:28:00 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BEA6CE.F106FE56
Content-Type: text/plain;
	charset="iso-8859-1"

Roughly:

<AuthReqBlk>
  <AuthReq ID="M1.w" AuthenticationID="AUTH1111">
    <Algorithm ID="M1.x" type="digest" name="iotp:sha1>
    <PackagedContent Name="DOMAIN" Content="PCDATA" Transform="BASE64">
      AAAABBBBZZZZ
    </PackagedContent>
    <PackagedContent Name="CHALLENGE" Content="PCDATA" Transform="BASE64">
      AAAABBBBZZZZ
    </PackagedContent>
  </AuthReq>
</AuthReqBlk>

<AuthRespBlk>
  <AuthResp AuthenticationId="AUTH1111" >
    <PackagedContent Name="SALT" Content="PCDATA" Transform="BASE64">
      AAAABBBBZZZZ
    </PackagedContent>
    <PackagedContent Name="DIGEST" Content="PCDATA" Transform="BASE64">
      AAAABBBBZZZZ
    </PackagedContent>
  </AuthResp>
</AuthRespBlk>

Although the transform of BASE64 is not required, under the cicumstances, I 
would think it would be wise.

The process is (off the top of my head, comment if required):

1) Identify the Algorithm; if it is SHA1 digest authentication, proceed.
   (Note that HMAC:SHA1 is likely preferred).

   I have used a sample name above - we should likely nail down this name.

2) Extract the DOMAIN, and determine (by query of file, database or user)
   if authentication can proceed against this DOMAIN. (Query against user,
   can be roughly interpreted as "ask for password"). Only proceed if
   the DOMAIN is accepted.

   In many cases, the DOMAIN may be a plain text string presented to the
user;
   in this regard, this is similar to Basic web authentication.

3) Choose an unpredictable (random is good, non-repeated is good) SALT.

4) Get the local SECRET.

5) Assemble the plaintext:

   DOMAIN NULL CHALLENGE NULL SECRET NULL SALT

   where NULL is a single byte of value Zero. The NULL separator raises the
   difficulty of structuring attacks based on moving information between the
   various elements of the plaintext without changing the DIGEST.

6) Generate the digest over the plaintext (using SHA1 or, better, HMAC
SHA1).

7) OFFICIALLY FORGET THE LOCAL SECRET. 

   Always a wise precaution.

8) Return the SALT and the DIGEST as described above.

   Again, BASE64 is not required, but is wise.

X) Unspecified here is the effect of interaction between various
wide-character
   formats, byte-ordering, and the digest algorithm.

...chris

______________________________ Reply Separator
_________________________________
Subject: Help Please - SHA1 Authentication Algorithm Packaged Content
Author:  "David Burdett" [SMTP:[email-masked]] at Internet
Date:    1999/05/21 09:50 PM

The Authentication Request Component (see other email) now says:

"If required the Algorithm may use the challenge data, contained in the 
Packaged Content elements within the Authentication Request Component in its

calculation. The format of the Packaged Contents are Algorithm dependent."

Can anyone help with defining the Packaged Content for the Challenge if the 
Authentication Algorithm is SHA1 - other values for the Algorithm (signature

and Payment Protocol dependent) I think are covered elsewhere.

David
> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office 
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973     Fax: +1 415 956 9370 
>

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

This Email and any attached files are confidential and may also be
privileged. 
If you are not the intended recipient, please notify the postmaster using
email 
address [email-masked] or call +44 171 557 5000 and ask for the
IT Helpdesk.  You should not copy this email and any attached files, use
them 
for any purpose or disclose the contents to any other person; all copies of
the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

****************************************************************************
****
*************
----------------------------------------------------------------------- 
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the 
body to: [email-masked]

------_=_NextPart_001_01BEA6CE.F106FE56
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: Help Please - SHA1 Authentication Algorithm Packaged =
Con</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>Roughly:</FONT>
</P>

<P><FONT SIZE=3D2>&lt;AuthReqBlk&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp; &lt;AuthReq ID=3D&quot;M1.w&quot; =
AuthenticationID=3D&quot;AUTH1111&quot;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; &lt;Algorithm =
ID=3D&quot;M1.x&quot; type=3D&quot;digest&quot; =
name=3D&quot;iotp:sha1&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; &lt;PackagedContent =
Name=3D&quot;DOMAIN&quot; Content=3D&quot;PCDATA&quot; =
Transform=3D&quot;BASE64&quot;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AAAABBBBZZZZ</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; &lt;/PackagedContent&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; &lt;PackagedContent =
Name=3D&quot;CHALLENGE&quot; Content=3D&quot;PCDATA&quot; =
Transform=3D&quot;BASE64&quot;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AAAABBBBZZZZ</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; &lt;/PackagedContent&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp; &lt;/AuthReq&gt;</FONT>
<BR><FONT SIZE=3D2>&lt;/AuthReqBlk&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&lt;AuthRespBlk&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp; &lt;AuthResp =
AuthenticationId=3D&quot;AUTH1111&quot; &gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; &lt;PackagedContent =
Name=3D&quot;SALT&quot; Content=3D&quot;PCDATA&quot; =
Transform=3D&quot;BASE64&quot;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AAAABBBBZZZZ</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; &lt;/PackagedContent&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; &lt;PackagedContent =
Name=3D&quot;DIGEST&quot; Content=3D&quot;PCDATA&quot; =
Transform=3D&quot;BASE64&quot;&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AAAABBBBZZZZ</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; &lt;/PackagedContent&gt;</FONT>
<BR><FONT SIZE=3D2>&nbsp; &lt;/AuthResp&gt;</FONT>
<BR><FONT SIZE=3D2>&lt;/AuthRespBlk&gt;</FONT>
</P>

<P><FONT SIZE=3D2>Although the transform of BASE64 is not required, =
under the cicumstances, I </FONT>
<BR><FONT SIZE=3D2>would think it would be wise.</FONT>
</P>

<P><FONT SIZE=3D2>The process is (off the top of my head, comment if =
required):</FONT>
</P>

<P><FONT SIZE=3D2>1) Identify the Algorithm; if it is SHA1 digest =
authentication, proceed.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; (Note that HMAC:SHA1 is likely =
preferred).</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; I have used a sample name above - we =
should likely nail down this name.</FONT>
</P>

<P><FONT SIZE=3D2>2) Extract the DOMAIN, and determine (by query of =
file, database or user)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; if authentication can proceed against =
this DOMAIN. (Query against user,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; can be roughly interpreted as &quot;ask =
for password&quot;). Only proceed if</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; the DOMAIN is accepted.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; In many cases, the DOMAIN may be a plain =
text string presented to the user;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; in this regard, this is similar to =
Basic web authentication.</FONT>
</P>

<P><FONT SIZE=3D2>3) Choose an unpredictable (random is good, =
non-repeated is good) SALT.</FONT>
</P>

<P><FONT SIZE=3D2>4) Get the local SECRET.</FONT>
</P>

<P><FONT SIZE=3D2>5) Assemble the plaintext:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; DOMAIN NULL CHALLENGE NULL SECRET NULL =
SALT</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; where NULL is a single byte of value =
Zero. The NULL separator raises the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; difficulty of structuring attacks based =
on moving information between the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; various elements of the plaintext =
without changing the DIGEST.</FONT>
</P>

<P><FONT SIZE=3D2>6) Generate the digest over the plaintext (using SHA1 =
or, better, HMAC SHA1).</FONT>
</P>

<P><FONT SIZE=3D2>7) OFFICIALLY FORGET THE LOCAL SECRET. </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; Always a wise precaution.</FONT>
</P>

<P><FONT SIZE=3D2>8) Return the SALT and the DIGEST as described =
above.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; Again, BASE64 is not required, but is =
wise.</FONT>
</P>

<P><FONT SIZE=3D2>X) Unspecified here is the effect of interaction =
between various wide-character</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; formats, byte-ordering, and the digest =
algorithm.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>...chris</FONT>
</P>

<P><FONT SIZE=3D2>______________________________ Reply Separator =
_________________________________</FONT>
<BR><FONT SIZE=3D2>Subject: Help Please - SHA1 Authentication Algorithm =
Packaged Content</FONT>
<BR><FONT SIZE=3D2>Author:&nbsp; &quot;David Burdett&quot; =
[SMTP:[email-masked]] at Internet</FONT>
<BR><FONT SIZE=3D2>Date:&nbsp;&nbsp;&nbsp; 1999/05/21 09:50 PM</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>The Authentication Request Component (see other =
email) now says:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;If required the Algorithm may use the challenge =
data, contained in the </FONT>
<BR><FONT SIZE=3D2>Packaged Content elements within the Authentication =
Request Component in its </FONT>
<BR><FONT SIZE=3D2>calculation. The format of the Packaged Contents are =
Algorithm dependent.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>Can anyone help with defining the Packaged Content =
for the Challenge if the </FONT>
<BR><FONT SIZE=3D2>Authentication Algorithm is SHA1 - other values for =
the Algorithm (signature </FONT>
<BR><FONT SIZE=3D2>and Payment Protocol dependent) I think are covered =
elsewhere.</FONT>
</P>

<P><FONT SIZE=3D2>David</FONT>
<BR><FONT SIZE=3D2>&gt; mailto:&lt;[email-masked]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Mondex International, US Advanced Technology =
Office </FONT>
<BR><FONT SIZE=3D2>&gt; 111 Pine St, 6th Floor, San Francisco, CA =
94111</FONT>
<BR><FONT SIZE=3D2>&gt; Tel/Voicemail: +1 415 645 =
6973&nbsp;&nbsp;&nbsp;&nbsp; Fax: +1 415 956 9370 </FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

<P><FONT =
SIZE=3D2>***************************************************************=
*****************</FONT>
<BR><FONT SIZE=3D2>**************</FONT>
</P>

<P><FONT SIZE=3D2>This Email and any attached files are confidential =
and may also be privileged. </FONT>
<BR><FONT SIZE=3D2>If you are not the intended recipient, please notify =
the postmaster using email </FONT>
<BR><FONT SIZE=3D2>address [email-masked] or call +44 171 557 =
5000 and ask for the</FONT>
<BR><FONT SIZE=3D2>IT Helpdesk.&nbsp; You should not copy this email =
and any attached files, use them </FONT>
<BR><FONT SIZE=3D2>for any purpose or disclose the contents to any =
other person; all copies of the </FONT>
<BR><FONT SIZE=3D2>Email and associated files in your possession should =
be destroyed.</FONT>
</P>

<P><FONT SIZE=3D2>Mondex International Limited</FONT>
<BR><FONT SIZE=3D2>47-53 Cannon Street</FONT>
<BR><FONT SIZE=3D2>London EC4M 5SQ</FONT>
<BR><FONT SIZE=3D2>United Kingdom</FONT>
<BR><FONT SIZE=3D2>Registered No: 3122085, England</FONT>
</P>

<P><FONT =
SIZE=3D2>Phone:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+44 171 557 5000</FONT>
<BR><FONT =
SIZE=3D2>Fax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; +44 171 557 5200</FONT>
<BR><FONT =
SIZE=3D2>Email:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>WebSite:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<A HREF=3D"http://www.mondexinternational.com" =
TARGET=3D"_blank">http://www.mondexinternational.com</A></FONT>
</P>

<P><FONT =
SIZE=3D2>***************************************************************=
*****************</FONT>
<BR><FONT SIZE=3D2>*************</FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------- </FONT>
<BR><FONT SIZE=3D2>Message addressed to: =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Archive available at: <A =
HREF=3D"http://www.elistx.com/archives/ietf-trade/" =
TARGET=3D"_blank">http://www.elistx.com/archives/ietf-trade/</A></FONT>
<BR><FONT SIZE=3D2>To (un)subscribe send a message with =
&quot;subscribe&quot; or &quot;unsubscribe&quot; in the </FONT>
<BR><FONT SIZE=3D2>body to: [email-masked]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BEA6CE.F106FE56--
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Smith, Chris" <[email-masked]>
To: "[email-masked]" <[email-masked]>,  David Burdett <[email-masked]>
Subject: RE: Implementation Results and IOTP Items - AlogrithmRefs
Date: Tue, 25 May 1999 11:56:00 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BEA6CC.68364E62
Content-Type: text/plain;
	charset="iso-8859-1"

This will work as long as the text description makes clear that some 
Algorithms may need information to be returned in the Org as well.

When this is necessary, the specifcation for the algorithm should 
indicate so.

Otherwise, I like this - it makes clear that in some cases (withdrawal, 
for example) I don't care who you are as long as you can authenticate 
yourself, and in other cases (purchase), I don't care who you are as 
long as you give me a shipping address as part of the customer's Org 
component.

...Chris

______________________________ Reply Separator
_________________________________
Subject: RE: Implementation Results and IOTP Items - AlogrithmRefs/Da
Author:  "David Burdett" [SMTP:[email-masked]] at Internet
Date:    1999/05/21 09:50 PM

I agree with Chris's point. However the change is not quite as simple as 
chris suggests since if you repeat the AuthData component, then it creates a

problem since AuthData also contains a "TradingRoleList" attribute which is 
used to request Organisation information about the Trading Roles which an 
individual or organisation wants to take in the Trade. If we repeat 
AuthData, then we are duplicating the request for Trading Role information.

In reality, requesting Organisation information is separate and distinct 
from authentication a Trading Role. So really, these should be two separate 
requests, so that the we have:
*     an Authentication Request which just does an Authentication, and 
*     a Trading Role Information Request, which requests the return of 
Organisation information about one or more Trading Roles.

Finally, Authentication Data now *only* occurs inside an Authentication 
Request Block therefore propose changing the name of the Authentication Data

Component to Authentication Request Component and its DTD name from AuthData

to AuthReq. This then mirrors Authentication Response more accurately as a 
request and response exchange.

Change to the specification are described below.

David

TRADING ROLE INFORMATION REQUEST
================================
This is a new component with DTD as follows:

<!ELEMENT TradingRoleInfoReq EMPTY>
<!ATTLIST TradingRoleInfoReq
 ID                 ID      #REQUIRED 
 TradingRoleList    NMTOKEN #REQUIRED >

 ... where TradingRoleList has the same defintion as in AuthData, and with a
description of ...

"This Trading Component contains a list of Trading Roles (see section 2.1) 
about which information is being requested. The result of a Trading Role 
Request is a set of Organisation Components (see section 7.6) that describe 
each of the Trading Roles requested."

Example usage includes:
          *     a Merchant requesting that a Consumer provides
Organisation Components for the Consumer and DelivTo Trading Roles
          *     a Consumer requesting from a Merchant, information
about the Payment Handlers and Delivery Handlers that the Merchant uses."

AUTHENTICATION DATA (REQUEST) COMPONENT 
====================================== 
Change Authentication Data DTD from:
<!ELEMENT AuthData (PackagedContent+, Algorithm+)> 
<!ATTLIST AuthData
 ID                 ID      #REQUIRED 
 AuthenticationId   CDATA   #REQUIRED 
 TradingRoleList    NMTOKEN #IMPLIED
 AlgorithmRefs      IDREFS  #REQUIRED 
 ContentSoftwareId  CDATA   #IMPLIED >

... to ...

<!ELEMENT AuthReq (Algorithm, PackagedContent*)> 
<!ATTLIST AuthReq
 ID                 ID      #REQUIRED 
 AuthenticationId   CDATA   #REQUIRED 
 ContentSoftwareId  CDATA   #IMPLIED >

... with a description as follows ...

"This Trading Component contains parameter data that is used in an 
Authentication of one Trading Role by another. Its definition is as 
follows."

Note that reference to Challenge Data has been removed as some 
authentication algorithms don't need challenge data.

AUTHENTICATION REQUEST AND AUTHENTICATiON RESPONSE SIGNATURES 
===========================================================
Add the TradingRoleRequestInfo component as one of the components to be 
signed in both these sections.

AUTHENTICATION REQUEST BLOCK
============================
Change the Authentication Request Block from:

<!ELEMENT AuthReqBlk (AuthData?) >

... to ...

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

.. and change the defintion AuthReq (AuthData) to read ...

     "If the Authentication Request Component (see section 7.2)is not
present it means that the Authentication Request Block is just requesting 
the return of Organisation Components which describe the Trading Role that 
received the Authentication Request Block.

     If one or more Authentication Data Components are present then each
describes an alternative way in which the Trading Role receiving the request

may authenticate themselves. The receiver of the Authentication Request 
block must use the Authentication method specified if there is only one or 
make a choice based on preference if there are more than one."

AUTHENTICATION RESPONSE BLOCK
Change the DTD from ...

<!ELEMENT AuthRespBlk (AuthResp, Org*) >

... to ...

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

... as the Authentication Response is only required if there is an 
Authentication Request component present in the Authentication Request 
Block.

AUTHENTICATION TRADING AND DOCUMENT EXCHANGES 
=============================================
Updated to reflect introduction of Trading Role Information Request.

> ----------
> From:      Smith, Chris[SMTP:[email-masked]] 
> Sent:      21 May 1999 12:42
> To:      [email-masked]
> Subject:      Implementation Results and IOTP Items - AlogrithmRefs/Data 
>
>
> In AuthData, we specify a content model of 
>
> <!ELEMENT AuthData (PackagedContent+, Algorithm+)> 
> <!ATTLIST AuthData
>  ID                 ID      #REQUIRED 
>  AuthenticationId   CDATA   #REQUIRED 
>  TradingRoleList    NMTOKEN #IMPLIED 
>  AlgorithmRefs      IDREFS  #REQUIRED
>  ContentSoftwareId  CDATA   #IMPLIED > 
>
> The intent is that the software and user together may choose a single 
> entry from AlgorithmRefs, and use the appropriate Algorithm and data 
> from PackagedContent.
>
> Two problems:
>
> 1) An algorithm might conceivably require NO data, especially if it is
> dependent on a hardware token. PackagedContent should likely be repeated 
> as (*) not as (+).
>
> 2) There is an unwarrented assumption here, that all algorithms can
> operate over the same PackagedContent. This is clearly not going to be 
> the case. However, there is no way to assign individual 'packages' to 
> the various algorithms.
>
> There are a couple of ways out of this. 
>
> 1: Limit AuthData to a single Algorithm and allow AuthData to repeat. 
> Then it is a matter of choosing from multiple AuthData, not from
> multiple AlgorithmRefs. In such a situation, AlgorithmRef would be 
> dropped as redundant.
>
> This strikes me as the most useful, since the most common case will 
> likely be a single choice of Algorithm.
>
> 2: Find a way to associate individual packages with algorithms. Do not 
> use the package names for this, as the individual algorithms may have
> already used those for their own purposes. This might be done using the 
> ID attributes from the PackagedContent items.
>
> This would work, but I still prefer 1: 
>
> =================================================================== 
> Chris Smith, Royal Bank, 416.348.6090, [email-masked]
>
>
>

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

This Email and any attached files are confidential and may also be
privileged. 
If you are not the intended recipient, please notify the postmaster using
email 
address [email-masked] or call +44 171 557 5000 and ask for the
IT Helpdesk.  You should not copy this email and any attached files, use
them 
for any purpose or disclose the contents to any other person; all copies of
the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

****************************************************************************
****
*************
----------------------------------------------------------------------- 
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the 
body to: [email-masked]

------_=_NextPart_001_01BEA6CC.68364E62
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: Implementation Results and IOTP Items - =
AlogrithmRefs</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>This will work as long as the text description makes =
clear that some </FONT>
<BR><FONT SIZE=3D2>Algorithms may need information to be returned in =
the Org as well.</FONT>
</P>

<P><FONT SIZE=3D2>When this is necessary, the specifcation for the =
algorithm should </FONT>
<BR><FONT SIZE=3D2>indicate so.</FONT>
</P>

<P><FONT SIZE=3D2>Otherwise, I like this - it makes clear that in some =
cases (withdrawal, </FONT>
<BR><FONT SIZE=3D2>for example) I don't care who you are as long as you =
can authenticate </FONT>
<BR><FONT SIZE=3D2>yourself, and in other cases (purchase), I don't =
care who you are as </FONT>
<BR><FONT SIZE=3D2>long as you give me a shipping address as part of =
the customer's Org </FONT>
<BR><FONT SIZE=3D2>component.</FONT>
</P>

<P><FONT SIZE=3D2>...Chris</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>______________________________ Reply Separator =
_________________________________</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Implementation Results and IOTP Items - =
AlogrithmRefs/Da</FONT>
<BR><FONT SIZE=3D2>Author:&nbsp; &quot;David Burdett&quot; =
[SMTP:[email-masked]] at Internet</FONT>
<BR><FONT SIZE=3D2>Date:&nbsp;&nbsp;&nbsp; 1999/05/21 09:50 PM</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I agree with Chris's point. However the change is not =
quite as simple as </FONT>
<BR><FONT SIZE=3D2>chris suggests since if you repeat the AuthData =
component, then it creates a </FONT>
<BR><FONT SIZE=3D2>problem since AuthData also contains a =
&quot;TradingRoleList&quot; attribute which is </FONT>
<BR><FONT SIZE=3D2>used to request Organisation information about the =
Trading Roles which an </FONT>
<BR><FONT SIZE=3D2>individual or organisation wants to take in the =
Trade. If we repeat </FONT>
<BR><FONT SIZE=3D2>AuthData, then we are duplicating the request for =
Trading Role information.</FONT>
</P>

<P><FONT SIZE=3D2>In reality, requesting Organisation information is =
separate and distinct </FONT>
<BR><FONT SIZE=3D2>from authentication a Trading Role. So really, these =
should be two separate </FONT>
<BR><FONT SIZE=3D2>requests, so that the we have:</FONT>
<BR><FONT SIZE=3D2>*&nbsp;&nbsp;&nbsp;&nbsp; an Authentication Request =
which just does an Authentication, and </FONT>
<BR><FONT SIZE=3D2>*&nbsp;&nbsp;&nbsp;&nbsp; a Trading Role Information =
Request, which requests the return of </FONT>
<BR><FONT SIZE=3D2>Organisation information about one or more Trading =
Roles.</FONT>
</P>

<P><FONT SIZE=3D2>Finally, Authentication Data now *only* occurs inside =
an Authentication </FONT>
<BR><FONT SIZE=3D2>Request Block therefore propose changing the name of =
the Authentication Data </FONT>
<BR><FONT SIZE=3D2>Component to Authentication Request Component and =
its DTD name from AuthData </FONT>
<BR><FONT SIZE=3D2>to AuthReq. This then mirrors Authentication =
Response more accurately as a </FONT>
<BR><FONT SIZE=3D2>request and response exchange.</FONT>
</P>

<P><FONT SIZE=3D2>Change to the specification are described =
below.</FONT>
</P>

<P><FONT SIZE=3D2>David</FONT>
</P>

<P><FONT SIZE=3D2>TRADING ROLE INFORMATION REQUEST</FONT>
<BR><FONT =
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>This is a new component with DTD as follows:</FONT>
</P>

<P><FONT SIZE=3D2>&lt;!ELEMENT TradingRoleInfoReq EMPTY&gt;</FONT>
<BR><FONT SIZE=3D2>&lt;!ATTLIST TradingRoleInfoReq</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #REQUIRED </FONT>
<BR><FONT SIZE=3D2>&nbsp;TradingRoleList&nbsp;&nbsp;&nbsp; NMTOKEN =
#REQUIRED &gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;... where TradingRoleList has the same =
defintion as in AuthData, and with a</FONT>
<BR><FONT SIZE=3D2>description of ...</FONT>
</P>

<P><FONT SIZE=3D2>&quot;This Trading Component contains a list of =
Trading Roles (see section 2.1) </FONT>
<BR><FONT SIZE=3D2>about which information is being requested. The =
result of a Trading Role </FONT>
<BR><FONT SIZE=3D2>Request is a set of Organisation Components (see =
section 7.6) that describe </FONT>
<BR><FONT SIZE=3D2>each of the Trading Roles requested.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>Example usage includes:</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
*&nbsp;&nbsp;&nbsp;&nbsp; a Merchant requesting that a Consumer =
provides</FONT>
<BR><FONT SIZE=3D2>Organisation Components for the Consumer and DelivTo =
Trading Roles</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
*&nbsp;&nbsp;&nbsp;&nbsp; a Consumer requesting from a Merchant, =
information</FONT>
<BR><FONT SIZE=3D2>about the Payment Handlers and Delivery Handlers =
that the Merchant uses.&quot;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>AUTHENTICATION DATA (REQUEST) COMPONENT </FONT>
<BR><FONT =
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D </FONT>
<BR><FONT SIZE=3D2>Change Authentication Data DTD from:</FONT>
<BR><FONT SIZE=3D2>&lt;!ELEMENT AuthData (PackagedContent+, =
Algorithm+)&gt; </FONT>
<BR><FONT SIZE=3D2>&lt;!ATTLIST AuthData</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #REQUIRED </FONT>
<BR><FONT SIZE=3D2>&nbsp;AuthenticationId&nbsp;&nbsp; CDATA&nbsp;&nbsp; =
#REQUIRED </FONT>
<BR><FONT SIZE=3D2>&nbsp;TradingRoleList&nbsp;&nbsp;&nbsp; NMTOKEN =
#IMPLIED</FONT>
<BR><FONT SIZE=3D2>&nbsp;AlgorithmRefs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
IDREFS&nbsp; #REQUIRED </FONT>
<BR><FONT SIZE=3D2>&nbsp;ContentSoftwareId&nbsp; CDATA&nbsp;&nbsp; =
#IMPLIED &gt;</FONT>
</P>

<P><FONT SIZE=3D2>... to ...</FONT>
</P>

<P><FONT SIZE=3D2>&lt;!ELEMENT AuthReq (Algorithm, =
PackagedContent*)&gt; </FONT>
<BR><FONT SIZE=3D2>&lt;!ATTLIST AuthReq</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #REQUIRED </FONT>
<BR><FONT SIZE=3D2>&nbsp;AuthenticationId&nbsp;&nbsp; CDATA&nbsp;&nbsp; =
#REQUIRED </FONT>
<BR><FONT SIZE=3D2>&nbsp;ContentSoftwareId&nbsp; CDATA&nbsp;&nbsp; =
#IMPLIED &gt;</FONT>
</P>

<P><FONT SIZE=3D2>... with a description as follows ...</FONT>
</P>

<P><FONT SIZE=3D2>&quot;This Trading Component contains parameter data =
that is used in an </FONT>
<BR><FONT SIZE=3D2>Authentication of one Trading Role by another. Its =
definition is as </FONT>
<BR><FONT SIZE=3D2>follows.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>Note that reference to Challenge Data has been =
removed as some </FONT>
<BR><FONT SIZE=3D2>authentication algorithms don't need challenge =
data.</FONT>
</P>

<P><FONT SIZE=3D2>AUTHENTICATION REQUEST AND AUTHENTICATiON RESPONSE =
SIGNATURES </FONT>
<BR><FONT =
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>Add the TradingRoleRequestInfo component as one of =
the components to be </FONT>
<BR><FONT SIZE=3D2>signed in both these sections.</FONT>
</P>

<P><FONT SIZE=3D2>AUTHENTICATION REQUEST BLOCK</FONT>
<BR><FONT =
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>Change the Authentication Request Block from:</FONT>
</P>

<P><FONT SIZE=3D2>&lt;!ELEMENT AuthReqBlk (AuthData?) &gt;</FONT>
</P>

<P><FONT SIZE=3D2>... to ...</FONT>
</P>

<P><FONT SIZE=3D2>&lt;!ELEMENT AuthReqBlk (AuthReq*, =
TradingRoleInfoReq?) &gt;</FONT>
</P>

<P><FONT SIZE=3D2>.. and change the defintion AuthReq (AuthData) to =
read ...</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; &quot;If the Authentication =
Request Component (see section 7.2)is not</FONT>
<BR><FONT SIZE=3D2>present it means that the Authentication Request =
Block is just requesting </FONT>
<BR><FONT SIZE=3D2>the return of Organisation Components which describe =
the Trading Role that </FONT>
<BR><FONT SIZE=3D2>received the Authentication Request Block.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; If one or more =
Authentication Data Components are present then each</FONT>
<BR><FONT SIZE=3D2>describes an alternative way in which the Trading =
Role receiving the request </FONT>
<BR><FONT SIZE=3D2>may authenticate themselves. The receiver of the =
Authentication Request </FONT>
<BR><FONT SIZE=3D2>block must use the Authentication method specified =
if there is only one or </FONT>
<BR><FONT SIZE=3D2>make a choice based on preference if there are more =
than one.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>AUTHENTICATION RESPONSE BLOCK</FONT>
<BR><FONT SIZE=3D2>Change the DTD from ...</FONT>
</P>

<P><FONT SIZE=3D2>&lt;!ELEMENT AuthRespBlk (AuthResp, Org*) &gt;</FONT>
</P>

<P><FONT SIZE=3D2>... to ...</FONT>
</P>

<P><FONT SIZE=3D2>&lt;!ELEMENT AuthRespBlk (AuthResp?, Org*) =
&gt;</FONT>
</P>

<P><FONT SIZE=3D2>... as the Authentication Response is only required =
if there is an </FONT>
<BR><FONT SIZE=3D2>Authentication Request component present in the =
Authentication Request </FONT>
<BR><FONT SIZE=3D2>Block.</FONT>
</P>

<P><FONT SIZE=3D2>AUTHENTICATION TRADING AND DOCUMENT EXCHANGES </FONT>
<BR><FONT =
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
</FONT>
<BR><FONT SIZE=3D2>Updated to reflect introduction of Trading Role =
Information Request.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; ----------</FONT>
<BR><FONT SIZE=3D2>&gt; From:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Smith, =
Chris[SMTP:[email-masked]] </FONT>
<BR><FONT SIZE=3D2>&gt; Sent:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 21 May 1999 =
12:42</FONT>
<BR><FONT SIZE=3D2>&gt; To:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Implementation Results and IOTP Items - AlogrithmRefs/Data </FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; In AuthData, we specify a content model of =
</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &lt;!ELEMENT AuthData (PackagedContent+, =
Algorithm+)&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &lt;!ATTLIST AuthData</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; =
ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #REQUIRED =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; AuthenticationId&nbsp;&nbsp; =
CDATA&nbsp;&nbsp; #REQUIRED </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; TradingRoleList&nbsp;&nbsp;&nbsp; NMTOKEN =
#IMPLIED </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; =
AlgorithmRefs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IDREFS&nbsp; =
#REQUIRED</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; ContentSoftwareId&nbsp; CDATA&nbsp;&nbsp; =
#IMPLIED &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; The intent is that the software and user =
together may choose a single </FONT>
<BR><FONT SIZE=3D2>&gt; entry from AlgorithmRefs, and use the =
appropriate Algorithm and data </FONT>
<BR><FONT SIZE=3D2>&gt; from PackagedContent.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Two problems:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; 1) An algorithm might conceivably require NO =
data, especially if it is</FONT>
<BR><FONT SIZE=3D2>&gt; dependent on a hardware token. PackagedContent =
should likely be repeated </FONT>
<BR><FONT SIZE=3D2>&gt; as (*) not as (+).</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; 2) There is an unwarrented assumption here, =
that all algorithms can</FONT>
<BR><FONT SIZE=3D2>&gt; operate over the same PackagedContent. This is =
clearly not going to be </FONT>
<BR><FONT SIZE=3D2>&gt; the case. However, there is no way to assign =
individual 'packages' to </FONT>
<BR><FONT SIZE=3D2>&gt; the various algorithms.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; There are a couple of ways out of this. </FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; 1: Limit AuthData to a single Algorithm and =
allow AuthData to repeat. </FONT>
<BR><FONT SIZE=3D2>&gt; Then it is a matter of choosing from multiple =
AuthData, not from</FONT>
<BR><FONT SIZE=3D2>&gt; multiple AlgorithmRefs. In such a situation, =
AlgorithmRef would be </FONT>
<BR><FONT SIZE=3D2>&gt; dropped as redundant.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; This strikes me as the most useful, since the =
most common case will </FONT>
<BR><FONT SIZE=3D2>&gt; likely be a single choice of Algorithm.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; 2: Find a way to associate individual packages =
with algorithms. Do not </FONT>
<BR><FONT SIZE=3D2>&gt; use the package names for this, as the =
individual algorithms may have</FONT>
<BR><FONT SIZE=3D2>&gt; already used those for their own purposes. This =
might be done using the </FONT>
<BR><FONT SIZE=3D2>&gt; ID attributes from the PackagedContent =
items.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; This would work, but I still prefer 1: </FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D </FONT>
<BR><FONT SIZE=3D2>&gt; Chris Smith, Royal Bank, 416.348.6090, =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

<P><FONT =
SIZE=3D2>***************************************************************=
*****************</FONT>
<BR><FONT SIZE=3D2>**************</FONT>
</P>

<P><FONT SIZE=3D2>This Email and any attached files are confidential =
and may also be privileged. </FONT>
<BR><FONT SIZE=3D2>If you are not the intended recipient, please notify =
the postmaster using email </FONT>
<BR><FONT SIZE=3D2>address [email-masked] or call +44 171 557 =
5000 and ask for the</FONT>
<BR><FONT SIZE=3D2>IT Helpdesk.&nbsp; You should not copy this email =
and any attached files, use them </FONT>
<BR><FONT SIZE=3D2>for any purpose or disclose the contents to any =
other person; all copies of the </FONT>
<BR><FONT SIZE=3D2>Email and associated files in your possession should =
be destroyed.</FONT>
</P>

<P><FONT SIZE=3D2>Mondex International Limited</FONT>
<BR><FONT SIZE=3D2>47-53 Cannon Street</FONT>
<BR><FONT SIZE=3D2>London EC4M 5SQ</FONT>
<BR><FONT SIZE=3D2>United Kingdom</FONT>
<BR><FONT SIZE=3D2>Registered No: 3122085, England</FONT>
</P>

<P><FONT =
SIZE=3D2>Phone:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+44 171 557 5000</FONT>
<BR><FONT =
SIZE=3D2>Fax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; +44 171 557 5200</FONT>
<BR><FONT =
SIZE=3D2>Email:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>WebSite:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<A HREF=3D"http://www.mondexinternational.com" =
TARGET=3D"_blank">http://www.mondexinternational.com</A></FONT>
</P>

<P><FONT =
SIZE=3D2>***************************************************************=
*****************</FONT>
<BR><FONT SIZE=3D2>*************</FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------- </FONT>
<BR><FONT SIZE=3D2>Message addressed to: =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Archive available at: <A =
HREF=3D"http://www.elistx.com/archives/ietf-trade/" =
TARGET=3D"_blank">http://www.elistx.com/archives/ietf-trade/</A></FONT>
<BR><FONT SIZE=3D2>To (un)subscribe send a message with =
&quot;subscribe&quot; or &quot;unsubscribe&quot; in the </FONT>
<BR><FONT SIZE=3D2>body to: [email-masked]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BEA6CC.68364E62--
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked],  [email-masked]
Subject: Comments for IOTP DSIG (addition).
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Tue, 25 May 1999 15:23:58 +0900 (JST)
Lines: 26
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David (and Kent), 

We can understand where we have to sign because of the following
description in section 6.17:

  o signs the Manifest element using the optional certificate
   identified in the Certificate element within the Signature
   Block placing the result in a Value element within a Signature
   Component

But there is no description(or definition) about how to sign. 

I and Hiroya-san think it is obvious that "signs the Manifest element"
means to make a hash value of the Manifest element and encrypt the
hash value of the Manifest element.

In order to avoid ambiguity, it may be better to describe how to sign
the Manifest element such as the above or more detail in IOTP (and/or
IOTP DSIG) document.

What do you think it is too obvious to describe how to sign?
--
Yoshiaki Kawatsura and Masaaki Hiroya,  Hitachi, Ltd.

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: [email-masked], Chris Smith <[email-masked]>
Subject: RE: HTML Names and Links
Date: Mon, 24 May 1999 22:10:57 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

See comments below.

David

> ----------
> From: 	Smith, Chris[SMTP:[email-masked]]
> Sent: 	21 May 1999 12:41
> To: 	[email-masked]
> Subject: 	HTML Names and Links
> 
> 
> Regarding included "HTML mini-sites": 
> 
> Comments: 
> 
> 1) You can't prevent the inclusion of out-bound links in the HTML. It 
> should be discouraged (if only for offline viewing reasons and for using 
> e-mail OTP reasons). Local software COULD prevent it, but I would still 
> want it to be a locally selectable (On/Off/Warn) selectable function. 
## Currently the spec states on "Packaging HTML" ...

"The packaged content may contain HTML. In this case the following
conventions are followed:
		*	references to any documents, images or other things,
such as sounds or web pages, which can affect the recipient's understanding
of the data which is being packaged must refer to other Packaged Elements
contained within the same parent element, e.g. an Order Description
		*	if more than one Packaged Content element is
included within a parent element in order to meet the previous requirement,
then the Name attribute of the top level Packaged Content from which
references to all other Packaged Elements can be determined, should have a
value of Main
		*	relative references to other documents, images, etc.
from one Packaged Content element to another are realised by setting the
value of the relative reference to the Name attribute of another Packaged
Content element at the same level and within the same parent element
		*	no external references that require the reference to
be resolved immediately should be used. As this could make the HTML
difficult or impossible to display completely
		*	[MIME] is used to encapsulate the data inside each
Packaged Element. This means that the information in the MIME header used to
identify the type of data which has been encapsulated and therefore how it
should be displayed.
If the above conventions are not followed by, for example, including
external references which must be resolved, then the recipient of the HTML
should be informed."

I think this meets the need. ##

> 2) The order of an included list of PackagedContent is important, if 
> only because signed items can't be rearranged. 
> 
> Applying a rule such as "The first PackagedContent item is the first 
> item to be displayed to a user" is a definitive rule. It always behaves 
> the same way. Also, any reasonable DOM will let you place items exactly 
> where the document builder wants them. This is not an undue constraint 
> on the Order builder, because order of items is already important. 
> 
> This would also allow using the PackagedContent:names exclusively for 
> inclusions and links. 
> 
> In this manner, even preexisting mini-sites could be included very 
> easily, likely without having to rename items as they are stored in the 
> Order Description. 
## I'm inclined to agree with Chris. Does anyone disagree? ##

> =================================================================== 
> Chris Smith, Royal Bank, 416.348.6090, [email-masked] 
> 
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: Comments for IOTP DSIG.
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Mon, 24 May 1999 14:33:03 +0900 (JST)
Lines: 103
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Kent,

I have some comments for your draft. See below.

1. In the meeting in Ft. Lauderdale (when we discussed about DSIG), I
remember that we decided to sign the Manifest element itself. But it
seems to me that there is no description about this in the DSIG draft. 
Would you specify the discription on it? I think this should be in the
DSIG document also (as in IOTP document).

2. The description of the Algorithm element in Section 3.3 should be
described in a separate section.
 
3. Section 4.3.2
   <Manifest
           LocatorHrefBase='iotp:globally-unique-tid#>

should be 

   <Manifest
           LocatorHrefBase='iotp:globally-unique-tid#'>

4. Section 6. examples
the example should change as follows:

   <OtpMessage>
       <TransRefBlk ID="C.1">
           <TransId
               ID="C.2"
               version="1.0"
               OtpTransID="foo"
               OtpTransType="foo"
               TransTimeStamp="1258402394">
           </TransId>
           <MsgId xml:lang="en" SoftwareID="1.0">
           </MsgId>
       </TransRefBlk>
       <AuthReqBlk ID="C.3">
           <Org
               ID="C.7"
               OrgId="shop 1.0"
               OtpMsgIdPrefix="foo"
               ShortDesc="Widgets,Inc."
               LogoNetLocn="http://www.widgets.com/Banner2.12.99.gif">
               <TradingRole ID="C.8" TradingRole="foo">
               </TradingRole>
               <ContactInfo Tel="408-864-0600" Email="[email-masked]">
               </ContactInfo>
           </Org>
       </AuthReqBlk>
       <IOTPSignatures>
           <Signature>
               <Manifest LocatorHrefBase="iotp:">
                   <Algorithm name="urn:sha1" type=digest ID="S.1">
                   </Algorithm>
                   <Algorithm name="urn:rsa" type=signature ID="S.2">
                       <Parameter type=AlgorithmRef>S.3</Parameter>
                   </Algorithm>
                   <Algorithm name="urn:dom-hash" type="digest" ID="S.3">
                       <Parameter type=AlgorithmRef>S.1</Parameter>
                   </Algorithm>
                   <Digest DigestAlgorithmRef="S.3">
                       <Locator href="C.1"/>
                       <Value>
                           xsqsfasDys2h44u4ehJDe54he5j4dJYTJ=
                       </Value>
                   </Digest>
                   <Digest DigestAlgorithmRef="S.3">
                       <Locator href="C.3"/>
                       <Value>
                           ked0Ks01k2d7a0kgmf9dk19lf63kkDSs0=
                       </Value>
                   </Digest>
                   <OriginatorInfo
                       OriginatorRef="C.7">
                   </OriginatorInfo>
                   <RecipientInfo
                       SignatureAlgorithmRef="S.2"
                       SignatureValueRef="V.1"
                       RecipientRef="M.8">
                   </RecipientInfo>
               </Manifest>
               <Value ID="V.1">
                   9dj28fjakA9sked0Ks01k2d7a0kgmf9dk19lf63kkDSs0=
               </Value>
           </Signature>
       </IOTPSignatures>
   </OtpMessage>

Regards,
----
Yoshiaki Kawatsura : E-mail [email-masked]
 Business & Information Systems Development Devision, Hitachi,Ltd.
Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Reply-To: [email-masked]
Date: Sun, 23 May 1999 16:59:38 +0900
To: [email-masked]
From: Masaaki Hiroya <[email-masked]>
Subject: Error Handling
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David and Werner

I have some questions about error handling.

[Question 1]
The business error handling described in IOTP Payment API Supplement v1.0.1a
is inconsistent with the one described in IOTP specification v1.0-03.

In 4.3.3.3 Block Business Errors in the IOTP specification, there is a 
description as follows:
"If a business error occurs in a process such as a Payment or a
 Delivery, then the appropriate type of response block is returned. The
 Status Component (see section 6.14) within that response block
 indicates the error and its severity. No Error Component or Error Block
 is generated for business errors."

In 8.5.2 Intermediate Failures in the Payment API Supplement, there is a
description as follows:
"Transient Error: Failures, that might be resolved by the retransmission of 
the appropriate IOTP message, belong to this class. 
......
The behavior of the IOTP Application Core and IOTP Payment Bridge does not
depend on any further classification of this failure (technical/business)."

In Fig.31 in 8.5.2, an business error with severity "TransientError" is 
notified from the Payment Handler to the Consumer by using an Error message.

Which should be used, ErrorBlk and Error Component or PayRespBlk and Status
Component in the case of business errors with "TransientError" severity?
 
If the Status Component should be used in any business error, it is necessary
to add a "Severity" attribute to the Status Component, since there is no 
"Severity" attribute in the Status Component defined in 6.14 of the IOTP 
specification.

[Question 2]
This is a confirmation rather than a question.
After the Consumer receives the PayResp message with Severity "Transient
Error", the Consumer sends the retrying PayExch message in order to continue
the transaction, doesn't it?
I think the answer is "yes" since there is the Server Role description 
in 4.4.1.9 of the IOTP specification as follows:
  "Transient Errors" are not stored so that if the original Response
  Block is received again, then it can be processed as if it had never
  been received before.
(In the above sentence, I think that "the original Response Block" should 
 be "the original Request Block" because the Server Role receives request
 blocks.)

[Question 3]
Additional Confirmation.  It is allowed to set different values from the
original request message to the retrying request message in the case of
business errors with "TransientError" severity, isn't it?
I think the answer should be "yes" since in the case of "Insufficient Fund"
the Consumer may replace the e-cash card and then retry the transaction
so PaySchemeData in the original may be different from the one in the
retrying message.

The reason why I am confused is there is a description in 4.4.2.8 of
IOTP specification as follows:
  "Transient errors may be used to provide a manual or automatic
  resending (step 8b) of a block previously stored or alternatively may
  result in transaction cancellation."

[Question 4]
Some errors are not easy to classify as technical errors or business errors.
If the payment server such as the SET Merchant connected to IOTP Payment
Handler server through its payment bridge has an internel processing error,
is it a technical error or a business error with an completion code of
"BadInstrument"?  If the SET Merchant server doesn't respond to the request
from the payment bridge of the Payment Handler, is it a technical error or
a business error with "BadInstrument" completion code?

[Question 5]
Accoring to the IOTP specification, PayReceipt Component is mandatory in 
PayRespBlk and it is required to use PayRespBlk in the case of business 
errors, 
But I think most payment schemes doesn't generate payment receipts when errors
occur.  Taking it into consideration, the PayReceipt should be optional in the 
PayRespBlk.  What do you think about it?

Regards
Masaaki
-----
Masaaki Hiroya
Systems Development Laboratory
Hitachi, Ltd.
tel: +81-44-959-0874
fax: +81-44-959-0856
email: [email-masked]
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: Help Please - SHA1 Authentication Algorithm Packaged Content
Date: Sat, 22 May 1999 02:50:43 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The Authentication Request Component (see other email) now says:

"If required the Algorithm may use the challenge data, contained in the
Packaged Content elements within the Authentication Request Component in its
calculation. The format of the Packaged Contents are Algorithm dependent."

Can anyone help with defining the Packaged Content for the Challenge if the
Authentication Algorithm is SHA1 - other values for the Algorithm (signature
and Payment Protocol dependent) I think are covered elsewhere.

David
> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: [email-masked], Chris Smith <[email-masked]>
Subject: RE: Implementation Results and IOTP Items - AlogrithmRefs/Data
Date: Sat, 22 May 1999 02:50:45 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I agree with Chris's point. However the change is not quite as simple as
chris suggests since if you repeat the AuthData component, then it creates a
problem since AuthData also contains a "TradingRoleList" attribute which is
used to request Organisation information about the Trading Roles which an
individual or organisation wants to take in the Trade. If we repeat
AuthData, then we are duplicating the request for Trading Role information.

In reality, requesting Organisation information is separate and distinct
from authentication a Trading Role. So really, these should be two separate
requests, so that the we have:
*	an Authentication Request which just does an Authentication, and
*	a Trading Role Information Request, which requests the return of
Organisation information about one or more Trading Roles.

Finally, Authentication Data now *only* occurs inside an Authentication
Request Block therefore propose changing the name of the Authentication Data
Component to Authentication Request Component and its DTD name from AuthData
to AuthReq. This then mirrors Authentication Response more accurately as a
request and response exchange.

Change to the specification are described below.

David

TRADING ROLE INFORMATION REQUEST
================================
This is a new component with DTD as follows:

<!ELEMENT TradingRoleInfoReq EMPTY>
<!ATTLIST TradingRoleInfoReq
 ID                 ID      #REQUIRED
 TradingRoleList    NMTOKEN #REQUIRED >

 ... where TradingRoleList has the same defintion as in AuthData, and with a
description of ...

"This Trading Component contains a list of Trading Roles (see section 2.1)
about which information is being requested. The result of a Trading Role
Request is a set of Organisation Components (see section 7.6) that describe
each of the Trading Roles requested."

Example usage includes:
		*	a Merchant requesting that a Consumer provides
Organisation Components for the Consumer and DelivTo Trading Roles
		*	a Consumer requesting from a Merchant, information
about the Payment Handlers and Delivery Handlers that the Merchant uses."

AUTHENTICATION DATA (REQUEST) COMPONENT
======================================
Change Authentication Data DTD from:
<!ELEMENT AuthData (PackagedContent+, Algorithm+)>
<!ATTLIST AuthData
 ID                 ID      #REQUIRED
 AuthenticationId   CDATA   #REQUIRED
 TradingRoleList    NMTOKEN #IMPLIED
 AlgorithmRefs      IDREFS  #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

... to ...

<!ELEMENT AuthReq (Algorithm, PackagedContent*)>
<!ATTLIST AuthReq
 ID                 ID      #REQUIRED
 AuthenticationId   CDATA   #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

... with a description as follows ...

"This Trading Component contains parameter data that is used in an
Authentication of one Trading Role by another. Its definition is as
follows."

Note that reference to Challenge Data has been removed as some
authentication algorithms don't need challenge data.

AUTHENTICATION REQUEST AND AUTHENTICATiON RESPONSE SIGNATURES
===========================================================
Add the TradingRoleRequestInfo component as one of the components to be
signed in both these sections.

AUTHENTICATION REQUEST BLOCK
============================
Change the Authentication Request Block from: 

<!ELEMENT AuthReqBlk (AuthData?) >

... to ...

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

.. and change the defintion AuthReq (AuthData) to read ...

	"If the Authentication Request Component (see section 7.2)is not
present it means that the Authentication Request Block is just requesting
the return of Organisation Components which describe the Trading Role that
received the Authentication Request Block. 

	If one or more Authentication Data Components are present then each
describes an alternative way in which the Trading Role receiving the request
may authenticate themselves. The receiver of the Authentication Request
block must use the Authentication method specified if there is only one or
make a choice based on preference if there are more than one."

AUTHENTICATION RESPONSE BLOCK
Change the DTD from ...

<!ELEMENT AuthRespBlk (AuthResp, Org*) >

... to ...

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

... as the Authentication Response is only required if there is an
Authentication Request component present in the Authentication Request
Block.

AUTHENTICATION TRADING AND DOCUMENT EXCHANGES
=============================================
Updated to reflect introduction of Trading Role Information Request.

> ----------
> From: 	Smith, Chris[SMTP:[email-masked]]
> Sent: 	21 May 1999 12:42
> To: 	[email-masked]
> Subject: 	Implementation Results and IOTP Items - AlogrithmRefs/Data
> 
> 
> In AuthData, we specify a content model of 
> 
> <!ELEMENT AuthData (PackagedContent+, Algorithm+)> 
> <!ATTLIST AuthData 
>  ID                 ID      #REQUIRED 
>  AuthenticationId   CDATA   #REQUIRED 
>  TradingRoleList    NMTOKEN #IMPLIED 
>  AlgorithmRefs      IDREFS  #REQUIRED 
>  ContentSoftwareId  CDATA   #IMPLIED > 
> 
> The intent is that the software and user together may choose a single 
> entry from AlgorithmRefs, and use the appropriate Algorithm and data 
> from PackagedContent. 
> 
> Two problems: 
> 
> 1) An algorithm might conceivably require NO data, especially if it is 
> dependent on a hardware token. PackagedContent should likely be repeated 
> as (*) not as (+). 
> 
> 2) There is an unwarrented assumption here, that all algorithms can 
> operate over the same PackagedContent. This is clearly not going to be 
> the case. However, there is no way to assign individual 'packages' to 
> the various algorithms. 
> 
> There are a couple of ways out of this. 
> 
> 1: Limit AuthData to a single Algorithm and allow AuthData to repeat. 
> Then it is a matter of choosing from multiple AuthData, not from 
> multiple AlgorithmRefs. In such a situation, AlgorithmRef would be 
> dropped as redundant. 
> 
> This strikes me as the most useful, since the most common case will 
> likely be a single choice of Algorithm. 
> 
> 2: Find a way to associate individual packages with algorithms. Do not 
> use the package names for this, as the individual algorithms may have 
> already used those for their own purposes. This might be done using the 
> ID attributes from the PackagedContent items. 
> 
> This would work, but I still prefer 1: 
> 
> =================================================================== 
> Chris Smith, Royal Bank, 416.348.6090, [email-masked] 
> 
> 
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: Implementation Results and IOTP Items - AuthenticationId
Date: Sat, 22 May 1999 02:50:40 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Agreed

David

> ----------
> From: 	Smith, Chris[SMTP:[email-masked]]
> Sent: 	21 May 1999 12:42
> To: 	[email-masked]
> Subject: 	Implementation Results and IOTP Items - AuthenticationId
> 
> 
> In section 6.2 (AuthData) we specify the AuthenticationId attribute, 
> indicating that it can be used to identify the autentication in question 
> if it is returned to the authenticating organization. 
> 
> However, in section 6.3 (AuthResp) we do not include the 
> AuthenticationId attribute. It must be available on the AuthResp if we 
> wish to return to value to the authenticating organization. 
> 
> It should be added. 
> 
> =================================================================== 
> Chris Smith, Royal Bank, 416.348.6090, [email-masked] 
> 
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Smith, Chris" <[email-masked]>
To: [email-masked]
Subject: HTML Names and Links
Date: Fri, 21 May 1999 15:41:00 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BEA3C3.1F6C0278
Content-Type: text/plain

Regarding included "HTML mini-sites":

Comments:

1) You can't prevent the inclusion of out-bound links in the HTML. It 
should be discouraged (if only for offline viewing reasons and for using 
e-mail OTP reasons). Local software COULD prevent it, but I would still 
want it to be a locally selectable (On/Off/Warn) selectable function.

2) The order of an included list of PackagedContent is important, if 
only because signed items can't be rearranged.

Applying a rule such as "The first PackagedContent item is the first 
item to be displayed to a user" is a definitive rule. It always behaves 
the same way. Also, any reasonable DOM will let you place items exactly 
where the document builder wants them. This is not an undue constraint 
on the Order builder, because order of items is already important.

This would also allow using the PackagedContent:names exclusively for 
inclusions and links.

In this manner, even preexisting mini-sites could be included very 
easily, likely without having to rename items as they are stored in the 
Order Description.

===================================================================
Chris Smith, Royal Bank, 416.348.6090, [email-masked]

------_=_NextPart_001_01BEA3C3.1F6C0278
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2232.0">
<TITLE>HTML Names and Links</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>Regarding included &quot;HTML mini-sites&quot;:</FONT>
</P>

<P><FONT SIZE=2>Comments:</FONT>
</P>

<P><FONT SIZE=2>1) You can't prevent the inclusion of out-bound links in the HTML. It </FONT>
<BR><FONT SIZE=2>should be discouraged (if only for offline viewing reasons and for using </FONT>
<BR><FONT SIZE=2>e-mail OTP reasons). Local software COULD prevent it, but I would still </FONT>
<BR><FONT SIZE=2>want it to be a locally selectable (On/Off/Warn) selectable function.</FONT>
</P>

<P><FONT SIZE=2>2) The order of an included list of PackagedContent is important, if </FONT>
<BR><FONT SIZE=2>only because signed items can't be rearranged.</FONT>
</P>

<P><FONT SIZE=2>Applying a rule such as &quot;The first PackagedContent item is the first </FONT>
<BR><FONT SIZE=2>item to be displayed to a user&quot; is a definitive rule. It always behaves </FONT>
<BR><FONT SIZE=2>the same way. Also, any reasonable DOM will let you place items exactly </FONT>
<BR><FONT SIZE=2>where the document builder wants them. This is not an undue constraint </FONT>
<BR><FONT SIZE=2>on the Order builder, because order of items is already important.</FONT>
</P>

<P><FONT SIZE=2>This would also allow using the PackagedContent:names exclusively for </FONT>
<BR><FONT SIZE=2>inclusions and links.</FONT>
</P>

<P><FONT SIZE=2>In this manner, even preexisting mini-sites could be included very </FONT>
<BR><FONT SIZE=2>easily, likely without having to rename items as they are stored in the </FONT>
<BR><FONT SIZE=2>Order Description.</FONT>
</P>
<BR>

<P><FONT SIZE=2>===================================================================</FONT>
<BR><FONT SIZE=2>Chris Smith, Royal Bank, 416.348.6090, [email-masked]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BEA3C3.1F6C0278--
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: Comments o signatures
Date: Fri, 21 May 1999 21:47:26 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Roland SEIDL of Telstra Research, made some comments in an earlier email
which I overlooked. These are now discussed below.

David

<<< Clip >>>
Some more comments on the draft.

Section 5.1
   "which Organisation(s) should be the receive the signature"
should read
   "which Organisation(s) should be the receiver of the signature" (?????)
## Now changed to read ...
*	which Organisation(s) should process the signature in order to check
that the Action the Organisation should take can occur. ## 

Figure 12 is inconsistent with the Signature Component DTD. The
RecipientInfo
block should be a subordinate of the Manifest block. The same inconsistency
appears in fig. 13 -- the Originator Info and Recipient Info blocks are all
subordinates of the Manifest block.
## Fixed##

I note that the Signature Component DTD is identical with that of the
Digital Signatures
for IOTP draft -- complete with the same errors!
  <!ELEMENT manifest ---- has no terminating ">"
 <!ATTRLIST ----  should be "<!ATTLIST"

## It's not surprising really since this part of the DTD in the IOTP spec
was copied from the signatures DTD. Anyway the problems will be fixed when
the Signatures spec is revised. ##

There is also a difference of opinion between the 2 draft specs.
 -- In Section 5.1.2 of the IOTP draft it states:
    "Attribute element with a type attribute set to IOTPSignatureType..."

 -- In Section 4.3.6 of the Digital Signature draft it states:
   "At this time, no IOTP specific attributes are specified."
## This will also be fixed when the Signatures spec is revised ##
> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Smith, Chris" <[email-masked]>
To: [email-masked]
Subject: Implementation Results and IOTP Items -OrgID / Role / Prefix
Date: Fri, 21 May 1999 15:41:00 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BEA3C3.1F51C89A
Content-Type: text/plain

We have stated that the Trading Role controls the prefix 
(PaymentHandler=P), (Merchant=M), etc. (section 3.4.1)

To capture the multiple roles of an organization. we allow an <Org> to 
have multiple <TradingRole> s.

However, the OtpMsgIdPrefix is on the <Org>

It should be on the <TradingRole>.

===================================================================
Chris Smith, Royal Bank, 416.348.6090, [email-masked]

------_=_NextPart_001_01BEA3C3.1F51C89A
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2232.0">
<TITLE>Implementation Results and IOTP Items -OrgID / Role / Prefix</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>We have stated that the Trading Role controls the prefix </FONT>
<BR><FONT SIZE=2>(PaymentHandler=P), (Merchant=M), etc. (section 3.4.1)</FONT>
</P>

<P><FONT SIZE=2>To capture the multiple roles of an organization. we allow an &lt;Org&gt; to </FONT>
<BR><FONT SIZE=2>have multiple &lt;TradingRole&gt; s.</FONT>
</P>

<P><FONT SIZE=2>However, the OtpMsgIdPrefix is on the &lt;Org&gt;</FONT>
</P>

<P><FONT SIZE=2>It should be on the &lt;TradingRole&gt;.</FONT>
</P>

<P><FONT SIZE=2>===================================================================</FONT>
<BR><FONT SIZE=2>Chris Smith, Royal Bank, 416.348.6090, [email-masked]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BEA3C3.1F51C89A--
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Smith, Chris" <[email-masked]>
To: [email-masked]
Subject: Implementation Results and IOTP Items - AuthenticationId
Date: Fri, 21 May 1999 15:42:00 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BEA3C3.433FF8EE
Content-Type: text/plain

In section 6.2 (AuthData) we specify the AuthenticationId attribute, 
indicating that it can be used to identify the autentication in question 
if it is returned to the authenticating organization.

However, in section 6.3 (AuthResp) we do not include the 
AuthenticationId attribute. It must be available on the AuthResp if we 
wish to return to value to the authenticating organization.

It should be added.

===================================================================
Chris Smith, Royal Bank, 416.348.6090, [email-masked]

------_=_NextPart_001_01BEA3C3.433FF8EE
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2232.0">
<TITLE>Implementation Results and IOTP Items - AuthenticationId</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>In section 6.2 (AuthData) we specify the AuthenticationId attribute, </FONT>
<BR><FONT SIZE=2>indicating that it can be used to identify the autentication in question </FONT>
<BR><FONT SIZE=2>if it is returned to the authenticating organization.</FONT>
</P>

<P><FONT SIZE=2>However, in section 6.3 (AuthResp) we do not include the </FONT>
<BR><FONT SIZE=2>AuthenticationId attribute. It must be available on the AuthResp if we </FONT>
<BR><FONT SIZE=2>wish to return to value to the authenticating organization.</FONT>
</P>

<P><FONT SIZE=2>It should be added.</FONT>
</P>

<P><FONT SIZE=2>===================================================================</FONT>
<BR><FONT SIZE=2>Chris Smith, Royal Bank, 416.348.6090, [email-masked]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BEA3C3.433FF8EE--
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Smith, Chris" <[email-masked]>
To: [email-masked]
Subject: Implementation Results and IOTP Items - AlogrithmRefs/Data
Date: Fri, 21 May 1999 15:42:00 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BEA3C3.433C67D8
Content-Type: text/plain

In AuthData, we specify a content model of

<!ELEMENT AuthData (PackagedContent+, Algorithm+)> 
<!ATTLIST AuthData
 ID                 ID      #REQUIRED 
 AuthenticationId   CDATA   #REQUIRED 
 TradingRoleList    NMTOKEN #IMPLIED
 AlgorithmRefs      IDREFS  #REQUIRED 
 ContentSoftwareId  CDATA   #IMPLIED >

The intent is that the software and user together may choose a single 
entry from AlgorithmRefs, and use the appropriate Algorithm and data 
from PackagedContent.

Two problems:

1) An algorithm might conceivably require NO data, especially if it is 
dependent on a hardware token. PackagedContent should likely be repeated 
as (*) not as (+).

2) There is an unwarrented assumption here, that all algorithms can 
operate over the same PackagedContent. This is clearly not going to be 
the case. However, there is no way to assign individual 'packages' to 
the various algorithms.

There are a couple of ways out of this.

1: Limit AuthData to a single Algorithm and allow AuthData to repeat. 
Then it is a matter of choosing from multiple AuthData, not from 
multiple AlgorithmRefs. In such a situation, AlgorithmRef would be 
dropped as redundant.

This strikes me as the most useful, since the most common case will 
likely be a single choice of Algorithm.

2: Find a way to associate individual packages with algorithms. Do not 
use the package names for this, as the individual algorithms may have 
already used those for their own purposes. This might be done using the 
ID attributes from the PackagedContent items.

This would work, but I still prefer 1:

===================================================================
Chris Smith, Royal Bank, 416.348.6090, [email-masked]

------_=_NextPart_001_01BEA3C3.433C67D8
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>Implementation Results and IOTP Items - =
AlogrithmRefs/Data</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>In AuthData, we specify a content model of</FONT>
</P>

<P><FONT SIZE=3D2>&lt;!ELEMENT AuthData (PackagedContent+, =
Algorithm+)&gt; </FONT>
<BR><FONT SIZE=3D2>&lt;!ATTLIST AuthData</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #REQUIRED </FONT>
<BR><FONT SIZE=3D2>&nbsp;AuthenticationId&nbsp;&nbsp; CDATA&nbsp;&nbsp; =
#REQUIRED </FONT>
<BR><FONT SIZE=3D2>&nbsp;TradingRoleList&nbsp;&nbsp;&nbsp; NMTOKEN =
#IMPLIED</FONT>
<BR><FONT SIZE=3D2>&nbsp;AlgorithmRefs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
IDREFS&nbsp; #REQUIRED </FONT>
<BR><FONT SIZE=3D2>&nbsp;ContentSoftwareId&nbsp; CDATA&nbsp;&nbsp; =
#IMPLIED &gt;</FONT>
</P>

<P><FONT SIZE=3D2>The intent is that the software and user together may =
choose a single </FONT>
<BR><FONT SIZE=3D2>entry from AlgorithmRefs, and use the appropriate =
Algorithm and data </FONT>
<BR><FONT SIZE=3D2>from PackagedContent.</FONT>
</P>

<P><FONT SIZE=3D2>Two problems:</FONT>
</P>

<P><FONT SIZE=3D2>1) An algorithm might conceivably require NO data, =
especially if it is </FONT>
<BR><FONT SIZE=3D2>dependent on a hardware token. PackagedContent =
should likely be repeated </FONT>
<BR><FONT SIZE=3D2>as (*) not as (+).</FONT>
</P>

<P><FONT SIZE=3D2>2) There is an unwarrented assumption here, that all =
algorithms can </FONT>
<BR><FONT SIZE=3D2>operate over the same PackagedContent. This is =
clearly not going to be </FONT>
<BR><FONT SIZE=3D2>the case. However, there is no way to assign =
individual 'packages' to </FONT>
<BR><FONT SIZE=3D2>the various algorithms.</FONT>
</P>

<P><FONT SIZE=3D2>There are a couple of ways out of this.</FONT>
</P>

<P><FONT SIZE=3D2>1: Limit AuthData to a single Algorithm and allow =
AuthData to repeat. </FONT>
<BR><FONT SIZE=3D2>Then it is a matter of choosing from multiple =
AuthData, not from </FONT>
<BR><FONT SIZE=3D2>multiple AlgorithmRefs. In such a situation, =
AlgorithmRef would be </FONT>
<BR><FONT SIZE=3D2>dropped as redundant.</FONT>
</P>

<P><FONT SIZE=3D2>This strikes me as the most useful, since the most =
common case will </FONT>
<BR><FONT SIZE=3D2>likely be a single choice of Algorithm.</FONT>
</P>

<P><FONT SIZE=3D2>2: Find a way to associate individual packages with =
algorithms. Do not </FONT>
<BR><FONT SIZE=3D2>use the package names for this, as the individual =
algorithms may have </FONT>
<BR><FONT SIZE=3D2>already used those for their own purposes. This =
might be done using the </FONT>
<BR><FONT SIZE=3D2>ID attributes from the PackagedContent items.</FONT>
</P>

<P><FONT SIZE=3D2>This would work, but I still prefer 1:</FONT>
</P>

<P><FONT =
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT=
>
<BR><FONT SIZE=3D2>Chris Smith, Royal Bank, 416.348.6090, =
[email-masked]</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BEA3C3.433C67D8--
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: Brand IDs & their registration.
Date: Fri, 21 May 1999 17:44:01 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I think tony meant this for the Trade list.

> ----------
> From: 	Lewis, Tony[SMTP:[email-masked]]
> Sent: 	20 May 1999 15:26
> To: 	David Burdett
> Subject: 	RE: Brand IDs & their registration.
> 
> Looks OK to me. I am not well versed in the syntax used, but it looks
> reasonable.
> 
> Tony
> > ----------
> > From: 	David Burdett[SMTP:[email-masked]]
> > Sent: 	Thursday, May 20, 1999 2:46 PM
> > To: 	Ietf Trade WG; Lewis, Tony
> > Subject: 	RE: Brand IDs & their registration.
> > 
> > I've been reading the emails on this topic and *think* I have a
> solution.
> > Details follow. But I really would like feedback on this before changing
> > the
> > spec.
> > 
> > David
> > 
> > INTRODUCTION
> > As I see it the requirement is as follows:
> > 1. We need to have a unique "brand id" so that we can link things like
> the
> > brand name, URL for the logo, etc to it.
> > 2. In addition for *some* payment protocols, we also need a protocol
> > specific version of a "brand id". For example for SET the payment
> protocol
> > specific of the Brand Id must be of the form "brand:[product]" and for
> EMV
> > it must be "RID+PIX", yet SCCD (I think) doesn't need a ProtocolBrandId
> at
> > all.
> > 
> > Currently the specification does not have a suitable "slot" into which
> to
> > put a payment protocol specific brand id. So how about the following as
> an
> > approach. It involves:
> > *	adding a new optional child element within the Brand elememt which
> > is protocol specific to hold the ProtocolBrandId, and
> > *	amending the definition of Brand Id in the Brand element of a Brand
> > list so that it becomes a pure IOTP defined brand id.
> > 
> > Detailed changes below ... 
> > 
> > BRAND ELEMENT.
> > 
> > Change the Brand Element definition (the ATTLIST doesn't change) from
> ...
> > 
> > 	<!ELEMENT Brand (PackagedContent*) >
> > 
> > ... to ...
> > 
> > 	<!ELEMENT Brand (ProtocolBrand*, PackagedContent*) >
> > 
> > The only other change to the Brand element is to change the definition
> of
> > the BrandId attribute to simply read ...
> > 
> > 	This contains a unique identifier for the brand (or promotional
> > brand). It is used to match against a list of Payment Instruments which
> > the
> > Consumer holds to determine whether or not the Consumer can pay with the
> > Brand.
> > 
> > 	BrandIds are controlled under the procedures defined in section 12
> > IANA Considerations. User defined values of BrandId may be used.
> > 
> > PROTOCOL BRAND ELEMENT.
> > The new ProtocolBrand element is then defined as ...
> > 
> > 	<!ELEMENT ProtocolBrand EMPTY>
> > 	<!ATTLIST ProtocolBrand
> > 	   ProtocolId         CDATA   #REQUIRED
> > 	   ProtocolBrandId    CDATA   #REQUIRED >
> > 
> > ... where ProtcolId must match the ProtocolId within a PayProtocol
> > element,
> > and ProtocolBrandId is the ProtocolBrandId to be used with that brand
> and
> > protocol.
> > 
> > EXAMPLE
> > For example a Visa gold card could be defined as follows ...
> > 
> >   <Brand ID = 'xxx'
> >     BrandId='VisaGold'
> >     BrandName='Visa Gold'
> >     BrandLogoNetLocn='http://otplogos.visa.com'
> >     ProtocolAmountRefs='xxx xxx'>
> >     <ProtocolBrand 
> >         ProtocolId='SETv1.0' 
> >         ProtocolBrandId='Visa:Gold' />
> >     <ProtocolBrand 
> >         ProtocolId='EMVv1.0' 
> >         ProtocolBrandId='0xA000000004:0xA000000032' />
> >   </Brand>
> > 
> > Responsibility for defining valid values of ProtocolId and the structure
> > of
> > the ProtocolBrandId (if there is one) that should be used with that
> > version
> > of the payment protocol would lie with the payment protocol supplement
> for
> > IOTP.
> > 
> > Initial values for BrandIds would be defined in the main IOTP
> > specification
> > and initial values for ProtocolBrandId in the payment protocol
> supplement.
> > In the future, new values of BrandId and their associated
> > ProtocolBrandId's
> > would use IANA procedures. More precisely ...
> > 
> > 	"New values of BrandId and their associated ProtocolBrandIds (if
> > any) 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."
> > 
> > In practice this means that if an established organisation (e.g
> > MasterCard,
> > Visa or Amex) wants to implement a new brand and give it a
> ProtocolBrandId
> > for each protocol to be used with it, then they can. It also means that
> > new
> > organisations with new brands can do the same sort of thing.
> > 
> > > ----------
> > > From: 	Lewis, Tony[SMTP:[email-masked]]
> > > Sent: 	18 May 1999 09:39
> > > To: 	Ietf Trade WG
> > > Subject: 	RE: Brand IDs & their registration. Was: RE: Comments on
> > > draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > 
> > > This chain has taken so many turns, I'm not convinced that I know what
> > > problem we're trying to solve anymore.
> > > 
> > > I think the problem is: How do we identify the brand that will be used
> > in
> > > a
> > > transaction regardless of payment protocol?
> > > 
> > > For SET, this is "brand[:product]". For EMV, this is RID+PIX. Other
> > > protocols will have their own internal method of encoding the brand.
> In
> > > all
> > > cases, the user will want to see a graphical representation of the
> Visa,
> > > MasterCard, Maestro, Mondex, etc. logo.
> > > 
> > > Do we need a new registry for brands? If we create such a registry,
> how
> > do
> > > we correlate those registrations with other schemes that know about
> the
> > > same
> > > brands? Are we going to have a big table somewhere that correlates
> IOTP
> > > brand, SET brand, EMV brand, etc.?
> > > 
> > > By the way, Visa does not imply "credit". It can be credit or debit.
> > > 
> > > Tony
> > > > ----------
> > > > From: 	David Burdett[SMTP:[email-masked]]
> > > > Sent: 	Monday, May 17, 1999 6:17 PM
> > > > To: 	[email-masked]; Lewis, Tony
> > > > Cc: 	Ietf Trade WG
> > > > Subject: 	RE: Brand IDs & their registration. Was: RE:
> Comments on
> > > > draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > > 
> > > > John/Tony
> > > > 
> > > > I don't think the RID+PIX is the way to go. Surely all we need is a
> > > > clearly
> > > > defined name declared in a public forum (e.g. the Trade WG or its
> > > > successor). For example we could declare:
> > > > *	MasterCard (implies credit)
> > > > *	Maestro (MasterCard debit)
> > > > *	Mondex (electronic cash)
> > > > *	Visa (implies credit)
> > > > *	VisaCash (electronic cash)
> > > > 
> > > > The "protocols" that can be used with each brand, e.g. SETv1.0,
> SCCD,
> > > etc.
> > > > are then separately specified with their own individual "payment
> > > > protocol/version no" identifiers. 
> > > > 
> > > > There is still the need to know which payment protocols can be used
> > with
> > > > each brand. However I don't think this an IOTP issue since:
> > > > *	Merchant's will know when they create a Brand List which
> protocols
> > > > are applicable for each Brand
> > > > *	Consumer's will know when they add a new brand what type of
> payment
> > > > instrument it is (e.g. Credit) and the consumer software can then
> > decide
> > > > which payment protocols apply.
> > > > 
> > > > Do you both agree?
> > > > 
> > > > David
> > > > 
> > > > > ----------
> > > > > From:
> > > > >
> > [email-masked][SMTP:[email-masked]]
> > > > > Sent: 	05 May 1999 23:01
> > > > > To: 	Ietf Trade WG
> > > > > Subject: 	RE: Brand IDs & their registration. Was: RE:
> > Comments on
> > > > > draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > > > 
> > > > > 
> > > > > 
> > > > > My understanding is that a RID (Registered ID obtained from ISO)
> is
> > > > > assigned
> > > > > more to an organization or association.
> > > > > 
> > > > > It is not easy to distinguish between
> > > > > a RID, a brand, and a consumer acceptance mark.
> > > > > 
> > > > > For MasterCard, the same RID is used for:
> > > > >    - MasterCard International chip credit cards,
> > > > >    - and Maestro International pin based debit cards - which uses
> a
> > > > > different
> > > > >    acceptance "mark" for what some consumers may consider a
> "brand".
> > > > > 
> > > > > For MasterCard's RID the hexadecimal characters 0xA000000004 have
> > been
> > > > > assigned
> > > > > by ISO to MasterCard.  The RID does not differentiate between our
> > > > > MasterCard and
> > > > > Maestro marks,
> > > > > but it is only the full RID + PIX (AID) that distinguishes what
> > > "brand"
> > > > or
> > > > > mark
> > > > > is involved.
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > "Lewis, Tony" <[email-masked]> on 05/04/99 08:09:25 PM
> > > > > 
> > > > > To:   Ietf Trade WG <[email-masked]>
> > > > > cc:    (bcc: John Wankmueller/NYC/MASTERCARD)
> > > > > Subject:  RE: Brand IDs & their registration. Was: RE: Comments on
> > > > > draft-ie tf-t
> > > > >       rade-iotp-v1.0-protocol-03.txt, part 1
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > In fact, Europay, MasterCard, and Visa have established EMVCo.
> > (EMVCo
> > > > does
> > > > > not currently have a web site so I can't point you there. I'm told
> > the
> > > > > site
> > > > > won't be up until July.)
> > > > > 
> > > > > EMV does not have brands in the same way that SET or IOTP do. EMV
> > > deals
> > > > > with
> > > > > application identifiers or AIDs. An AID consists of two parts: a
> > > > > Registered
> > > > > ID (RID) obtained from ISO and a Proprietary Extension (PIX). The
> > RID
> > > is
> > > > > roughly analogous to a brand. For example, Visa has an RID with a
> > > value
> > > > of
> > > > > 0xA000000003. Visa then assigns PIX values for various
> applications,
> > > > e.g.,
> > > > > Credit/Debit, VisaCash, etc.
> > > > > 
> > > > > Typically, an RID will be obtained by a payment brand, but there
> is
> > no
> > > > > guarantee that there is a one to one correspondence between a
> brand
> > > and
> > > > a
> > > > > RID.
> > > > > 
> > > > > As we look at a way to integrate EMV cards with SET, we expect to
> > add
> > > > AIDs
> > > > > to the SET Initiation message, which will ultimately be replaced
> by
> > > > IOTP.
> > > > > 
> > > > > Tony
> > > > > > ----------
> > > > > > From:   Steve Fabes[SMTP:[email-masked]]
> > > > > > Sent:   Tuesday, May 04, 1999 10:33 AM
> > > > > > To:     [email-masked]; Ietf Trade WG
> > > > > > Subject:     Re: Brand IDs & their registration. Was: RE:
> Comments
> > > on
> > > > > > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > > > >
> > > > > > Donald, I do not have much to add but when looking at the
> actions
> > of
> > > > > SETCo
> > > > > > we should also anticipate that the EMV world will establish
> EMVCo
> > > and
> > > > > its
> > > > > > rules will need to be considered along side those of SETCo's.
> The
> > > > > > membership
> > > > > > of the two Co's will overlap but be different and to assume the
> > same
> > > > > brand
> > > > > > and operating rules may be optimistic.
> > > > > > -----Original Message-----
> > > > > > From: [email-masked] <[email-masked]>
> > > > > > To: Ietf Trade WG <[email-masked]>
> > > > > > Date: Tuesday, May 04, 1999 09:33
> > > > > > Subject: RE: Brand IDs & their registration. Was: RE: Comments
> on
> > > > > > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > > > >
> > > > > >
> > > > > > >Regardless of EMV or whatever, it seems to me that we have a
> > > "brand"
> > > > > > registry
> > > > > > >problem to solve.  Credit/Debit cards are sort of odd creatures
> > > > because
> > > > > > they can
> > > > > > >be used in payments via multiple different protocols.  Most
> > stored
> > > > > value
> > > > > > cards
> > > > > > >can be used via only a single protocol.
> > > > > > >
> > > > > > >SETco clearly operates a card brand regisgration operations,
> > > however
> > > > > > limited and
> > > > > > >even if it's only expressed in the brand level certificates
> that
> > > > SETco
> > > > > > allows to
> > > > > > >be created under its root.  I think the hope was that the SET
> > > > > > registration
> > > > > > could
> > > > > > >be used in IOTP for all credit/debit cards.  This would at
> least
> > > > avoid
> > > > > > the
> > > > > > >problem where some brand was registered under different names
> at
> > > > > > different
> > > > > > >registries (where "different" could just be things like whether
> > > there
> > > > > is
> > > > > > really
> > > > > > >a space between American and Express or whether the C is
> > > capitalized
> > > > in
> > > > > > >Mastercard or whether Visa is all caps, ...).  Is there a list
> of
> > > > bands
> > > > > > >officially supported by SETco and their official names?
> > > > > > >
> > > > > > >However, if SETco is inappropriate for this, because they won't
> > > > > > "register"
> > > > > > >brands that haven't joined", then we need a separate solution.
> > It
> > > > > > certainly
> > > > > > >isn't very difficult to set up regsitration via IANA, probably
> > > using
> > > > > the
> > > > > > same
> > > > > > >Designated Expert criteria being used for other things.  The
> only
> > > > > > difficulty I
> > > > > > >can see is that some brand might get registered there for IOTP
> > use
> > > > and
> > > > > > then
> > > > > > >later join SETco or otherwise get registered in some other
> system
> > > > under
> > > > > > some
> > > > > > >other name.  Various messyness with Discover/Novus, AT&T
> > Universal
> > > > Card
> > > > > > changing
> > > > > > >to CitiBank Universal Card and the like occur to me.  I'm not
> > sure
> > > > > those
> > > > > > cases
> > > > > > >are actually name change problems but one can image such.
> > > > > > >
> > > > > > >All this seems to imply that we need to be prepared to register
> > > > > > credit/debit
> > > > > > >card brands under "IOTP:".  I'm a bit reluctant to drop the
> > "SET:"
> > > > > branch
> > > > > > of the
> > > > > > >brand tree in IOTP.  If some brand exists under SETco but
> hasn't
> > > yet
> > > > > been
> > > > > > >registered under IOTP, it seems like it should be usable.  Of
> > > course,
> > > > > > this
> > > > > > means
> > > > > > >that some brand registered under IOTP could later join SETco
> and
> > > > could
> > > > > > exist as
> > > > > > >both IOTP:BrandX and SET:BrandX or SET:Brand-ex.  So you might
> > get
> > > > into
> > > > > > >equivalence tables but these are really just an artifact of the
> > > real
> > > > > > world
> > > > > > being
> > > > > > >messy and not particularly worse than brands splitting or
> > merging.
> > > > > > >
> > > > > > >I don't see a major problem with us using
> > > > > > brand:[product]:[promotional-name] if
> > > > > > >we want, even after "SET:", although we should make it clear in
> > > that
> > > > > case
> > > > > > that
> > > > > > >these values differ from those permitted in the SET protocol.
> > The
> > > > > other
> > > > > > >possibility that occurs to me would be to use brand[:product]
> and
> > > > have
> > > > > a
> > > > > > >separate [promotional=xxx] optional attribute.
> > > > > > >
> > > > > > >What do people think?
> > > > > > >
> > > > > > >Thanks,
> > > > > > >Donald
> > > > > > >
> > > > > > >Donald E. Eastlake, 3rd
> > > > > > >17 Skyline Drive, Hawthorne, NY 10532 USA
> > > > > > >[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
> > > > > > >
> > > > > > >home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
> > > > > > >[email-masked]   tel: 1-914-276-2668
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >David Burdett <[email-masked]> on 04/29/99 12:17:01
> PM
> > > > > > >
> > > > > > >To:   Ietf Trade WG <[email-masked]>
> > > > > > >cc:   "Lewis, Tony" <[email-masked]> (bcc: Donald
> > > > > > Eastlake/Hawthorne/IBM)
> > > > > > >Subject:  RE: Brand IDs & their registration. Was: RE: Comments
> > on
> > > > > > draft-ie
> > > > > > >      tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >I agree with Tony. Smart card based EMV transactions will be
> the
> > > > > dominant
> > > > > > >payment model within a decade, probably even earlier especially
> > in
> > > > the
> > > > > > >non-US part of the world. The main reasons being, in my view:
> > > > > > >*    it will reduce fraud as it's much much harder to copy a
> > smart
> > > > card
> > > > > > >than a mag stripe card
> > > > > > >*    it makes internet credit card payments "card present"
> > > > transactions
> > > > > > >which should result in lower merchant fees. This also means
> that
> > it
> > > > > will
> > > > > > be
> > > > > > >much harder for customers to claim they never made an internet
> > > > purchase
> > > > > > >*    using a multi-application smart card you will be able to
> use
> > > > just
> > > > > > >one smart card for debit, credit, electronic cash, a loyalty
> > scheme
> > > > as
> > > > > > well
> > > > > > >as hold electronic tickets for anything from local cinema to
> your
> > > > next
> > > > > > >flight.
> > > > > > >
> > > > > > >To rephrase a MasterCard ad line, "smart cards are the future
> of
> > > > > money".
> > > > > > >
> > > > > > >David
> > > > > > >
> > > > > > >> ----------
> > > > > > >> From:   Lewis, Tony[SMTP:[email-masked]]
> > > > > > >> Sent:   28 April 1999 20:30
> > > > > > >> To:     Ietf Trade WG
> > > > > > >> Subject:     RE: Brand IDs & their registration. Was: RE:
> > > Comments
> > > > on
> > > > > > >> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > > > > >>
> > > > > > >> My point is that the brand is "Visa" no matter whether using
> > > IOTP,
> > > > > SET
> > > > > > or
> > > > > > >> any other protocol.
> > > > > > >>
> > > > > > >> As for EMV, the very first live SET 1.0 transaction was made
> > > using
> > > > an
> > > > > > EMV
> > > > > > >> card with the EMV data carried inside a SET message
> extension.
> > > EMV
> > > > > > credit
> > > > > > >> and debit products are a significant part of the future of
> > > > electronic
> > > > > > >> commerce. I expect they will be the dominant model for
> payment
> > in
> > > a
> > > > > > >> decade.
> > > > > > >>
> > > > > > >> Tony
> > > > > > >> > ----------
> > > > > > >> > From:      Steve Fabes[SMTP:[email-masked]]
> > > > > > >> > Sent:      Wednesday, April 28, 1999 3:43 PM
> > > > > > >> > To:   Lewis, Tony; Ietf Trade WG
> > > > > > >> > Subject:   Re: Brand IDs & their registration. Was: RE:
> > > Comments
> > > > on
> > > > > > >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > > > > >> >
> > > > > > >> > Tony - do your comments infer that SET.Visa will be the
> only
> > > > > > e-Commerce
> > > > > > >> > product that an IOTP product supplier can expect to see.
> Can
> > > you
> > > > > see
> > > > > > a
> > > > > > >> day
> > > > > > >> > when a Visa EMV 3.1.1 (or 3.x.x) based credit product could
> > > also
> > > > be
> > > > > > used
> > > > > > >> > inside an IOTP product?
> > > > > > >> > -----Original Message-----
> > > > > > >> > From: Lewis, Tony <[email-masked]>
> > > > > > >> > To: Ietf Trade WG <[email-masked]>
> > > > > > >> > Date: Wednesday, April 28, 1999 13:21
> > > > > > >> > Subject: RE: Brand IDs & their registration. Was: RE:
> > Comments
> > > on
> > > > > > >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > >David,
> > > > > > >> > >
> > > > > > >> > >I am new to this group and do not know what lead to the
> > > current
> > > > > > >> approach.
> > > > > > >> > >There are undoubtedly some issues that I don't know about.
> > > > > However,
> > > > > > it
> > > > > > >> > seems
> > > > > > >> > >to me that a brand is a brand no matter what payment
> > protocol
> > > is
> > > > > > being
> > > > > > >> > used.
> > > > > > >> > >The only difference I see between "IOTP:Visa" and
> "SET:Visa"
> > > is
> > > > > that
> > > > > > >> the
> > > > > > >> > >latter indicates that the brand is supported by a specific
> > > > payment
> > > > > > >> > protocol.
> > > > > > >> > >Since you need to support brands other than those
> supported
> > by
> > > > > SET,
> > > > > > >> there
> > > > > > >> > >will need to be a registry. It seems to me that there
> should
> > > > only
> > > > > be
> > > > > > >> one
> > > > > > >> > >such registry rather than the two being proposed. I
> > recommend
> > > > > having
> > > > > > a
> > > > > > >> > >single domain for these brands. It seems reasonable to
> > > initially
> > > > > > >> populate
> > > > > > >> > it
> > > > > > >> > >using the brands registered with SET and those non-SET
> > brands
> > > > you
> > > > > > >> listed
> > > > > > >> > in
> > > > > > >> > >your note.
> > > > > > >> > >
> > > > > > >> > >Tony
> > > > > > >> > >> ----------
> > > > > > >> > >> From: David Burdett[SMTP:[email-masked]]
> > > > > > >> > >> Sent: Wednesday, April 28, 1999 11:36 AM
> > > > > > >> > >> To: Ietf Trade WG; Lewis, Tony
> > > > > > >> > >> Subject: Brand IDs & their registration. Was: RE:
> Comments
> > > on
> > > > > > >> > >> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > > > > >> > >>
> > > > > > >> > >> In the current specification the basic idea for
> > identifying
> > > > > brands
> > > > > > is
> > > > > > >> > that
> > > > > > >> > >> they should be of the form "xxx:brandid" where "xxx" can
> > be
> > > > > "SET"
> > > > > > >> which
> > > > > > >> > >> indicates that the brandid is any valid brandid that is
> > > > accepted
> > > > > > by
> > > > > > >> > SET,
> > > > > > >> > >> or
> > > > > > >> > >> alternatively "IOTP" which can be used to define any
> brand
> > > not
> > > > > > >> defined
> > > > > > >> > by
> > > > > > >> > >> SET. The idea was that we should not need to define
> > "Visa",
> > > > > > >> > "MasterCard",
> > > > > > >> > >> "American Express", etc more than once since they are
> > > already
> > > > > > defined
> > > > > > >> > and
> > > > > > >> > >> registered by SET.
> > > > > > >> > >>
> > > > > > >> > >> However a couple of problems may arise ...
> > > > > > >> > >>
> > > > > > >> > >> USING THE SET BRAND ID FOR NON-SET PAYMENTS
> > > > > > >> > >> Although IOTP can support SET as a payment protocol, it
> > can
> > > > also
> > > > > > >> > support
> > > > > > >> > >> credit card payments (using Secure Channel Credit Debit
> -
> > > > SCCD)
> > > > > > where
> > > > > > >> > the
> > > > > > >> > >> credit card information (no, name, expiration date, etc)
> > is
> > > > > coded
> > > > > > >> > >> effectively in the clear but with privacy protection
> > > provided
> > > > by
> > > > > > >> using
> > > > > > >> > a
> > > > > > >> > >> secure channel such as SSL. In this way it provides a
> > > similar
> > > > > > level
> > > > > > >> of
> > > > > > >> > >> privacy/security as for credit card payments that occur
> > now
> > > > > where
> > > > > > a
> > > > > > >> web
> > > > > > >> > >> page
> > > > > > >> > >> form is completed by the user.
> > > > > > >> > >>
> > > > > > >> > >> My question is, will it be reasonable to use the SET
> > brandid
> > > > in
> > > > > > this
> > > > > > >> > way
> > > > > > >> > >> to
> > > > > > >> > >> cover non-SET credit card payments. I *think* the answer
> > is
> > > > > "yes"
> > > > > > as
> > > > > > >> > you
> > > > > > >> > >> can
> > > > > > >> > >> quite imagine a situation where a consumer is offered a
> > > choice
> > > > > of
> > > > > > >> using
> > > > > > >> > >> their VISA credit card to pay using either SET or SCCD.
> > > > > > >> > >>
> > > > > > >> > >> WHAT BRAND ID SHOULD BE USED FOR CO BRANDS
> > > > > > >> > >> If a payment brand, such as a local brand or co-brand,
> > > > chooses,
> > > > > > >> > initiall
> > > > > > >> > >> to
> > > > > > >> > >> use just SCCD rather than SET then they would not (I
> > think)
> > > > need
> > > > > > to
> > > > > > >> > >> register
> > > > > > >> > >> their brand with SET. In this case, they might register
> > > their
> > > > > > brand
> > > > > > >> as
> > > > > > >> > an
> > > > > > >> > >> "IOTP" brand. However if they later adopted SET, they
> > would
> > > > end
> > > > > up
> > > > > > >> with
> > > > > > >> > >> potentially two equivalent Brand IDs. Do you think we
> > might
> > > be
> > > > > > better
> > > > > > >> > off
> > > > > > >> > >> with a straight IOTP brand and keep all the names under
> > the
> > > > > > >> procedures
> > > > > > >> > >> defined by IANA? I'm not sure?
> > > > > > >> > >>
> > > > > > >> > >> REGISTERING NEW BRAND IDs
> > > > > > >> > >> To help assist in answering the last point, the
> following
> > is
> > > > > what
> > > > > > I'm
> > > > > > >> > >> currently writing as the proposed IANA procedure for
> > > > registering
> > > > > > new
> > > > > > >> > brand
> > > > > > >> > >> ids. Any comments:
> > > > > > >> > >>
> > > > > > >> > >> >>>Clip>>>
> > > > > > >> > >> The format of the Brand ID is either:
> > > > > > >> > >> * SET:setbrand where setbrand is a brand which is
> accepted
> > > by
> > > > > the
> > > > > > >> > >> [SET] payment protocol
> > > > > > >> > >> * IOTP:iotpbrand where iotpbrand may be:
> > > > > > >> > >> - GeldKarte
> > > > > > >> > >> - Mondex
> > > > > > >> > >>
> > > > > > >> > >> New values of the high level prefix (SET or IOTP) should
> > be
> > > > > > allocated
> > > > > > >> > >> following review on the IETF Trade Working Group mailing
> > > list
> > > > > and
> > > > > > by
> > > > > > >> > the
> > > > > > >> > >> Designated Expert.
> > > > > > >> > >>
> > > > > > >> > >> Values of "setbrand" are allocated as defined in the
> [SET]
> > > > > > >> > specifications.
> > > > > > >> > >>
> > > > > > >> > >> New values of "iotpbrand" must be announced to the IETF
> > > Trade
> > > > WG
> > > > > > >> > mailing
> > > > > > >> > >> list and, if there are no objections within three weeks,
> > be
> > > > > > allocated
> > > > > > >> > on
> > > > > > >> > a
> > > > > > >> > >> "first come first served" basis.
> > > > > > >> > >> <<<End Clip<<<
> > > > > > >> > >>
> > > > > > >> > >> Regards
> > > > > > >> > >>
> > > > > > >> > >> David
> > > > > > >> > >> > ----------
> > > > > > >> > >> > From: Lewis, Tony[SMTP:[email-masked]]
> > > > > > >> > >> > Sent: 28 April 1999 08:14
> > > > > > >> > >> > To: Ietf Trade WG
> > > > > > >> > >> > Subject: RE: Comments on
> > > > > > >> draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> > > > > > >> > >> > part  1
> > > > > > >> > >> >
> > > > > > >> > >> > In SET, the BrandID is either "brand" or
> > "brand:product".
> > > > > > >> > >> >
> > > > > > >> > >> > In Japan, there are products that are co-branded.
> > > > Essentially
> > > > > > these
> > > > > > >> > >> > products
> > > > > > >> > >> > are private label cards for domestic transactions with
> > an
> > > > > > >> > international
> > > > > > >> > >> > brand for non-domestic transactions. The private label
> > can
> > > > be
> > > > > > >> > reflected
> > > > > > >> > >> in
> > > > > > >> > >> > a
> > > > > > >> > >> > SET cardholder certificate as the "promotional card
> > name"
> > > > > under
> > > > > > the
> > > > > > >> > >> > international brand's hierarchy and/or the cardholder
> > can
> > > > have
> > > > > a
> > > > > > >> > >> > certificate
> > > > > > >> > >> > issued under the private label hierarchy.
> > > > > > >> > >> >
> > > > > > >> > >> > There is no provision to carry both the private label
> > (of
> > > > the
> > > > > > >> > Japanese
> > > > > > >> > >> > credit card company) and the international brand as
> part
> > > of
> > > > > the
> > > > > > SET
> > > > > > >> > >> > BrandID.
> > > > > > >> > >> >
> > > > > > >> > >> > Tony
> > > > > > >
> > > > > > >
> > > > > >
> > > >
> > >-----------------------------------------------------------------------
> > > > > > >Message addressed to: [email-masked]
> > > > > > >Archive available at:
> http://www.elistx.com/archives/ietf-trade/
> > > > > > >To (un)subscribe send a message with "subscribe" or
> "unsubscribe"
> > > in
> > > > > the
> > > > > > >body to: [email-masked]
> > > > > > >
> > > > > >
> > > > > >
> > > >
> > -----------------------------------------------------------------------
> > > > > > Message addressed to: [email-masked]
> > > > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > > > To (un)subscribe send a message with "subscribe" or
> "unsubscribe"
> > in
> > > > the
> > > > > > body to: [email-masked]
> > > > > >
> > > > >
> > >
> -----------------------------------------------------------------------
> > > > > Message addressed to: [email-masked]
> > > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > > To (un)subscribe send a message with "subscribe" or "unsubscribe"
> in
> > > the
> > > > > body to: [email-masked]
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > >
> > >
> -----------------------------------------------------------------------
> > > > > Message addressed to: [email-masked]
> > > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > > To (un)subscribe send a message with "subscribe" or "unsubscribe"
> in
> > > the
> > > > > body to: [email-masked]
> > > > > 
> > > > 
> > > >
> > >
> >
> **************************************************************************
> > > > ********************
> > > > 
> > > > This Email and any attached files are confidential and may also be
> > > > privileged. 
> > > > If you are not the intended recipient, please notify the postmaster
> > > using
> > > > email 
> > > > address [email-masked] or call +44 171 557 5000 and ask for
> the
> > 
> > > > IT Helpdesk.  You should not copy this email and any attached files,
> > use
> > > > them 
> > > > for any purpose or disclose the contents to any other person; all
> > copies
> > > > of the 
> > > > Email and associated files in your possession should be destroyed.
> > > > 
> > > > Mondex International Limited
> > > > 47-53 Cannon Street
> > > > London EC4M 5SQ
> > > > United Kingdom
> > > > Registered No: 3122085, England
> > > > 
> > > > Phone:          +44 171 557 5000
> > > > Fax:            +44 171 557 5200
> > > > Email:          [email-masked]
> > > > WebSite:        http://www.mondexinternational.com
> > > > 
> > > >
> > >
> >
> **************************************************************************
> > > > *******************
> > > > 
> > >
> -----------------------------------------------------------------------
> > > Message addressed to: [email-masked]
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > body to: [email-masked]
> > > 
> > 
> >
> **************************************************************************
> > ********************
> > 
> > This Email and any attached files are confidential and may also be
> > privileged. 
> > If you are not the intended recipient, please notify the postmaster
> using
> > email 
> > address [email-masked] or call +44 171 557 5000 and ask for the 
> > IT Helpdesk.  You should not copy this email and any attached files, use
> > them 
> > for any purpose or disclose the contents to any other person; all copies
> > of the 
> > Email and associated files in your possession should be destroyed.
> > 
> > Mondex International Limited
> > 47-53 Cannon Street
> > London EC4M 5SQ
> > United Kingdom
> > Registered No: 3122085, England
> > 
> > Phone:          +44 171 557 5000
> > Fax:            +44 171 557 5200
> > Email:          [email-masked]
> > WebSite:        http://www.mondexinternational.com
> > 
> >
> **************************************************************************
> > *******************
> > 
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>, [email-masked]
Subject: RE: Using XML as well as HTML
Date: Fri, 21 May 1999 15:24:38 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

OK

David
> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	20 May 1999 12:44
> To: 	[email-masked]
> Subject: 	RE: Using XML as well as HTML
> 
> While it is true that XSL and how to link it to an XML document isn't
> finalized
> yet, I'm not sure how much we should worry about that.  It seems very
> likely
> there will be some way to link style sheets out of an XML document so as
> long as
> the full documents in the XML syntax sense are included.  I don't think it
> is a
> good idea to just say "at the discretion of the implementer".  How about
> just
> saying "implementers should follow the latest recommendations of the W3C"?
> 
> Thanks,
> Donald
> 
> Donald E. Eastlake, 3rd
> 17 Skyline Drive, Hawthorne, NY 10532 USA
> [email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
> 
> home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
> [email-masked]   tel: 1-914-276-2668
> 
> 
> 
> David Burdett <[email-masked]> on 05/17/99 09:17:01 PM
> 
> To:   Ietf Trade WG <[email-masked]>, Don Eastlake
>       <[email-masked]>
> cc:    (bcc: Donald Eastlake/Hawthorne/IBM)
> Subject:  RE: Using XML as well as HTML
> 
> 
> 
> 
> 
> The problem is that the XML style sheet (XSL) specifications are not
> finalised. Specifically:
> *    "Associating stylesheets with XML documents" at
> http://www.w3.org/TR/xml-stylesheet is a proposed recommendation and
> requires comments to be submitted by 26 May, and
> *    "Extensible Stylesheet Language (XSL) Specification" at
> http://www.w3.org/TR/WD-xsl is just a working draft.
> 
> The first document also states  " ... the technology explained in this
> Proposed Recommendation is not the only one for its task. There are others
> available or under development that allow the link to be outside the XML
> document ..." which means that further changes can be anticipated.
> 
> Therefore I suggest that the a "XML Packaging" section is added to the
> IOTP
> specification after the existing section on "HTML packaging" that says ...
> 
> "Support for XML is recommended. When XML needs to be displayed, for
> example
> to display the content of an Order Description to a Consumer, then the
> method employed is at the discretion of the implementer.
> 
>      [Note]    At the time of writing this specification, standards are
> under development that specify XML style sheets that show how XML
> documents
> should be displayed. See:
>                     *    "Extensible Stylesheet Language
> (XSL) Specification" at http://www.w3.org/TR/WD-xsl, and
>                     *    "Associating stylesheets with XML
> documents" at http://www.w3.org/TR/xml-stylesheet.
>                     Once these standards become W3C
> "Recommendations", then it is anticipated that this specification will be
> amended if practical.
>      [Note End]      "
> 
> ... and change references to "plain text and HTML" to additionally refer
> to
> XML  for instance ...
> 
> "For interoperability, implementations must support Plain Text, HTML and
> XML
> as a minimum so that it can be easily displayed."
> 
> This applies to the sections on: "Order Description Content", "Payment
> Note"
> and "Delivery Note"
> 
> Any comments?
> 
> David
> > ----------
> > From:   Donald E. Eastlake 3rd[SMTP:[email-masked]]
> > Sent:   10 May 1999 19:56
> > To:     Ietf Trade WG
> > Subject:     Re: Using XML as well as HTML
> >
> > It seems to me that the solution for this involves, among other things,
> > the Offer Request message we have defered until after v1.0...
> >
> > I suggest we go for simplicity in v1.0 and just say that support of
> > XML is recommended even though your point about XML support at some
> > level being implied since IOTP uses XML syntax...
> >
> > Thanks,
> > Donald
> >
> > From:  David Burdett <[email-masked]>
> > Message-Id:
> <[email-masked]>
> > Date:  Fri, 30 Apr 1999 20:04:09 +0100
> >
> > >I agree that XML should be recommended, the problem is how do you
> > discover
> > >if the consumer has XML/XSL support in their IOTP implementation?
> > >
> > >If a merchant or one of the other trading roles is unsure, then they'll
> > >never send order descrciptions, etc, in XML to the consumer. On the
> other
> > >hand if a particular IOTP consumer client software becomes highly
> popular
> > >that supports XML/XSL, then it is reasonable safe for merchants to use
> > XML
> > >and more might do so.
> > >
> > >Finally, you could argue that since to do IOTP at all, there must be
> XML
> > >support then at least half the solution *must* be there. In this case,
> > you
> > >could recommend displaying a message to the user of the problem and
> > >displaying XML in a very simple way.
> > >
> > >David
> > >
> > >
> > >> ----------
> > >> From:     Donald E. Eastlake 3rd[SMTP:[email-masked]]
> > >> Sent:     29 April 1999 10:04
> > >> To:  Ietf Trade WG
> > >> Subject:  Re: Using XML as well as HTML
> > >>
> > >> I believe that support for XML should be recommended but not
> required.
> > >>
> > >> Thanks,
> > >> Donald
> > >>
> > >> From:  David Burdett <[email-masked]>
> > >> Message-Id:
> > <[email-masked]>
> > >> To:  Ietf Trade WG <[email-masked]>
> > >> Date:  Thu, 29 Apr 1999 17:17:05 +0100
> > >>
> > >> >Following on from my other email on using HTML, the spec doesn't
> > >> currently
> > >> >describe how XML could be used. I think that it should. We could
> > provide
> > >> >similar guidelines for XML/XSL to the ones for HTML.
> > >> >
> > >> >Who thinks this is a good idea?
> > >> >
> > >> >David
> > >> >
> > >> >THIS EMAIL IS FOR UNRESTRICTED DISTRIBUTION
> > >> >> mailto:<[email-masked]>
> > >> >> Mondex International, US Advanced Technology Office
> > >> >> 111 Pine St, 6th Floor, San Francisco, CA 94111
> > >> >> Tel/Voicemail: +1 415 645 6973   Fax: +1 415 956 9370
> > >>
> -----------------------------------------------------------------------
> 
> 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>, Tony Lewis <[email-masked]>
Subject: RE: Brand IDs & their registration.
Date: Thu, 20 May 1999 22:46:00 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I've been reading the emails on this topic and *think* I have a solution.
Details follow. But I really would like feedback on this before changing the
spec.

David

INTRODUCTION
As I see it the requirement is as follows:
1. We need to have a unique "brand id" so that we can link things like the
brand name, URL for the logo, etc to it.
2. In addition for *some* payment protocols, we also need a protocol
specific version of a "brand id". For example for SET the payment protocol
specific of the Brand Id must be of the form "brand:[product]" and for EMV
it must be "RID+PIX", yet SCCD (I think) doesn't need a ProtocolBrandId at
all.

Currently the specification does not have a suitable "slot" into which to
put a payment protocol specific brand id. So how about the following as an
approach. It involves:
*	adding a new optional child element within the Brand elememt which
is protocol specific to hold the ProtocolBrandId, and
*	amending the definition of Brand Id in the Brand element of a Brand
list so that it becomes a pure IOTP defined brand id.

Detailed changes below ... 

BRAND ELEMENT.

Change the Brand Element definition (the ATTLIST doesn't change) from ...

	<!ELEMENT Brand (PackagedContent*) >

... to ...

	<!ELEMENT Brand (ProtocolBrand*, PackagedContent*) >

The only other change to the Brand element is to change the definition of
the BrandId attribute to simply read ...

	This contains a unique identifier for the brand (or promotional
brand). It is used to match against a list of Payment Instruments which the
Consumer holds to determine whether or not the Consumer can pay with the
Brand.

	BrandIds are controlled under the procedures defined in section 12
IANA Considerations. User defined values of BrandId may be used.

PROTOCOL BRAND ELEMENT.
The new ProtocolBrand element is then defined as ...

	<!ELEMENT ProtocolBrand EMPTY>
	<!ATTLIST ProtocolBrand
	   ProtocolId         CDATA   #REQUIRED
	   ProtocolBrandId    CDATA   #REQUIRED >

... where ProtcolId must match the ProtocolId within a PayProtocol element,
and ProtocolBrandId is the ProtocolBrandId to be used with that brand and
protocol.

EXAMPLE
For example a Visa gold card could be defined as follows ...

  <Brand ID = 'xxx'
    BrandId='VisaGold'
    BrandName='Visa Gold'
    BrandLogoNetLocn='http://otplogos.visa.com'
    ProtocolAmountRefs='xxx xxx'>
    <ProtocolBrand 
        ProtocolId='SETv1.0' 
        ProtocolBrandId='Visa:Gold' />
    <ProtocolBrand 
        ProtocolId='EMVv1.0' 
        ProtocolBrandId='0xA000000004:0xA000000032' />
  </Brand>

Responsibility for defining valid values of ProtocolId and the structure of
the ProtocolBrandId (if there is one) that should be used with that version
of the payment protocol would lie with the payment protocol supplement for
IOTP.

Initial values for BrandIds would be defined in the main IOTP specification
and initial values for ProtocolBrandId in the payment protocol supplement.
In the future, new values of BrandId and their associated ProtocolBrandId's
would use IANA procedures. More precisely ...

	"New values of BrandId and their associated ProtocolBrandIds (if
any) 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."

In practice this means that if an established organisation (e.g MasterCard,
Visa or Amex) wants to implement a new brand and give it a ProtocolBrandId
for each protocol to be used with it, then they can. It also means that new
organisations with new brands can do the same sort of thing.

> ----------
> From: 	Lewis, Tony[SMTP:[email-masked]]
> Sent: 	18 May 1999 09:39
> To: 	Ietf Trade WG
> Subject: 	RE: Brand IDs & their registration. Was: RE: Comments on
> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
> 
> This chain has taken so many turns, I'm not convinced that I know what
> problem we're trying to solve anymore.
> 
> I think the problem is: How do we identify the brand that will be used in
> a
> transaction regardless of payment protocol?
> 
> For SET, this is "brand[:product]". For EMV, this is RID+PIX. Other
> protocols will have their own internal method of encoding the brand. In
> all
> cases, the user will want to see a graphical representation of the Visa,
> MasterCard, Maestro, Mondex, etc. logo.
> 
> Do we need a new registry for brands? If we create such a registry, how do
> we correlate those registrations with other schemes that know about the
> same
> brands? Are we going to have a big table somewhere that correlates IOTP
> brand, SET brand, EMV brand, etc.?
> 
> By the way, Visa does not imply "credit". It can be credit or debit.
> 
> Tony
> > ----------
> > From: 	David Burdett[SMTP:[email-masked]]
> > Sent: 	Monday, May 17, 1999 6:17 PM
> > To: 	[email-masked]; Lewis, Tony
> > Cc: 	Ietf Trade WG
> > Subject: 	RE: Brand IDs & their registration. Was: RE: Comments on
> > draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > 
> > John/Tony
> > 
> > I don't think the RID+PIX is the way to go. Surely all we need is a
> > clearly
> > defined name declared in a public forum (e.g. the Trade WG or its
> > successor). For example we could declare:
> > *	MasterCard (implies credit)
> > *	Maestro (MasterCard debit)
> > *	Mondex (electronic cash)
> > *	Visa (implies credit)
> > *	VisaCash (electronic cash)
> > 
> > The "protocols" that can be used with each brand, e.g. SETv1.0, SCCD,
> etc.
> > are then separately specified with their own individual "payment
> > protocol/version no" identifiers. 
> > 
> > There is still the need to know which payment protocols can be used with
> > each brand. However I don't think this an IOTP issue since:
> > *	Merchant's will know when they create a Brand List which protocols
> > are applicable for each Brand
> > *	Consumer's will know when they add a new brand what type of payment
> > instrument it is (e.g. Credit) and the consumer software can then decide
> > which payment protocols apply.
> > 
> > Do you both agree?
> > 
> > David
> > 
> > > ----------
> > > From:
> > > [email-masked][SMTP:[email-masked]]
> > > Sent: 	05 May 1999 23:01
> > > To: 	Ietf Trade WG
> > > Subject: 	RE: Brand IDs & their registration. Was: RE: Comments on
> > > draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > 
> > > 
> > > 
> > > My understanding is that a RID (Registered ID obtained from ISO) is
> > > assigned
> > > more to an organization or association.
> > > 
> > > It is not easy to distinguish between
> > > a RID, a brand, and a consumer acceptance mark.
> > > 
> > > For MasterCard, the same RID is used for:
> > >    - MasterCard International chip credit cards,
> > >    - and Maestro International pin based debit cards - which uses a
> > > different
> > >    acceptance "mark" for what some consumers may consider a "brand".
> > > 
> > > For MasterCard's RID the hexadecimal characters 0xA000000004 have been
> > > assigned
> > > by ISO to MasterCard.  The RID does not differentiate between our
> > > MasterCard and
> > > Maestro marks,
> > > but it is only the full RID + PIX (AID) that distinguishes what
> "brand"
> > or
> > > mark
> > > is involved.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > "Lewis, Tony" <[email-masked]> on 05/04/99 08:09:25 PM
> > > 
> > > To:   Ietf Trade WG <[email-masked]>
> > > cc:    (bcc: John Wankmueller/NYC/MASTERCARD)
> > > Subject:  RE: Brand IDs & their registration. Was: RE: Comments on
> > > draft-ie tf-t
> > >       rade-iotp-v1.0-protocol-03.txt, part 1
> > > 
> > > 
> > > 
> > > 
> > > In fact, Europay, MasterCard, and Visa have established EMVCo. (EMVCo
> > does
> > > not currently have a web site so I can't point you there. I'm told the
> > > site
> > > won't be up until July.)
> > > 
> > > EMV does not have brands in the same way that SET or IOTP do. EMV
> deals
> > > with
> > > application identifiers or AIDs. An AID consists of two parts: a
> > > Registered
> > > ID (RID) obtained from ISO and a Proprietary Extension (PIX). The RID
> is
> > > roughly analogous to a brand. For example, Visa has an RID with a
> value
> > of
> > > 0xA000000003. Visa then assigns PIX values for various applications,
> > e.g.,
> > > Credit/Debit, VisaCash, etc.
> > > 
> > > Typically, an RID will be obtained by a payment brand, but there is no
> > > guarantee that there is a one to one correspondence between a brand
> and
> > a
> > > RID.
> > > 
> > > As we look at a way to integrate EMV cards with SET, we expect to add
> > AIDs
> > > to the SET Initiation message, which will ultimately be replaced by
> > IOTP.
> > > 
> > > Tony
> > > > ----------
> > > > From:   Steve Fabes[SMTP:[email-masked]]
> > > > Sent:   Tuesday, May 04, 1999 10:33 AM
> > > > To:     [email-masked]; Ietf Trade WG
> > > > Subject:     Re: Brand IDs & their registration. Was: RE: Comments
> on
> > > > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > >
> > > > Donald, I do not have much to add but when looking at the actions of
> > > SETCo
> > > > we should also anticipate that the EMV world will establish EMVCo
> and
> > > its
> > > > rules will need to be considered along side those of SETCo's. The
> > > > membership
> > > > of the two Co's will overlap but be different and to assume the same
> > > brand
> > > > and operating rules may be optimistic.
> > > > -----Original Message-----
> > > > From: [email-masked] <[email-masked]>
> > > > To: Ietf Trade WG <[email-masked]>
> > > > Date: Tuesday, May 04, 1999 09:33
> > > > Subject: RE: Brand IDs & their registration. Was: RE: Comments on
> > > > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > >
> > > >
> > > > >Regardless of EMV or whatever, it seems to me that we have a
> "brand"
> > > > registry
> > > > >problem to solve.  Credit/Debit cards are sort of odd creatures
> > because
> > > > they can
> > > > >be used in payments via multiple different protocols.  Most stored
> > > value
> > > > cards
> > > > >can be used via only a single protocol.
> > > > >
> > > > >SETco clearly operates a card brand regisgration operations,
> however
> > > > limited and
> > > > >even if it's only expressed in the brand level certificates that
> > SETco
> > > > allows to
> > > > >be created under its root.  I think the hope was that the SET
> > > > registration
> > > > could
> > > > >be used in IOTP for all credit/debit cards.  This would at least
> > avoid
> > > > the
> > > > >problem where some brand was registered under different names at
> > > > different
> > > > >registries (where "different" could just be things like whether
> there
> > > is
> > > > really
> > > > >a space between American and Express or whether the C is
> capitalized
> > in
> > > > >Mastercard or whether Visa is all caps, ...).  Is there a list of
> > bands
> > > > >officially supported by SETco and their official names?
> > > > >
> > > > >However, if SETco is inappropriate for this, because they won't
> > > > "register"
> > > > >brands that haven't joined", then we need a separate solution.  It
> > > > certainly
> > > > >isn't very difficult to set up regsitration via IANA, probably
> using
> > > the
> > > > same
> > > > >Designated Expert criteria being used for other things.  The only
> > > > difficulty I
> > > > >can see is that some brand might get registered there for IOTP use
> > and
> > > > then
> > > > >later join SETco or otherwise get registered in some other system
> > under
> > > > some
> > > > >other name.  Various messyness with Discover/Novus, AT&T Universal
> > Card
> > > > changing
> > > > >to CitiBank Universal Card and the like occur to me.  I'm not sure
> > > those
> > > > cases
> > > > >are actually name change problems but one can image such.
> > > > >
> > > > >All this seems to imply that we need to be prepared to register
> > > > credit/debit
> > > > >card brands under "IOTP:".  I'm a bit reluctant to drop the "SET:"
> > > branch
> > > > of the
> > > > >brand tree in IOTP.  If some brand exists under SETco but hasn't
> yet
> > > been
> > > > >registered under IOTP, it seems like it should be usable.  Of
> course,
> > > > this
> > > > means
> > > > >that some brand registered under IOTP could later join SETco and
> > could
> > > > exist as
> > > > >both IOTP:BrandX and SET:BrandX or SET:Brand-ex.  So you might get
> > into
> > > > >equivalence tables but these are really just an artifact of the
> real
> > > > world
> > > > being
> > > > >messy and not particularly worse than brands splitting or merging.
> > > > >
> > > > >I don't see a major problem with us using
> > > > brand:[product]:[promotional-name] if
> > > > >we want, even after "SET:", although we should make it clear in
> that
> > > case
> > > > that
> > > > >these values differ from those permitted in the SET protocol.  The
> > > other
> > > > >possibility that occurs to me would be to use brand[:product] and
> > have
> > > a
> > > > >separate [promotional=xxx] optional attribute.
> > > > >
> > > > >What do people think?
> > > > >
> > > > >Thanks,
> > > > >Donald
> > > > >
> > > > >Donald E. Eastlake, 3rd
> > > > >17 Skyline Drive, Hawthorne, NY 10532 USA
> > > > >[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
> > > > >
> > > > >home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
> > > > >[email-masked]   tel: 1-914-276-2668
> > > > >
> > > > >
> > > > >
> > > > >David Burdett <[email-masked]> on 04/29/99 12:17:01 PM
> > > > >
> > > > >To:   Ietf Trade WG <[email-masked]>
> > > > >cc:   "Lewis, Tony" <[email-masked]> (bcc: Donald
> > > > Eastlake/Hawthorne/IBM)
> > > > >Subject:  RE: Brand IDs & their registration. Was: RE: Comments on
> > > > draft-ie
> > > > >      tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >I agree with Tony. Smart card based EMV transactions will be the
> > > dominant
> > > > >payment model within a decade, probably even earlier especially in
> > the
> > > > >non-US part of the world. The main reasons being, in my view:
> > > > >*    it will reduce fraud as it's much much harder to copy a smart
> > card
> > > > >than a mag stripe card
> > > > >*    it makes internet credit card payments "card present"
> > transactions
> > > > >which should result in lower merchant fees. This also means that it
> > > will
> > > > be
> > > > >much harder for customers to claim they never made an internet
> > purchase
> > > > >*    using a multi-application smart card you will be able to use
> > just
> > > > >one smart card for debit, credit, electronic cash, a loyalty scheme
> > as
> > > > well
> > > > >as hold electronic tickets for anything from local cinema to your
> > next
> > > > >flight.
> > > > >
> > > > >To rephrase a MasterCard ad line, "smart cards are the future of
> > > money".
> > > > >
> > > > >David
> > > > >
> > > > >> ----------
> > > > >> From:   Lewis, Tony[SMTP:[email-masked]]
> > > > >> Sent:   28 April 1999 20:30
> > > > >> To:     Ietf Trade WG
> > > > >> Subject:     RE: Brand IDs & their registration. Was: RE:
> Comments
> > on
> > > > >> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > > >>
> > > > >> My point is that the brand is "Visa" no matter whether using
> IOTP,
> > > SET
> > > > or
> > > > >> any other protocol.
> > > > >>
> > > > >> As for EMV, the very first live SET 1.0 transaction was made
> using
> > an
> > > > EMV
> > > > >> card with the EMV data carried inside a SET message extension.
> EMV
> > > > credit
> > > > >> and debit products are a significant part of the future of
> > electronic
> > > > >> commerce. I expect they will be the dominant model for payment in
> a
> > > > >> decade.
> > > > >>
> > > > >> Tony
> > > > >> > ----------
> > > > >> > From:      Steve Fabes[SMTP:[email-masked]]
> > > > >> > Sent:      Wednesday, April 28, 1999 3:43 PM
> > > > >> > To:   Lewis, Tony; Ietf Trade WG
> > > > >> > Subject:   Re: Brand IDs & their registration. Was: RE:
> Comments
> > on
> > > > >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > > >> >
> > > > >> > Tony - do your comments infer that SET.Visa will be the only
> > > > e-Commerce
> > > > >> > product that an IOTP product supplier can expect to see. Can
> you
> > > see
> > > > a
> > > > >> day
> > > > >> > when a Visa EMV 3.1.1 (or 3.x.x) based credit product could
> also
> > be
> > > > used
> > > > >> > inside an IOTP product?
> > > > >> > -----Original Message-----
> > > > >> > From: Lewis, Tony <[email-masked]>
> > > > >> > To: Ietf Trade WG <[email-masked]>
> > > > >> > Date: Wednesday, April 28, 1999 13:21
> > > > >> > Subject: RE: Brand IDs & their registration. Was: RE: Comments
> on
> > > > >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > > >> >
> > > > >> >
> > > > >> > >David,
> > > > >> > >
> > > > >> > >I am new to this group and do not know what lead to the
> current
> > > > >> approach.
> > > > >> > >There are undoubtedly some issues that I don't know about.
> > > However,
> > > > it
> > > > >> > seems
> > > > >> > >to me that a brand is a brand no matter what payment protocol
> is
> > > > being
> > > > >> > used.
> > > > >> > >The only difference I see between "IOTP:Visa" and "SET:Visa"
> is
> > > that
> > > > >> the
> > > > >> > >latter indicates that the brand is supported by a specific
> > payment
> > > > >> > protocol.
> > > > >> > >Since you need to support brands other than those supported by
> > > SET,
> > > > >> there
> > > > >> > >will need to be a registry. It seems to me that there should
> > only
> > > be
> > > > >> one
> > > > >> > >such registry rather than the two being proposed. I recommend
> > > having
> > > > a
> > > > >> > >single domain for these brands. It seems reasonable to
> initially
> > > > >> populate
> > > > >> > it
> > > > >> > >using the brands registered with SET and those non-SET brands
> > you
> > > > >> listed
> > > > >> > in
> > > > >> > >your note.
> > > > >> > >
> > > > >> > >Tony
> > > > >> > >> ----------
> > > > >> > >> From: David Burdett[SMTP:[email-masked]]
> > > > >> > >> Sent: Wednesday, April 28, 1999 11:36 AM
> > > > >> > >> To: Ietf Trade WG; Lewis, Tony
> > > > >> > >> Subject: Brand IDs & their registration. Was: RE: Comments
> on
> > > > >> > >> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > > >> > >>
> > > > >> > >> In the current specification the basic idea for identifying
> > > brands
> > > > is
> > > > >> > that
> > > > >> > >> they should be of the form "xxx:brandid" where "xxx" can be
> > > "SET"
> > > > >> which
> > > > >> > >> indicates that the brandid is any valid brandid that is
> > accepted
> > > > by
> > > > >> > SET,
> > > > >> > >> or
> > > > >> > >> alternatively "IOTP" which can be used to define any brand
> not
> > > > >> defined
> > > > >> > by
> > > > >> > >> SET. The idea was that we should not need to define "Visa",
> > > > >> > "MasterCard",
> > > > >> > >> "American Express", etc more than once since they are
> already
> > > > defined
> > > > >> > and
> > > > >> > >> registered by SET.
> > > > >> > >>
> > > > >> > >> However a couple of problems may arise ...
> > > > >> > >>
> > > > >> > >> USING THE SET BRAND ID FOR NON-SET PAYMENTS
> > > > >> > >> Although IOTP can support SET as a payment protocol, it can
> > also
> > > > >> > support
> > > > >> > >> credit card payments (using Secure Channel Credit Debit -
> > SCCD)
> > > > where
> > > > >> > the
> > > > >> > >> credit card information (no, name, expiration date, etc) is
> > > coded
> > > > >> > >> effectively in the clear but with privacy protection
> provided
> > by
> > > > >> using
> > > > >> > a
> > > > >> > >> secure channel such as SSL. In this way it provides a
> similar
> > > > level
> > > > >> of
> > > > >> > >> privacy/security as for credit card payments that occur now
> > > where
> > > > a
> > > > >> web
> > > > >> > >> page
> > > > >> > >> form is completed by the user.
> > > > >> > >>
> > > > >> > >> My question is, will it be reasonable to use the SET brandid
> > in
> > > > this
> > > > >> > way
> > > > >> > >> to
> > > > >> > >> cover non-SET credit card payments. I *think* the answer is
> > > "yes"
> > > > as
> > > > >> > you
> > > > >> > >> can
> > > > >> > >> quite imagine a situation where a consumer is offered a
> choice
> > > of
> > > > >> using
> > > > >> > >> their VISA credit card to pay using either SET or SCCD.
> > > > >> > >>
> > > > >> > >> WHAT BRAND ID SHOULD BE USED FOR CO BRANDS
> > > > >> > >> If a payment brand, such as a local brand or co-brand,
> > chooses,
> > > > >> > initiall
> > > > >> > >> to
> > > > >> > >> use just SCCD rather than SET then they would not (I think)
> > need
> > > > to
> > > > >> > >> register
> > > > >> > >> their brand with SET. In this case, they might register
> their
> > > > brand
> > > > >> as
> > > > >> > an
> > > > >> > >> "IOTP" brand. However if they later adopted SET, they would
> > end
> > > up
> > > > >> with
> > > > >> > >> potentially two equivalent Brand IDs. Do you think we might
> be
> > > > better
> > > > >> > off
> > > > >> > >> with a straight IOTP brand and keep all the names under the
> > > > >> procedures
> > > > >> > >> defined by IANA? I'm not sure?
> > > > >> > >>
> > > > >> > >> REGISTERING NEW BRAND IDs
> > > > >> > >> To help assist in answering the last point, the following is
> > > what
> > > > I'm
> > > > >> > >> currently writing as the proposed IANA procedure for
> > registering
> > > > new
> > > > >> > brand
> > > > >> > >> ids. Any comments:
> > > > >> > >>
> > > > >> > >> >>>Clip>>>
> > > > >> > >> The format of the Brand ID is either:
> > > > >> > >> * SET:setbrand where setbrand is a brand which is accepted
> by
> > > the
> > > > >> > >> [SET] payment protocol
> > > > >> > >> * IOTP:iotpbrand where iotpbrand may be:
> > > > >> > >> - GeldKarte
> > > > >> > >> - Mondex
> > > > >> > >>
> > > > >> > >> New values of the high level prefix (SET or IOTP) should be
> > > > allocated
> > > > >> > >> following review on the IETF Trade Working Group mailing
> list
> > > and
> > > > by
> > > > >> > the
> > > > >> > >> Designated Expert.
> > > > >> > >>
> > > > >> > >> Values of "setbrand" are allocated as defined in the [SET]
> > > > >> > specifications.
> > > > >> > >>
> > > > >> > >> New values of "iotpbrand" must be announced to the IETF
> Trade
> > WG
> > > > >> > mailing
> > > > >> > >> list and, if there are no objections within three weeks, be
> > > > allocated
> > > > >> > on
> > > > >> > a
> > > > >> > >> "first come first served" basis.
> > > > >> > >> <<<End Clip<<<
> > > > >> > >>
> > > > >> > >> Regards
> > > > >> > >>
> > > > >> > >> David
> > > > >> > >> > ----------
> > > > >> > >> > From: Lewis, Tony[SMTP:[email-masked]]
> > > > >> > >> > Sent: 28 April 1999 08:14
> > > > >> > >> > To: Ietf Trade WG
> > > > >> > >> > Subject: RE: Comments on
> > > > >> draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> > > > >> > >> > part  1
> > > > >> > >> >
> > > > >> > >> > In SET, the BrandID is either "brand" or "brand:product".
> > > > >> > >> >
> > > > >> > >> > In Japan, there are products that are co-branded.
> > Essentially
> > > > these
> > > > >> > >> > products
> > > > >> > >> > are private label cards for domestic transactions with an
> > > > >> > international
> > > > >> > >> > brand for non-domestic transactions. The private label can
> > be
> > > > >> > reflected
> > > > >> > >> in
> > > > >> > >> > a
> > > > >> > >> > SET cardholder certificate as the "promotional card name"
> > > under
> > > > the
> > > > >> > >> > international brand's hierarchy and/or the cardholder can
> > have
> > > a
> > > > >> > >> > certificate
> > > > >> > >> > issued under the private label hierarchy.
> > > > >> > >> >
> > > > >> > >> > There is no provision to carry both the private label (of
> > the
> > > > >> > Japanese
> > > > >> > >> > credit card company) and the international brand as part
> of
> > > the
> > > > SET
> > > > >> > >> > BrandID.
> > > > >> > >> >
> > > > >> > >> > Tony
> > > > >
> > > > >
> > > >
> > >-----------------------------------------------------------------------
> > > > >Message addressed to: [email-masked]
> > > > >Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > >To (un)subscribe send a message with "subscribe" or "unsubscribe"
> in
> > > the
> > > > >body to: [email-masked]
> > > > >
> > > >
> > > >
> > -----------------------------------------------------------------------
> > > > Message addressed to: [email-masked]
> > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> > the
> > > > body to: [email-masked]
> > > >
> > >
> -----------------------------------------------------------------------
> > > Message addressed to: [email-masked]
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > body to: [email-masked]
> > > 
> > > 
> > > 
> > > 
> > >
> -----------------------------------------------------------------------
> > > Message addressed to: [email-masked]
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > body to: [email-masked]
> > > 
> > 
> >
> **************************************************************************
> > ********************
> > 
> > This Email and any attached files are confidential and may also be
> > privileged. 
> > If you are not the intended recipient, please notify the postmaster
> using
> > email 
> > address [email-masked] or call +44 171 557 5000 and ask for the 
> > IT Helpdesk.  You should not copy this email and any attached files, use
> > them 
> > for any purpose or disclose the contents to any other person; all copies
> > of the 
> > Email and associated files in your possession should be destroyed.
> > 
> > Mondex International Limited
> > 47-53 Cannon Street
> > London EC4M 5SQ
> > United Kingdom
> > Registered No: 3122085, England
> > 
> > Phone:          +44 171 557 5000
> > Fax:            +44 171 557 5200
> > Email:          [email-masked]
> > WebSite:        http://www.mondexinternational.com
> > 
> >
> **************************************************************************
> > *******************
> > 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: "Seidl, Roland A" <[email-masked]>
Cc: Ietf Trade WG <[email-masked]>
Subject: RE: Cancelling Transactions and IOTP  figs 10 and 11
Date: Thu, 20 May 1999 22:45:12 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BEA30A.0A6A6D60
Content-Type: text/plain;
	charset="iso-8859-1"

Roland

See comments below ... I agree with everything you say aboout figures 10 and
11. I've made the changes to diagram that you suggest.

However this discussion about Idempotency, Processing Sequence and Message
Flow, has made me realise that it doesn't cover the situation when a
transaction is cancelled by one or other of the Trading Roles. The ability
to cancel a transaction was added after this part of the specification was
written and the section on Idempotency, etc. didn't get updated.

I've also noticed that Section 7.18 that describes the Cancel block is not
quite correct since it says that only the Consumer can cancel a transaction
whereas in fact any Trading Role can cancel a transaction at any time. The
updates required to handle this and revised versions of figures 10 and 11
are below

David

SPEC CHANGES ...

Section 7.18 now reads
"The Cancel Block is used by one Trading Role to inform any other that a
transaction has been cancelled. Example usage includes:
		*	a Consumer Role informing a non-Consumer role that
it no longer plans to continue with the transaction. This will allow the
server to close down the transaction tidily without a waiting for a time-out
to occur
		*	a non-Consumer Role to inform a Consumer role that
the Transaction is being stopped. In this case, the Consumer is then
unlikely to re-send the previous message that was sent in the mistaken
understanding that the original was not received."

New section 4.4.1.6 Cancel Blocks (for server role) reads:
"If the Consumer role has sent a Cancel Block then the Consumer does not
intend to carry on with the Transaction and the Server should stop any
processing and not issue any further response blocks."

New section 4.4.2.6 Cancel Blocks (for consumer role) reads:
"If the Server role has sent a Cancel Block then the Server role does not
intend to carry on with the Transaction for the reasons indicated in the
Status Component in the Block. The Consumer should stop all processing of
the transaction and not issue any further blocks or messages."

Revised Figures 10 and 11.

 <<fig10v3.txt>>  <<fig11v3.txt>> 

> ----------
> From: 	Seidl, Roland A[SMTP:[email-masked]]
> Sent: 	20 May 1999 00:53
> To: 	David Burdett
> Subject: 	RE: IOTP  figs 10 and 11 redrafted plus some more Draft
> comments
> 
> David
>             The comments below don't change figure 10 from what I sent you
> yesterday.
> The only discomfort I feel is in leaving block 6d dangling so to speak.
> Perhaps
> there should be a pointer back to block 2, i.e
> 
>           6d. Do nothing!
>          Earlier request
>            will provide
>                      |
>                     v
>                   (2)
## Agreed ##

> If I understand you correctly, if an action request is received, which was
> previously
> received AND if the previous version of the request has been processed
> then
> send the previous response [sequence 6a->6b->6c->10].
## Correct ##

> Now if a duplicate of the action request is received while the first copy
> is still
> being processed, then it is ignored [The processing of the first copy will
> provide
> the response].  In this case (since it appears that block processing is
> carried
> out asynchronously, otherwise there wouldn't need to be a question
> regarding
> the completion or otherwise of processing a block) I would argue
> whateverfunction
> is scheduling the block processing would go and get the next block if one
> is
> available (i.e. go back to (2))
## Spot on ##

Roland thanks for your help. I've added the pointer back to step 2 in the
last version of step 2 that you sent me.

> Regards
> Roland
> 
> 
>  ----------
> >From: David Burdett
> >Subject:  RE: IOTP  figs 10 and 11 redrafted plus some more Draft
> comments
> >Date: 1999-05-20 11:26
> >
> >Roland
> >
> >See comments below.
> >
> >I've also looked at the diagrams you sent in your other email and they
> seem
> >much better. Do you want to revise them one more time in light of the
> >comments below, and then I'll include them in the spec.
> >
> >Thanks
> >
> >David
> >
> >> Is there anything that you see wrong with the way I point to/from one
> part
> >> of the diagram to the other? Would you like a different way of
> indicating
> >> this rather than
> >>
> >>    |      ?    Perhaps     |_
> >>    v                          | 9 |
> >>   (9)                          \/
> >## I prefer the approach on the left which is the one you currently are
> >using.##
> >
> >> Incidentally there is another error in the DTD.
> >> <!ATTLIST Parameter
> >>     type      PCDATA #REQUIRED>
> >>
> >> should be    "type CDATA"
> >## This part of the DTD was copied from the IOTP-DSIG DTD and is in a
> >separate spec. I guess this should be fixed in the next version of that
> >spec, then I will replace the complete section##
> >
> >> Also there was an error in the updated figure 11 you sent me. There
> >> shouldn't have
> >> been a link from the "4. Type of Block?" to the "Errors" stream.
> >##Agreed##
> >
> >> I still have a problem with figure 10!
> >> I thing the following needs to be determined to satisfy my misgivings
> >> about
> >> the "completeness" of the logic.
> >>
> >> Firstly - Under what circumstances will an "action request" be received
> >> which has been previously received?
> >##The internet can sometimes, without any intervention by anybody, result
> in
> >the same message being received twice. I think its something to do with
> the
> >Internet Protocol, if it can't (or more precisely thinks it can't) get a
> >message through to its destination by its preferred route, then it sends
> it
> >via another. In this case the *identical* message can sometimes get to
> the
> >destination two, or even more times.##
> >
> >> Secondly - There are two options as far as I see it.
> >>                       a) Do nothing, that is discard the previously
> >> received
> >> request and continue processing the next block
> >>                       b) Resend the previous response block
> >>               Under what circumstances is option a correct and in which
> is
> >> option b?
> >> ## I don't think that option (a) is *ever* correct. If you're
> processing
> a
> >> block and the identical one is received again, then:
> >*	if you haven't finished processing the original block, then you
> >should carry on processing (why stop and start again?) it which
> eventually
> >result in a response block being generated.
> >*	on the other hand, if you have finished processing the original
> >block and an identical one is received again, then the original block
> might
> >have been sent again because the response block was never received. In
> this
> >case you want to send the response again.
> >
> >Does this make sense?##
> >
> >> I guess that the answers to the first question will provide a
> resolution
> >> to
> >> the second.
> >>
> >> As far as I am concerned, if there are situations where each of the
> above
> >> options
> >> might apply, then we might need some check as to whether "Do Nothing"
> is
> >> the
> >> correct option?
> >>
> >>                 6b. Processing of Block Complete
> >>                                                |
> >>                                                |  NO
> >>                           Resend Previous Response?
> >>                             |
> >	                                                        |
> >>                             |   Yes
> |
> >> Ignore, get next block
> >>                            v
> >> v
> >>                          (6c)
> (2)
> >>
> >> Any comments?
> >## See earlier comments. However really the disagram should specify the
> >conditions which allow you to decide whether to ignore or resend if
> >duplicate block is received.##
> >
> 
> 
> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> 
> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
------_=_NextPart_000_01BEA30A.0A6A6D60
Content-Type: text/plain;
	name="fig10v3.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="fig10v3.txt"

                             --------------
                            |     Input    |
                            | IOTP Message |
                             --------------
                                   |
                                   v
                         1. Check for transport         Errors
                         or message level errors  ------------------
                                   |                                |
                                   | OK                             |
                                   v                                |
 --------------------------------->|                                |
|                                  |                                |
|                  NO              v                                |
|           ----------  2. More Blocks to process?                  |
|          |                       |                                |
|          v                       | YES                            |
|   ---------------                v                     Errors     v
|  |    Output     |       3. Check Block OK  --------------------->|
|  | IOTP Messasge |               |                                |
|   ---------------                | Checks OK                      |
|                                  v                                |
|                          4. Type of Block?                        |
|                                  |                                |
|                                  v                                |
|            ------------------------------------------------       |
|           |               |                |               |      |
|         Status         Action        Encapsulating    Error or    |
|         Block          Request           Block      Cancel Block  |
|           |               |                |               |      |
|           v               |                |               v      |
|  5. Generate Status       |                |             STOP     |
|     Response Block        |                v                      |
|           |               |      7. Process encapsulated          v
|           |               |        message and generate  -------->|
|           v               |         response message      Errors  |
|         (10)              |                |                      |
|                           |                | OK                   |
|                           |                v                      |
|                           |              (10)                     |
|                           v                                       |
|                     6a. Action Request                            |
|                 ---  Received Before?  ------                     |
|                |                             |                    |
|                | NO                      YES |                    |
|                v                             v                    |
|         6b. Processing of           6e. Process Action    Errors  v
|      ---  Block Complete? ---      Request and generate --------->|
|     |                        |         response block             |
|     | Yes                 No |               |                    v
|     v                        v               |            9. Generate
| 6c. Retrieve and      6d. Do nothing!        |            Error Block
|  resend previous      Earlier request        |             and store
|   Block                will provide          |                    |
|     |                    response            v                    |
|     |                        |        6f. Store Request           |
|     |                        |          and Response              |
|     |                        v              Block                 |
|     |                       (2)              |                    |
|     |                                        v                    v
|      ---------------------------->-<--------<---------------------
|                                   |
|                                   v
|                           10. Add block to
 --------------------------  output message  <----------------(10)

------_=_NextPart_000_01BEA30A.0A6A6D60
Content-Type: text/plain;
	name="fig11v3.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="fig11v3.txt"

                                  --------------
                                 |     Input    |
                                 | IOTP Message |
                                  --------------
                                        |
                                        v
                               1. Check for transport        Errors
                               or message level errors  ------------->
                                        |                             |
  ------------------------------------->| OK                          |
 ^                                      v                             |
 |            -------------  2. More Blocks to process?               |
 |           |     NO                   |                             |
 |           |                          | Yes                         |
 |           v                          |                             |
 |    11. Blocks to ---                 v            Errors           v
 |         send?       |     3. Check Block OK  --------------------->|
 |           |      No |                |                             |
 |       Yes |         v                | Checks OK                   |
 |           v       STOP               |                             |
 |    12. Generate                      |                             |
 |   output message                     v                             |
 |           |                  4. Type of Block?                     |
 |           v                          |                             |
 |     --------------                   |                             |
 |    |    Output    |                  |                             |
 |    | IOTP Message |                  |                             |
 |     --------------                   |                             |
 |                                      v                             |
 |        ----------------------------------------------------        |
 |       |         |            |              |              |       |
 |       v         v            v              v              v       |
 |    Status     Cancel      Action      Encapsulating      Error     |
 |    Request    Block      Response         Block          Block     |
 |       |         |            |              |              |       |
 |       v         v            |              v              v       |
 |     (10)      STOP           |         7. Process         (8)      |
 |                              |        Encapsulated                 v
 |                              v           message   --------------->|
 |<----------------6a. Action Response         |         Errors       |
 ^  Yes, Ignore     Received Before?           | OK                   |
 |                    |                        v                      |
 |                    | NO                   (6c)                     |
 |                    |                                               |
 |                    |                -------------------------------
 |                    |               |               =20
 |                    |               v               =20
 |                    v          9. Generate          =20
 |       6b. Process Action --->Error Block          (8)
 |         Response Block        and Store            |
 |              |                     |               v
 |              | OK         (6c)     |        8a. Error Block -------
 |              v              |      |           Severity            |
 |<------6c. New Request <-----       |               |          Hard |
 ^   NO      Required                 |               |         Error |
 |              |                     |               v               v
 |              | Yes                 |           Transient         =
STOP
 |              v                     |         Error (retry)
 |     6d. Generate Request           |               |
 |       Block and Store              |             WAIT
 |              |                     |               |
 |              |                     |               v
 |              v                     |       8b. Retrieve and
 |       10. Add Block to             v        Resend previous
 |        Output message  <------------<------     Block(s)
 |              |
 |              v
  <-------------

------_=_NextPart_000_01BEA30A.0A6A6D60--
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: [email-masked]
Date: Thu, 20 May 1999 15:33:22 -0400
Subject: Re: FW: iotp doc format
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--0__=XlM6qehO2AXGy080oLco8BYshQXNUNCaKHyvwHHRC0ENxDk2Ib0xBef6
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Either iotpfmt3.txt or iotpfmt2.txt look like reasonable choices.

Thanks,
Donald

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
[email-masked]   tel: 1-914-276-2668

David Burdett <[email-masked]> on 05/18/99 08:37:58 PM

To:   Ietf Trade WG <[email-masked]>
cc:    (bcc: Donald Eastlake/Hawthorne/IBM)
Subject:  FW: iotp doc format

Chris Smith asked me to forward this to the Trade WG as he's having
difficulty in sending attachments. Essentially, its a set of suggested
alternative ways of doing message flow diagrams using Text.

As these are easier to do (and I think clearer) than the style I had
proposed I plan to adopt the style given by Chris in the file titled
'iotpfnt2.txt"

David

> ----------
> From:   Smith, Chris[SMTP:[email-masked]]
> Sent:   17 May 1999 16:13
> To:     [email-masked]
> Subject:     iotp doc format
>
>  <<iotpfmt3.txt>>  <<iotpfmt3.doc>>  <<iotpfmt3.ans>>  <<iotpfmt1.txt>>
> <<iotpfmt2.txt>>
>
> here are the attachments dav
*********************************************************************************************

--0__=XlM6qehO2AXGy080oLco8BYshQXNUNCaKHyvwHHRC0ENxDk2Ib0xBef6
Content-type: application/octet-stream; 
	name="iotpfmt3.txt"
Content-Disposition: attachment; filename="iotpfmt3.txt"
Content-transfer-encoding: base64
Content-Description: Text - character set unknown

--0__=XlM6qehO2AXGy080oLco8BYshQXNUNCaKHyvwHHRC0ENxDk2Ib0xBef6
Content-type: application/X-Lotus-Manuscript1; 
	name="iotpfmt3.doc"
Content-Disposition: attachment; filename="iotpfmt3.doc"
Content-transfer-encoding: base64
Content-Description: Lotus Manuscript 1.0

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJAAAAAAAAAAA
EAAAJgAAAAEAAAD+////AAAAACMAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

--0__=XlM6qehO2AXGy080oLco8BYshQXNUNCaKHyvwHHRC0ENxDk2Ib0xBef6
Content-type: application/octet-stream; 
	name="iotpfmt3.ans"
Content-Disposition: attachment; filename="iotpfmt3.ans"
Content-transfer-encoding: base64

--0__=XlM6qehO2AXGy080oLco8BYshQXNUNCaKHyvwHHRC0ENxDk2Ib0xBef6
Content-type: application/octet-stream; 
	name="iotpfmt1.txt"
Content-Disposition: attachment; filename="iotpfmt1.txt"
Content-transfer-encoding: base64
Content-Description: Text - character set unknown

--0__=XlM6qehO2AXGy080oLco8BYshQXNUNCaKHyvwHHRC0ENxDk2Ib0xBef6
Content-type: application/octet-stream; 
	name="iotpfmt2.txt"
Content-Disposition: attachment; filename="iotpfmt2.txt"
Content-transfer-encoding: base64
Content-Description: Text - character set unknown

--0__=XlM6qehO2AXGy080oLco8BYshQXNUNCaKHyvwHHRC0ENxDk2Ib0xBef6--

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: [email-masked]
Date: Thu, 20 May 1999 15:44:21 -0400
Subject: RE: Using XML as well as HTML
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

While it is true that XSL and how to link it to an XML document isn't finalized
yet, I'm not sure how much we should worry about that.  It seems very likely
there will be some way to link style sheets out of an XML document so as long as
the full documents in the XML syntax sense are included.  I don't think it is a
good idea to just say "at the discretion of the implementer".  How about just
saying "implementers should follow the latest recommendations of the W3C"?

Thanks,
Donald

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
[email-masked]   tel: 1-914-276-2668

David Burdett <[email-masked]> on 05/17/99 09:17:01 PM

To:   Ietf Trade WG <[email-masked]>, Don Eastlake
      <[email-masked]>
cc:    (bcc: Donald Eastlake/Hawthorne/IBM)
Subject:  RE: Using XML as well as HTML

The problem is that the XML style sheet (XSL) specifications are not
finalised. Specifically:
*    "Associating stylesheets with XML documents" at
http://www.w3.org/TR/xml-stylesheet is a proposed recommendation and
requires comments to be submitted by 26 May, and
*    "Extensible Stylesheet Language (XSL) Specification" at
http://www.w3.org/TR/WD-xsl is just a working draft.

The first document also states  " ... the technology explained in this
Proposed Recommendation is not the only one for its task. There are others
available or under development that allow the link to be outside the XML
document ..." which means that further changes can be anticipated.

Therefore I suggest that the a "XML Packaging" section is added to the IOTP
specification after the existing section on "HTML packaging" that says ...

"Support for XML is recommended. When XML needs to be displayed, for example
to display the content of an Order Description to a Consumer, then the
method employed is at the discretion of the implementer.

     [Note]    At the time of writing this specification, standards are
under development that specify XML style sheets that show how XML documents
should be displayed. See:
                    *    "Extensible Stylesheet Language
(XSL) Specification" at http://www.w3.org/TR/WD-xsl, and
                    *    "Associating stylesheets with XML
documents" at http://www.w3.org/TR/xml-stylesheet.
                    Once these standards become W3C
"Recommendations", then it is anticipated that this specification will be
amended if practical.
     [Note End]      "

... and change references to "plain text and HTML" to additionally refer to
XML  for instance ...

"For interoperability, implementations must support Plain Text, HTML and XML
as a minimum so that it can be easily displayed."

This applies to the sections on: "Order Description Content", "Payment Note"
and "Delivery Note"

Any comments?

David
> ----------
> From:   Donald E. Eastlake 3rd[SMTP:[email-masked]]
> Sent:   10 May 1999 19:56
> To:     Ietf Trade WG
> Subject:     Re: Using XML as well as HTML
>
> It seems to me that the solution for this involves, among other things,
> the Offer Request message we have defered until after v1.0...
>
> I suggest we go for simplicity in v1.0 and just say that support of
> XML is recommended even though your point about XML support at some
> level being implied since IOTP uses XML syntax...
>
> Thanks,
> Donald
>
> From:  David Burdett <[email-masked]>
> Message-Id:  <[email-masked]>
> Date:  Fri, 30 Apr 1999 20:04:09 +0100
>
> >I agree that XML should be recommended, the problem is how do you
> discover
> >if the consumer has XML/XSL support in their IOTP implementation?
> >
> >If a merchant or one of the other trading roles is unsure, then they'll
> >never send order descrciptions, etc, in XML to the consumer. On the other
> >hand if a particular IOTP consumer client software becomes highly popular
> >that supports XML/XSL, then it is reasonable safe for merchants to use
> XML
> >and more might do so.
> >
> >Finally, you could argue that since to do IOTP at all, there must be XML
> >support then at least half the solution *must* be there. In this case,
> you
> >could recommend displaying a message to the user of the problem and
> >displaying XML in a very simple way.
> >
> >David
> >
> >
> >> ----------
> >> From:     Donald E. Eastlake 3rd[SMTP:[email-masked]]
> >> Sent:     29 April 1999 10:04
> >> To:  Ietf Trade WG
> >> Subject:  Re: Using XML as well as HTML
> >>
> >> I believe that support for XML should be recommended but not required.
> >>
> >> Thanks,
> >> Donald
> >>
> >> From:  David Burdett <[email-masked]>
> >> Message-Id:
> <[email-masked]>
> >> To:  Ietf Trade WG <[email-masked]>
> >> Date:  Thu, 29 Apr 1999 17:17:05 +0100
> >>
> >> >Following on from my other email on using HTML, the spec doesn't
> >> currently
> >> >describe how XML could be used. I think that it should. We could
> provide
> >> >similar guidelines for XML/XSL to the ones for HTML.
> >> >
> >> >Who thinks this is a good idea?
> >> >
> >> >David
> >> >
> >> >THIS EMAIL IS FOR UNRESTRICTED DISTRIBUTION
> >> >> mailto:<[email-masked]>
> >> >> Mondex International, US Advanced Technology Office
> >> >> 111 Pine St, 6th Floor, San Francisco, CA 94111
> >> >> Tel/Voicemail: +1 415 645 6973   Fax: +1 415 956 9370
> >> -----------------------------------------------------------------------

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Subject: RE: Brand IDs & their registration. Was: RE: Comments on draft-ie		 tf-t rade-iotp-v1.0-protocol-03.txt, part 1
Date: Thu, 20 May 1999 13:37:46 +0100
From: Dave Birch <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Lewis, Tony said

>Actually, VisaCash is its own brand. As far as I know, CEPS is not branded
>(at least from a Visa perspective).

My (distant and possibly imperfect) understanding of CEPS is that Europay 
issuers will brand as "Clip" and Visa issuers will brand as "VisaCash".

Regards,
Dave Birch.

...  My own opinion (I think!) given solely in my capacity as  ...
...         an interested member of the general public         ...
...                                                            ...
...  mailto:[email-masked]   .........  http://pobox.com/~dgwb ...

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: Andrew Drapp <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RE: LITIGATION WITH A SALE
Date: Thu, 20 May 1999 11:24:50 +0900
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Welcome Serge Piasek;

Actually, the problem you present is not directly 
related to the functionality of IOTP.

IOTP does provide for a refund type transaction.
The amount of the refund will be based upon the
policies of the Merchant.  I have seen shops that
not only will not refund the price of shipping,
but will also keep 15% of the price of the item
as a "restocking" fee.  On the other hand, the
Merchant may be willing to refund the cost of
shipping as well.

IOTP does not include the ability to negotiate 
how much will be refunded.  In a transaction type
involved, IOTP can be used in the following ways:

1.  Prove that a payment was made, and the amount 
that was paid.
2.  If an itemized invoice was included, establish
the amount that was for the item, and the amount
that was for shipping.
3.  Prove that the bike does not match the original
description.
4.  Provide a method to receive a refund.
5.  Provide proof that a refund was paid.

IOTP cannot be used for the following:
1.  Negotiate the price to be paid for the bike 
originally.
2.  Negotiate the amount to be refunded.
3.  Guarantee that a refund will even be provided or
available.

IOTP cannot prevent fraud or guarantee that you will
get your money back.  IOTP only provides evidence of
your claims should you decide to dispute a transaction.

I hope this information helps.  If you have any more
questions, feel free to ask.

Andrew Drapp

--
Andrew Drapp
[email-masked]
Systems Development Laboratory, Hitachi Ltd.
Ozenji 1099, Asao, Kawasaki, 215-0013 JAPAN
TEL:+81-44-966-9111   FAX:+81-44-966-1796
PGP Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F

-----Original Message-----
From:	Serge Piasek [SMTP:[email-masked]]
Sent:	Wednesday, May 19, 1999 5:47 PM
To:	[email-masked]
Subject:	LITIGATION WITH A SALE

Hello,

I'm new here, please forgive me with my bad english (je suis fran軋is).

Here is the problem,

Imagine that someone buy a bike using IOTP protocol.

He pay through IOTP the delivery of the goods + the bike.

He receive the bike, don't agree with what he saw on the web site and
decide to send back the bike to the merchand.

He request his money back.

How the merchand will send him back the money (the merchand must include
the bike price + delivery price) as he got only the money for the bike,
the delivery was paid directly to UPS (for example).

How will he get back all the money.

Did you allready work on this aspect to send back money when there is 2
simultanous payment made by the customer to the Payment Handler at the
time of the sale ???

Thank you for answering??

A +

--
_____________________________________________________

L'integrite de ce message n'etant pas assuree sur Internet,
COMMUNICATION
INTERACTIVE ne peut etre tenue responsable de son contenu.
Si vous n'etes pas destinataire de ce message, merci de le detruire et
d'avertir l'expediteur.

-------------------------------------------------------------------------------

---
The integrity of this message cannot be guaranteed on the Internet.
COMMUNICATION INTERACTIVE can not therefore be considered responsible
for the contents.
If you are not the intended recipient of this message, then please
delete
it and notify the sender.
________________________________________________________________________________

_____________________________________________________

 << File: serge.piasek.vcf >> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Lewis, Tony" <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: Brand IDs & their registration. Was: RE: Comments on draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
Date: Wed, 19 May 1999 13:27:26 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Actually, VisaCash is its own brand. As far as I know, CEPS is not branded
(at least from a Visa perspective).

Tony
> ----------
> From: 	Dave Birch[SMTP:[email-masked]]
> Sent: 	Wednesday, May 19, 1999 12:42 PM
> To: 	Ietf Trade WG
> Subject: 	RE: Brand IDs & their registration. Was: RE: Comments on
> draft-ie	 tf-t rade-iotp-v1.0-protocol-03.txt, part 1
> 
> Lewis, Tony said
> 
> >By the way, Visa does not imply "credit". It can be credit or debit.
> 
> Or cash (e.g. VisaCash, CEPS etc).
> 
> Regards,
> Dave Birch.
> 
> ...  My own opinion (I think!) given solely in my capacity as  ...
> ...         an interested member of the general public         ...
> ...                                                            ...
> ...  mailto:[email-masked]   .........  http://pobox.com/‾dgwb ...
> 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Subject: RE: Brand IDs & their registration. Was: RE: Comments on draft-ie	 tf-t rade-iotp-v1.0-protocol-03.txt, part 1
Date: Wed, 19 May 1999 20:42:31 +0100
From: Dave Birch <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Lewis, Tony said

>By the way, Visa does not imply "credit". It can be credit or debit.

Or cash (e.g. VisaCash, CEPS etc).

Regards,
Dave Birch.

...  My own opinion (I think!) given solely in my capacity as  ...
...         an interested member of the general public         ...
...                                                            ...
...  mailto:[email-masked]   .........  http://pobox.com/‾dgwb ...

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Date: Wed, 19 May 1999 08:46:51 +0000
From: Serge Piasek <[email-masked]>
Organization: COMMUNICATION INTERACTIVE
To: [email-masked]
Subject: LITIGATION WITH A SALE
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Il s'agit d'un message multivolet au format MIME.
--------------3B554D08AFE12600E8A914B3
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by wanadoo.fr id IAA04400

Hello,

I'm new here, please forgive me with my bad english (je suis fran=E7ais).

Here is the problem,

Imagine that someone buy a bike using IOTP protocol.

He pay through IOTP the delivery of the goods + the bike.

He receive the bike, don't agree with what he saw on the web site and
decide to send back the bike to the merchand.

He request his money back.

How the merchand will send him back the money (the merchand must include
the bike price + delivery price) as he got only the money for the bike,
the delivery was paid directly to UPS (for example).

How will he get back all the money.

Did you allready work on this aspect to send back money when there is 2
simultanous payment made by the customer to the Payment Handler at the
time of the sale ???

Thank you for answering??

A +

--
_____________________________________________________

L'integrite de ce message n'etant pas assuree sur Internet,
COMMUNICATION
INTERACTIVE ne peut etre tenue responsable de son contenu.
Si vous n'etes pas destinataire de ce message, merci de le detruire et
d'avertir l'expediteur.

-------------------------------------------------------------------------=
------

---
The integrity of this message cannot be guaranteed on the Internet.
COMMUNICATION INTERACTIVE can not therefore be considered responsible
for the contents.
If you are not the intended recipient of this message, then please
delete
it and notify the sender.
_________________________________________________________________________=
_______

_____________________________________________________

--------------3B554D08AFE12600E8A914B3
Content-Type: text/x-vcard; charset=us-ascii;
 name="serge.piasek.vcf"
Content-Description: Carte pour Serge Piasek
Content-Disposition: attachment;
 filename="serge.piasek.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Piasek;Serge
tel;cell:+33662049522
tel;fax:+33142884273
tel;work:+33144619922
x-mozilla-html:TRUE
url:http://www.checkflow.com
org:COMMUNICATION INTERACTIVE
adr:;;25 Rue du Temple;Paris;;75004;France
version:2.1
email;internet:[email-masked]
title:Direction Generale
fn:Serge Piasek
end:vcard

--------------3B554D08AFE12600E8A914B3--

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: FW: iotp doc format
Date: Wed, 19 May 1999 01:37:58 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BEA18F.D8C5F5C0
Content-Type: text/plain

Chris Smith asked me to forward this to the Trade WG as he's having
difficulty in sending attachments. Essentially, its a set of suggested
alternative ways of doing message flow diagrams using Text.

As these are easier to do (and I think clearer) than the style I had
proposed I plan to adopt the style given by Chris in the file titled
'iotpfnt2.txt"

David

> ----------
> From: 	Smith, Chris[SMTP:[email-masked]]
> Sent: 	17 May 1999 16:13
> To: 	[email-masked]
> Subject: 	iotp doc format
> 
>  <<iotpfmt3.txt>>  <<iotpfmt3.doc>>  <<iotpfmt3.ans>>  <<iotpfmt1.txt>>  
> <<iotpfmt2.txt>> 
> 
> here are the attachments dave 
> 
>   
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
------_=_NextPart_000_01BEA18F.D8C5F5C0
Content-Type: text/plain;
	name="iotpfmt3.txt"
Content-Disposition: attachment;
	filename="iotpfmt3.txt"

------------------------------- Message Contents -------------------------------
    Consumer    PayHandler      
      |  Merchant |
      |     |     |
      
  1.  C --> M         Consumer decides to trade and sends information about
                      the transaction (requests an offer) to the Merchant,
                      e.g. using HTML

  2.  C <-- M         Merchant decides which payment brand and currencies and
                      amounts to offer, places them in a Brand List Component
                      and sends them to the Consumer

  3.  C --> M         Consumer selects the payment brand, protocol and currency
                      amount, creates a Brand Selection Component and send it
                      to the Merchant

  4.  C <-- M         Merchant checks Brand Selection, specifies Merchant and
                      Payment Handler Org components, creates Payment Amount
                      information, optionally signs it to authorise payment and
                      sends it to the Consumer

  5.  C --------> P   Consumer checks the Payment Amount information and if OK
                      requests that the payment starts by sending a Payment
                      Request with Brand List, Brand Selection, Pay Scheme,
                      Pay Amount, and Organizations to the Payment Handler

------_=_NextPart_000_01BEA18F.D8C5F5C0
Content-Type: application/msword;
	name="iotpfmt3.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="iotpfmt3.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJAAAAAAAAAAA
EAAAJgAAAAEAAAD+////AAAAACMAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

------_=_NextPart_000_01BEA18F.D8C5F5C0
Content-Type: application/octet-stream;
	name="iotpfmt3.ans"
Content-Disposition: attachment;
	filename="iotpfmt3.ans"

------------------------------- Message Contents -------------------------------
    Consumer    PayHandler
      |  Merchant |
      |     |     |

  1.  C --> M          Consumer decides to trade and sends information about
                       the transaction (requests an offer) to the Merchant,
                       e.g. using HTML

  2.  C <-- M          Merchant decides which payment brand and currencies and
                       amounts to offer, places them in a Brand List Component
                       and sends them to the Consumer

  3.  C --> M          Consumer selects the payment brand, protocol and
                       currency amount, creates a Brand Selection Component and
                       send it to the Merchant

  4.  C <-- M          Merchant checks Brand Selection, specifies Merchant and
                       Payment Handler Org components, creates Payment Amount
                       information, optionally signs it to authorise payment
                       and sends it to the Consumer

  5.  C --------> P    Consumer checks the Payment Amount information and if OK
                       requests that the payment starts by sending a Payment
                       Request with Brand List, Brand Selection, Pay Scheme,
                       Pay Amount, and Organizations to the Payment Handler

------_=_NextPart_000_01BEA18F.D8C5F5C0
Content-Type: text/plain;
	name="iotpfmt1.txt"
Content-Disposition: attachment;
	filename="iotpfmt1.txt"

------------------------------- Message Contents -------------------------------

 CONSUMER               <<< IOTP MESSAGE >>>                    MERCHANT
  1. Consumer decides to trade and sends information about the
     transaction (requests an offer) to the Merchant, e.g. 
     using HTML

        >>>Information on what is being paid for (outside scope of IOTP)>>>

                           2. Merchant decides which payment brand and
                              currencies/amounts to offer, places them in a Brand
                              List Component and sends them to the Consumer

                           <<<< Brand List Component <<<<

  3. Consumer selects the payment brand, protocol and
     currency/amount, creates a Brand Selection Component and 
     send it to the Merchant

                        >>>> Brand Selection Component >>>>

                           4. Merchant checks Brand Selection, creates Payment
                              Amount information, optionally signs it to 
                              authorise payment and sends it to the Consumer

               <<< Pay Amount; Organisations: Merchant  <<< 
               <<< & Payment Handler; Signature (Offer) <<<

  5 Consumer checks the Payment Amount information and if OK
     reuqests that the payment starts by sending a Payment 
     Request to the Payment Handler

       >>>      Brand List; Brand Selection; Pay Amount; Pay Scheme; >>>
       >>> Organisations: Merchant and Payment Handler; Signature (Offer) >>>

------_=_NextPart_000_01BEA18F.D8C5F5C0
Content-Type: text/plain;
	name="iotpfmt2.txt"
Content-Disposition: attachment;
	filename="iotpfmt2.txt"

------------------------------- Message Contents -------------------------------
    Consumer    PayHandler      
      |  Merchant |
      |     |     |
      
  1.  C --> M         Consumer decides to trade and sends information about
                      the transaction (requests an offer) to the Merchant,
                      e.g. using HTML

                   >> Information on what is being paid for (outside scope of IOTP)

  2.  C <-- M         Merchant decides which payment brand and currencies and
                      amounts to offer, places them in a Brand List Component
                      and sends them to the Consumer

                   << Brand List Component

  3.  C --> M         Consumer selects the payment brand, protocol and currency
                      amount, creates a Brand Selection Component and send it
                      to the Merchant

                   >> Brand Selection Component

  4.  C <-- M         Merchant checks Brand Selection, creates Payment Amount
                      information, optionally sings it to authorise payment and
                      sends it to the Consumer

                   << Pay Amount; Organisations: Merchant & Payment Handler;
                      Signature (Offer)

  5.  C --------> P   Consumer checks the Payment Amount information and if OK
                      requests that the payment starts by sending a Payment
                      Request to the Payment Handler

                   >> Brand List; Brand Selection; Pay Amount; Pay Scheme;
                      Organisations: Merchant and Payment Handler; Signature

------_=_NextPart_000_01BEA18F.D8C5F5C0--
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>,  Don Eastlake <[email-masked]>
Subject: RE: Otp -> Iotp ?? 
Date: Wed, 19 May 1999 01:38:00 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

There's also a need to change the valid value for the Relationship attribute
of the Related To element within a Transaction Reference block from
"OtpTransaction" to "IotpTransactio".

David

> ----------
> From: 	Donald E. Eastlake 3rd[SMTP:[email-masked]]
> Sent: 	18 May 1999 06:02
> To: 	Ietf Trade WG
> Subject: 	Re: Otp -> Iotp ?? 
> 
> I think we should go ahead and do the otp -> iotp change.
> 
> Thanks,
> Donald
> 
> From:  David Burdett <[email-masked]>
> Message-Id:  <[email-masked]>
> To:  Ietf Trade WG <[email-masked]>
> Date:  Tue, 18 May 1999 02:17:10 +0100
> 
> >There are still some element or attribute names in the DTD that contain
> >"Otp" rather than "Iotp". Do we want to change them? My view is yes,
> >although if anyone strongly objects I'm open to persuasion.
> >
> >Names to which this applies are:
> >*	OtpMessage, 
> >*	OtpTransId, 
> >*	OtpTransType, 
> >*	RespOtpMsg, 
> >*	OtpMsgIdPrefix, 
> >*	OtpMsgRef, 
> >*	LastReceivedOtpMsgRef, 
> >*	LastSentOtpMsgRef
> >
> >The first is an element. The rest are attributes.
> >
> >Thoughts?
> >
> >David
> >> mailto:<[email-masked]>
> >> Mondex International, US Advanced Technology Office
> >> 111 Pine St, 6th Floor, San Francisco, CA 94111
> >> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Lewis, Tony" <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: Brand IDs & their registration. Was: RE: Comments on draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
Date: Tue, 18 May 1999 09:39:18 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This chain has taken so many turns, I'm not convinced that I know what
problem we're trying to solve anymore.

I think the problem is: How do we identify the brand that will be used in a
transaction regardless of payment protocol?

For SET, this is "brand[:product]". For EMV, this is RID+PIX. Other
protocols will have their own internal method of encoding the brand. In all
cases, the user will want to see a graphical representation of the Visa,
MasterCard, Maestro, Mondex, etc. logo.

Do we need a new registry for brands? If we create such a registry, how do
we correlate those registrations with other schemes that know about the same
brands? Are we going to have a big table somewhere that correlates IOTP
brand, SET brand, EMV brand, etc.?

By the way, Visa does not imply "credit". It can be credit or debit.

Tony
> ----------
> From: 	David Burdett[SMTP:[email-masked]]
> Sent: 	Monday, May 17, 1999 6:17 PM
> To: 	[email-masked]; Lewis, Tony
> Cc: 	Ietf Trade WG
> Subject: 	RE: Brand IDs & their registration. Was: RE: Comments on
> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
> 
> John/Tony
> 
> I don't think the RID+PIX is the way to go. Surely all we need is a
> clearly
> defined name declared in a public forum (e.g. the Trade WG or its
> successor). For example we could declare:
> *	MasterCard (implies credit)
> *	Maestro (MasterCard debit)
> *	Mondex (electronic cash)
> *	Visa (implies credit)
> *	VisaCash (electronic cash)
> 
> The "protocols" that can be used with each brand, e.g. SETv1.0, SCCD, etc.
> are then separately specified with their own individual "payment
> protocol/version no" identifiers. 
> 
> There is still the need to know which payment protocols can be used with
> each brand. However I don't think this an IOTP issue since:
> *	Merchant's will know when they create a Brand List which protocols
> are applicable for each Brand
> *	Consumer's will know when they add a new brand what type of payment
> instrument it is (e.g. Credit) and the consumer software can then decide
> which payment protocols apply.
> 
> Do you both agree?
> 
> David
> 
> > ----------
> > From:
> > [email-masked][SMTP:[email-masked]]
> > Sent: 	05 May 1999 23:01
> > To: 	Ietf Trade WG
> > Subject: 	RE: Brand IDs & their registration. Was: RE: Comments on
> > draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > 
> > 
> > 
> > My understanding is that a RID (Registered ID obtained from ISO) is
> > assigned
> > more to an organization or association.
> > 
> > It is not easy to distinguish between
> > a RID, a brand, and a consumer acceptance mark.
> > 
> > For MasterCard, the same RID is used for:
> >    - MasterCard International chip credit cards,
> >    - and Maestro International pin based debit cards - which uses a
> > different
> >    acceptance "mark" for what some consumers may consider a "brand".
> > 
> > For MasterCard's RID the hexadecimal characters 0xA000000004 have been
> > assigned
> > by ISO to MasterCard.  The RID does not differentiate between our
> > MasterCard and
> > Maestro marks,
> > but it is only the full RID + PIX (AID) that distinguishes what "brand"
> or
> > mark
> > is involved.
> > 
> > 
> > 
> > 
> > 
> > "Lewis, Tony" <[email-masked]> on 05/04/99 08:09:25 PM
> > 
> > To:   Ietf Trade WG <[email-masked]>
> > cc:    (bcc: John Wankmueller/NYC/MASTERCARD)
> > Subject:  RE: Brand IDs & their registration. Was: RE: Comments on
> > draft-ie tf-t
> >       rade-iotp-v1.0-protocol-03.txt, part 1
> > 
> > 
> > 
> > 
> > In fact, Europay, MasterCard, and Visa have established EMVCo. (EMVCo
> does
> > not currently have a web site so I can't point you there. I'm told the
> > site
> > won't be up until July.)
> > 
> > EMV does not have brands in the same way that SET or IOTP do. EMV deals
> > with
> > application identifiers or AIDs. An AID consists of two parts: a
> > Registered
> > ID (RID) obtained from ISO and a Proprietary Extension (PIX). The RID is
> > roughly analogous to a brand. For example, Visa has an RID with a value
> of
> > 0xA000000003. Visa then assigns PIX values for various applications,
> e.g.,
> > Credit/Debit, VisaCash, etc.
> > 
> > Typically, an RID will be obtained by a payment brand, but there is no
> > guarantee that there is a one to one correspondence between a brand and
> a
> > RID.
> > 
> > As we look at a way to integrate EMV cards with SET, we expect to add
> AIDs
> > to the SET Initiation message, which will ultimately be replaced by
> IOTP.
> > 
> > Tony
> > > ----------
> > > From:   Steve Fabes[SMTP:[email-masked]]
> > > Sent:   Tuesday, May 04, 1999 10:33 AM
> > > To:     [email-masked]; Ietf Trade WG
> > > Subject:     Re: Brand IDs & their registration. Was: RE: Comments on
> > > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > >
> > > Donald, I do not have much to add but when looking at the actions of
> > SETCo
> > > we should also anticipate that the EMV world will establish EMVCo and
> > its
> > > rules will need to be considered along side those of SETCo's. The
> > > membership
> > > of the two Co's will overlap but be different and to assume the same
> > brand
> > > and operating rules may be optimistic.
> > > -----Original Message-----
> > > From: [email-masked] <[email-masked]>
> > > To: Ietf Trade WG <[email-masked]>
> > > Date: Tuesday, May 04, 1999 09:33
> > > Subject: RE: Brand IDs & their registration. Was: RE: Comments on
> > > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > >
> > >
> > > >Regardless of EMV or whatever, it seems to me that we have a "brand"
> > > registry
> > > >problem to solve.  Credit/Debit cards are sort of odd creatures
> because
> > > they can
> > > >be used in payments via multiple different protocols.  Most stored
> > value
> > > cards
> > > >can be used via only a single protocol.
> > > >
> > > >SETco clearly operates a card brand regisgration operations, however
> > > limited and
> > > >even if it's only expressed in the brand level certificates that
> SETco
> > > allows to
> > > >be created under its root.  I think the hope was that the SET
> > > registration
> > > could
> > > >be used in IOTP for all credit/debit cards.  This would at least
> avoid
> > > the
> > > >problem where some brand was registered under different names at
> > > different
> > > >registries (where "different" could just be things like whether there
> > is
> > > really
> > > >a space between American and Express or whether the C is capitalized
> in
> > > >Mastercard or whether Visa is all caps, ...).  Is there a list of
> bands
> > > >officially supported by SETco and their official names?
> > > >
> > > >However, if SETco is inappropriate for this, because they won't
> > > "register"
> > > >brands that haven't joined", then we need a separate solution.  It
> > > certainly
> > > >isn't very difficult to set up regsitration via IANA, probably using
> > the
> > > same
> > > >Designated Expert criteria being used for other things.  The only
> > > difficulty I
> > > >can see is that some brand might get registered there for IOTP use
> and
> > > then
> > > >later join SETco or otherwise get registered in some other system
> under
> > > some
> > > >other name.  Various messyness with Discover/Novus, AT&T Universal
> Card
> > > changing
> > > >to CitiBank Universal Card and the like occur to me.  I'm not sure
> > those
> > > cases
> > > >are actually name change problems but one can image such.
> > > >
> > > >All this seems to imply that we need to be prepared to register
> > > credit/debit
> > > >card brands under "IOTP:".  I'm a bit reluctant to drop the "SET:"
> > branch
> > > of the
> > > >brand tree in IOTP.  If some brand exists under SETco but hasn't yet
> > been
> > > >registered under IOTP, it seems like it should be usable.  Of course,
> > > this
> > > means
> > > >that some brand registered under IOTP could later join SETco and
> could
> > > exist as
> > > >both IOTP:BrandX and SET:BrandX or SET:Brand-ex.  So you might get
> into
> > > >equivalence tables but these are really just an artifact of the real
> > > world
> > > being
> > > >messy and not particularly worse than brands splitting or merging.
> > > >
> > > >I don't see a major problem with us using
> > > brand:[product]:[promotional-name] if
> > > >we want, even after "SET:", although we should make it clear in that
> > case
> > > that
> > > >these values differ from those permitted in the SET protocol.  The
> > other
> > > >possibility that occurs to me would be to use brand[:product] and
> have
> > a
> > > >separate [promotional=xxx] optional attribute.
> > > >
> > > >What do people think?
> > > >
> > > >Thanks,
> > > >Donald
> > > >
> > > >Donald E. Eastlake, 3rd
> > > >17 Skyline Drive, Hawthorne, NY 10532 USA
> > > >[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
> > > >
> > > >home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
> > > >[email-masked]   tel: 1-914-276-2668
> > > >
> > > >
> > > >
> > > >David Burdett <[email-masked]> on 04/29/99 12:17:01 PM
> > > >
> > > >To:   Ietf Trade WG <[email-masked]>
> > > >cc:   "Lewis, Tony" <[email-masked]> (bcc: Donald
> > > Eastlake/Hawthorne/IBM)
> > > >Subject:  RE: Brand IDs & their registration. Was: RE: Comments on
> > > draft-ie
> > > >      tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >I agree with Tony. Smart card based EMV transactions will be the
> > dominant
> > > >payment model within a decade, probably even earlier especially in
> the
> > > >non-US part of the world. The main reasons being, in my view:
> > > >*    it will reduce fraud as it's much much harder to copy a smart
> card
> > > >than a mag stripe card
> > > >*    it makes internet credit card payments "card present"
> transactions
> > > >which should result in lower merchant fees. This also means that it
> > will
> > > be
> > > >much harder for customers to claim they never made an internet
> purchase
> > > >*    using a multi-application smart card you will be able to use
> just
> > > >one smart card for debit, credit, electronic cash, a loyalty scheme
> as
> > > well
> > > >as hold electronic tickets for anything from local cinema to your
> next
> > > >flight.
> > > >
> > > >To rephrase a MasterCard ad line, "smart cards are the future of
> > money".
> > > >
> > > >David
> > > >
> > > >> ----------
> > > >> From:   Lewis, Tony[SMTP:[email-masked]]
> > > >> Sent:   28 April 1999 20:30
> > > >> To:     Ietf Trade WG
> > > >> Subject:     RE: Brand IDs & their registration. Was: RE: Comments
> on
> > > >> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > >>
> > > >> My point is that the brand is "Visa" no matter whether using IOTP,
> > SET
> > > or
> > > >> any other protocol.
> > > >>
> > > >> As for EMV, the very first live SET 1.0 transaction was made using
> an
> > > EMV
> > > >> card with the EMV data carried inside a SET message extension. EMV
> > > credit
> > > >> and debit products are a significant part of the future of
> electronic
> > > >> commerce. I expect they will be the dominant model for payment in a
> > > >> decade.
> > > >>
> > > >> Tony
> > > >> > ----------
> > > >> > From:      Steve Fabes[SMTP:[email-masked]]
> > > >> > Sent:      Wednesday, April 28, 1999 3:43 PM
> > > >> > To:   Lewis, Tony; Ietf Trade WG
> > > >> > Subject:   Re: Brand IDs & their registration. Was: RE: Comments
> on
> > > >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > >> >
> > > >> > Tony - do your comments infer that SET.Visa will be the only
> > > e-Commerce
> > > >> > product that an IOTP product supplier can expect to see. Can you
> > see
> > > a
> > > >> day
> > > >> > when a Visa EMV 3.1.1 (or 3.x.x) based credit product could also
> be
> > > used
> > > >> > inside an IOTP product?
> > > >> > -----Original Message-----
> > > >> > From: Lewis, Tony <[email-masked]>
> > > >> > To: Ietf Trade WG <[email-masked]>
> > > >> > Date: Wednesday, April 28, 1999 13:21
> > > >> > Subject: RE: Brand IDs & their registration. Was: RE: Comments on
> > > >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > >> >
> > > >> >
> > > >> > >David,
> > > >> > >
> > > >> > >I am new to this group and do not know what lead to the current
> > > >> approach.
> > > >> > >There are undoubtedly some issues that I don't know about.
> > However,
> > > it
> > > >> > seems
> > > >> > >to me that a brand is a brand no matter what payment protocol is
> > > being
> > > >> > used.
> > > >> > >The only difference I see between "IOTP:Visa" and "SET:Visa" is
> > that
> > > >> the
> > > >> > >latter indicates that the brand is supported by a specific
> payment
> > > >> > protocol.
> > > >> > >Since you need to support brands other than those supported by
> > SET,
> > > >> there
> > > >> > >will need to be a registry. It seems to me that there should
> only
> > be
> > > >> one
> > > >> > >such registry rather than the two being proposed. I recommend
> > having
> > > a
> > > >> > >single domain for these brands. It seems reasonable to initially
> > > >> populate
> > > >> > it
> > > >> > >using the brands registered with SET and those non-SET brands
> you
> > > >> listed
> > > >> > in
> > > >> > >your note.
> > > >> > >
> > > >> > >Tony
> > > >> > >> ----------
> > > >> > >> From: David Burdett[SMTP:[email-masked]]
> > > >> > >> Sent: Wednesday, April 28, 1999 11:36 AM
> > > >> > >> To: Ietf Trade WG; Lewis, Tony
> > > >> > >> Subject: Brand IDs & their registration. Was: RE: Comments on
> > > >> > >> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > >> > >>
> > > >> > >> In the current specification the basic idea for identifying
> > brands
> > > is
> > > >> > that
> > > >> > >> they should be of the form "xxx:brandid" where "xxx" can be
> > "SET"
> > > >> which
> > > >> > >> indicates that the brandid is any valid brandid that is
> accepted
> > > by
> > > >> > SET,
> > > >> > >> or
> > > >> > >> alternatively "IOTP" which can be used to define any brand not
> > > >> defined
> > > >> > by
> > > >> > >> SET. The idea was that we should not need to define "Visa",
> > > >> > "MasterCard",
> > > >> > >> "American Express", etc more than once since they are already
> > > defined
> > > >> > and
> > > >> > >> registered by SET.
> > > >> > >>
> > > >> > >> However a couple of problems may arise ...
> > > >> > >>
> > > >> > >> USING THE SET BRAND ID FOR NON-SET PAYMENTS
> > > >> > >> Although IOTP can support SET as a payment protocol, it can
> also
> > > >> > support
> > > >> > >> credit card payments (using Secure Channel Credit Debit -
> SCCD)
> > > where
> > > >> > the
> > > >> > >> credit card information (no, name, expiration date, etc) is
> > coded
> > > >> > >> effectively in the clear but with privacy protection provided
> by
> > > >> using
> > > >> > a
> > > >> > >> secure channel such as SSL. In this way it provides a similar
> > > level
> > > >> of
> > > >> > >> privacy/security as for credit card payments that occur now
> > where
> > > a
> > > >> web
> > > >> > >> page
> > > >> > >> form is completed by the user.
> > > >> > >>
> > > >> > >> My question is, will it be reasonable to use the SET brandid
> in
> > > this
> > > >> > way
> > > >> > >> to
> > > >> > >> cover non-SET credit card payments. I *think* the answer is
> > "yes"
> > > as
> > > >> > you
> > > >> > >> can
> > > >> > >> quite imagine a situation where a consumer is offered a choice
> > of
> > > >> using
> > > >> > >> their VISA credit card to pay using either SET or SCCD.
> > > >> > >>
> > > >> > >> WHAT BRAND ID SHOULD BE USED FOR CO BRANDS
> > > >> > >> If a payment brand, such as a local brand or co-brand,
> chooses,
> > > >> > initiall
> > > >> > >> to
> > > >> > >> use just SCCD rather than SET then they would not (I think)
> need
> > > to
> > > >> > >> register
> > > >> > >> their brand with SET. In this case, they might register their
> > > brand
> > > >> as
> > > >> > an
> > > >> > >> "IOTP" brand. However if they later adopted SET, they would
> end
> > up
> > > >> with
> > > >> > >> potentially two equivalent Brand IDs. Do you think we might be
> > > better
> > > >> > off
> > > >> > >> with a straight IOTP brand and keep all the names under the
> > > >> procedures
> > > >> > >> defined by IANA? I'm not sure?
> > > >> > >>
> > > >> > >> REGISTERING NEW BRAND IDs
> > > >> > >> To help assist in answering the last point, the following is
> > what
> > > I'm
> > > >> > >> currently writing as the proposed IANA procedure for
> registering
> > > new
> > > >> > brand
> > > >> > >> ids. Any comments:
> > > >> > >>
> > > >> > >> >>>Clip>>>
> > > >> > >> The format of the Brand ID is either:
> > > >> > >> * SET:setbrand where setbrand is a brand which is accepted by
> > the
> > > >> > >> [SET] payment protocol
> > > >> > >> * IOTP:iotpbrand where iotpbrand may be:
> > > >> > >> - GeldKarte
> > > >> > >> - Mondex
> > > >> > >>
> > > >> > >> New values of the high level prefix (SET or IOTP) should be
> > > allocated
> > > >> > >> following review on the IETF Trade Working Group mailing list
> > and
> > > by
> > > >> > the
> > > >> > >> Designated Expert.
> > > >> > >>
> > > >> > >> Values of "setbrand" are allocated as defined in the [SET]
> > > >> > specifications.
> > > >> > >>
> > > >> > >> New values of "iotpbrand" must be announced to the IETF Trade
> WG
> > > >> > mailing
> > > >> > >> list and, if there are no objections within three weeks, be
> > > allocated
> > > >> > on
> > > >> > a
> > > >> > >> "first come first served" basis.
> > > >> > >> <<<End Clip<<<
> > > >> > >>
> > > >> > >> Regards
> > > >> > >>
> > > >> > >> David
> > > >> > >> > ----------
> > > >> > >> > From: Lewis, Tony[SMTP:[email-masked]]
> > > >> > >> > Sent: 28 April 1999 08:14
> > > >> > >> > To: Ietf Trade WG
> > > >> > >> > Subject: RE: Comments on
> > > >> draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> > > >> > >> > part  1
> > > >> > >> >
> > > >> > >> > In SET, the BrandID is either "brand" or "brand:product".
> > > >> > >> >
> > > >> > >> > In Japan, there are products that are co-branded.
> Essentially
> > > these
> > > >> > >> > products
> > > >> > >> > are private label cards for domestic transactions with an
> > > >> > international
> > > >> > >> > brand for non-domestic transactions. The private label can
> be
> > > >> > reflected
> > > >> > >> in
> > > >> > >> > a
> > > >> > >> > SET cardholder certificate as the "promotional card name"
> > under
> > > the
> > > >> > >> > international brand's hierarchy and/or the cardholder can
> have
> > a
> > > >> > >> > certificate
> > > >> > >> > issued under the private label hierarchy.
> > > >> > >> >
> > > >> > >> > There is no provision to carry both the private label (of
> the
> > > >> > Japanese
> > > >> > >> > credit card company) and the international brand as part of
> > the
> > > SET
> > > >> > >> > BrandID.
> > > >> > >> >
> > > >> > >> > Tony
> > > >
> > > >
> > >
> >-----------------------------------------------------------------------
> > > >Message addressed to: [email-masked]
> > > >Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > >To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> > the
> > > >body to: [email-masked]
> > > >
> > >
> > >
> -----------------------------------------------------------------------
> > > Message addressed to: [email-masked]
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > body to: [email-masked]
> > >
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> > 
> > 
> > 
> > 
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> > 
> 
> **************************************************************************
> ********************
> 
> This Email and any attached files are confidential and may also be
> privileged. 
> If you are not the intended recipient, please notify the postmaster using
> email 
> address [email-masked] or call +44 171 557 5000 and ask for the 
> IT Helpdesk.  You should not copy this email and any attached files, use
> them 
> for any purpose or disclose the contents to any other person; all copies
> of the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> **************************************************************************
> *******************
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: Ietf Trade WG <[email-masked]>
Subject: Re: Otp -> Iotp ?? 
Date: Tue, 18 May 1999 09:02:31 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I think we should go ahead and do the otp -> iotp change.

Thanks,
Donald

From:  David Burdett <[email-masked]>
Message-Id:  <[email-masked]>
To:  Ietf Trade WG <[email-masked]>
Date:  Tue, 18 May 1999 02:17:10 +0100

>There are still some element or attribute names in the DTD that contain
>"Otp" rather than "Iotp". Do we want to change them? My view is yes,
>although if anyone strongly objects I'm open to persuasion.
>
>Names to which this applies are:
>*	OtpMessage, 
>*	OtpTransId, 
>*	OtpTransType, 
>*	RespOtpMsg, 
>*	OtpMsgIdPrefix, 
>*	OtpMsgRef, 
>*	LastReceivedOtpMsgRef, 
>*	LastSentOtpMsgRef
>
>The first is an element. The rest are attributes.
>
>Thoughts?
>
>David
>> mailto:<[email-masked]>
>> Mondex International, US Advanced Technology Office
>> 111 Pine St, 6th Floor, San Francisco, CA 94111
>> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: Andrew Drapp <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: Brand IDs & their registration.
Date: Tue, 18 May 1999 12:43:41 +0900
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Yoshiaki as mentioned a bit before why we recommended the format:

SET:Brand:[Product]:[Promotional Card Name]

([] denotes optional)

Actually, at the meeting where this was discussed, we were only proposing a 
standard way for defining brands when performing a SET transaction. 
 Originally, the suggestion was for it to be IOTP:Brand:[Product]:[PCN]

I think there was a bit of confusion in the discussion.  SET brands are not 
defined as above.  A Set BrandID is composed of "Brand[:Product]".  We 
needed to be able to map the brands listed in the TPO to a SET BrandID.

Additionally, we considered it desirable to be able to distinguish 
Promotional or Dual card names.  This information is included in the SET 
certificate, but is not part of the actual BrandID.  The ability to offer 
discount based on the payment brand is a nice advantage in IOTP, and we 
wanted to preserve this with PCNs.  In order to do this, the PCN needed to 
be included as part of the IOTP brand name.  Again, the PCN is not part of 
the SET BrandID.

With SET, the colon is also optional, and only included if a Product name is 
given, for example:

Visa
Visa:Gold

We encountered a problem if we just tagged on the PCN.  If both of the above 
cards were UC Card dual brands, then tagging on the PCN would yield:

Visa:UC_Card
Visa:Gold:UC_Card

The problem is that in the first example above, "UC_Card" would be 
misinterpreted as the Product name within the SET BrandID, instead of as a 
PCN.  To eliminate this problem, we wanted to make the colons mandatory in 
the brand name, giving:

Visa::UC_Card
Visa:Gold:UC_Card

Thus, when we generated the SET messages in the SET bridge, the SET Brand ID 
would be given as "Visa" and "Visa:Gold", respectively.  However, the dual 
brand status of the card could still be used to provide discounts.

As a side note, while dual brands are specific to Japan, Promotional Card 
Names are not.  PCNs include store issued cards, alumni association cards, 
etc.

Anyway, because we wanted to require the extra colons in a brand name, it 
was suggested that we use a different namespace, specifically "SET:".

It doesn't really make much difference to us what prefix we use, as long as 
it is possible to both include the PCN, and be able to properly separate it 
from the SET BrandID.

Regards,

Andrew

--
Andrew Drapp
[email-masked]
Systems Development Laboratory, Hitachi Ltd.
Ozenji 1099, Asao, Kawasaki, 215-0013 JAPAN
TEL:+81-44-966-9111   FAX:+81-44-966-1796
PGP Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F

-----Original Message-----
From:	David Burdett [SMTP:[email-masked]]
Sent:	Tuesday, May 18, 1999 10:17 AM
To:	Ietf Trade WG
Subject:	RE: Brand IDs & their registration. Was: RE: Comments on 
draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1

Apart from Steve Fabes, I haven't received any comments on this 
suggestion.
Before doing this change I'd like some additional feedback.

David

> ----------
> From: 	David Burdett[SMTP:[email-masked]]
> Sent: 	05 May 1999 12:10
> To: 	Ietf Trade WG
> Subject: 	RE: Brand IDs & their registration. Was: RE: Comments on
> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
>
> Having read the various notes from Tony, Don and Steve on this topic. I
> think that we should have a separate IOTP brand registry, maintained by
> IANA
> under the procedures I included in an earlier email ... if only because 
it
> will be simpler. However I think this would mean that:
> *	we would need to copy all the SET brands to the IOTP spec
> *	we would need to also copy the SET method of defining Brand Ids to
> the IOTP spec (although we might be able to refer to the SET specs)
>
> The last item is less than ideal since it will involve replication and
> therefore the need to keep things in step.
>
> Thoughts?
>
> David
>
> > ----------
> > From: 	Lewis, Tony[SMTP:[email-masked]]
> > Sent: 	04 May 1999 17:09
> > To: 	Ietf Trade WG
> > Subject: 	RE: Brand IDs & their registration. Was: RE: Comments on
> > draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
> >
> > In fact, Europay, MasterCard, and Visa have established EMVCo. (EMVCo
> does
> > not currently have a web site so I can't point you there. I'm told the
> > site
> > won't be up until July.)
> >
> > EMV does not have brands in the same way that SET or IOTP do. EMV 
deals
> > with
> > application identifiers or AIDs. An AID consists of two parts: a
> > Registered
> > ID (RID) obtained from ISO and a Proprietary Extension (PIX). The RID 
is
> > roughly analogous to a brand. For example, Visa has an RID with a 
value
> of
> > 0xA000000003. Visa then assigns PIX values for various applications,
> e.g.,
> > Credit/Debit, VisaCash, etc.
> >
> > Typically, an RID will be obtained by a payment brand, but there is no
> > guarantee that there is a one to one correspondence between a brand 
and
> a
> > RID.
> >
> > As we look at a way to integrate EMV cards with SET, we expect to add
> AIDs
> > to the SET Initiation message, which will ultimately be replaced by
> IOTP.
> >
> > Tony
> > > ----------
> > > From: 	Steve Fabes[SMTP:[email-masked]]
> > > Sent: 	Tuesday, May 04, 1999 10:33 AM
> > > To: 	[email-masked]; Ietf Trade WG
> > > Subject: 	Re: Brand IDs & their registration. Was: RE: Comments on
> > > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > >
> > > Donald, I do not have much to add but when looking at the actions of
> > SETCo
> > > we should also anticipate that the EMV world will establish EMVCo 
and
> > its
> > > rules will need to be considered along side those of SETCo's. The
> > > membership
> > > of the two Co's will overlap but be different and to assume the same
> > brand
> > > and operating rules may be optimistic.
> > > -----Original Message-----
> > > From: [email-masked] <[email-masked]>
> > > To: Ietf Trade WG <[email-masked]>
> > > Date: Tuesday, May 04, 1999 09:33
> > > Subject: RE: Brand IDs & their registration. Was: RE: Comments on
> > > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > >
> > >
> > > >Regardless of EMV or whatever, it seems to me that we have a 
"brand"
> > > registry
> > > >problem to solve.  Credit/Debit cards are sort of odd creatures
> because
> > > they can
> > > >be used in payments via multiple different protocols.  Most stored
> > value
> > > cards
> > > >can be used via only a single protocol.
> > > >
> > > >SETco clearly operates a card brand regisgration operations, 
however
> > > limited and
> > > >even if it's only expressed in the brand level certificates that
> SETco
> > > allows to
> > > >be created under its root.  I think the hope was that the SET
> > > registration
> > > could
> > > >be used in IOTP for all credit/debit cards.  This would at least
> avoid
> > > the
> > > >problem where some brand was registered under different names at
> > > different
> > > >registries (where "different" could just be things like whether 
there
> > is
> > > really
> > > >a space between American and Express or whether the C is 
capitalized
> in
> > > >Mastercard or whether Visa is all caps, ...).  Is there a list of
> bands
> > > >officially supported by SETco and their official names?
> > > >
> > > >However, if SETco is inappropriate for this, because they won't
> > > "register"
> > > >brands that haven't joined", then we need a separate solution.  It
> > > certainly
> > > >isn't very difficult to set up regsitration via IANA, probably 
using
> > the
> > > same
> > > >Designated Expert criteria being used for other things.  The only
> > > difficulty I
> > > >can see is that some brand might get registered there for IOTP use
> and
> > > then
> > > >later join SETco or otherwise get registered in some other system
> under
> > > some
> > > >other name.  Various messyness with Discover/Novus, AT&T Universal
> Card
> > > changing
> > > >to CitiBank Universal Card and the like occur to me.  I'm not sure
> > those
> > > cases
> > > >are actually name change problems but one can image such.
> > > >
> > > >All this seems to imply that we need to be prepared to register
> > > credit/debit
> > > >card brands under "IOTP:".  I'm a bit reluctant to drop the "SET:"
> > branch
> > > of the
> > > >brand tree in IOTP.  If some brand exists under SETco but hasn't 
yet
> > been
> > > >registered under IOTP, it seems like it should be usable.  Of 
course,
> > > this
> > > means
> > > >that some brand registered under IOTP could later join SETco and
> could
> > > exist as
> > > >both IOTP:BrandX and SET:BrandX or SET:Brand-ex.  So you might get
> into
> > > >equivalence tables but these are really just an artifact of the 
real
> > > world
> > > being
> > > >messy and not particularly worse than brands splitting or merging.
> > > >
> > > >I don't see a major problem with us using
> > > brand:[product]:[promotional-name] if
> > > >we want, even after "SET:", although we should make it clear in 
that
> > case
> > > that
> > > >these values differ from those permitted in the SET protocol.  The
> > other
> > > >possibility that occurs to me would be to use brand[:product] and
> have
> > a
> > > >separate [promotional=xxx] optional attribute.
> > > >
> > > >What do people think?
> > > >
> > > >Thanks,
> > > >Donald
> > > >
> > > >Donald E. Eastlake, 3rd
> > > >17 Skyline Drive, Hawthorne, NY 10532 USA
> > > >[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
> > > >
> > > >home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
> > > >[email-masked]   tel: 1-914-276-2668
> > > >
> > > >
> > > >
> > > >David Burdett <[email-masked]> on 04/29/99 12:17:01 PM
> > > >
> > > >To:   Ietf Trade WG <[email-masked]>
> > > >cc:   "Lewis, Tony" <[email-masked]> (bcc: Donald
> > > Eastlake/Hawthorne/IBM)
> > > >Subject:  RE: Brand IDs & their registration. Was: RE: Comments on
> > > draft-ie
> > > >      tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >I agree with Tony. Smart card based EMV transactions will be the
> > dominant
> > > >payment model within a decade, probably even earlier especially in
> the
> > > >non-US part of the world. The main reasons being, in my view:
> > > >*    it will reduce fraud as it's much much harder to copy a smart
> card
> > > >than a mag stripe card
> > > >*    it makes internet credit card payments "card present"
> transactions
> > > >which should result in lower merchant fees. This also means that it
> > will
> > > be
> > > >much harder for customers to claim they never made an internet
> purchase
> > > >*    using a multi-application smart card you will be able to use
> just
> > > >one smart card for debit, credit, electronic cash, a loyalty scheme
> as
> > > well
> > > >as hold electronic tickets for anything from local cinema to your
> next
> > > >flight.
> > > >
> > > >To rephrase a MasterCard ad line, "smart cards are the future of
> > money".
> > > >
> > > >David
> > > >
> > > >> ----------
> > > >> From:   Lewis, Tony[SMTP:[email-masked]]
> > > >> Sent:   28 April 1999 20:30
> > > >> To:     Ietf Trade WG
> > > >> Subject:     RE: Brand IDs & their registration. Was: RE: 
Comments
> on
> > > >> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > >>
> > > >> My point is that the brand is "Visa" no matter whether using 
IOTP,
> > SET
> > > or
> > > >> any other protocol.
> > > >>
> > > >> As for EMV, the very first live SET 1.0 transaction was made 
using
> an
> > > EMV
> > > >> card with the EMV data carried inside a SET message extension. 
EMV
> > > credit
> > > >> and debit products are a significant part of the future of
> electronic
> > > >> commerce. I expect they will be the dominant model for payment in 
a
> > > >> decade.
> > > >>
> > > >> Tony
> > > >> > ----------
> > > >> > From:      Steve Fabes[SMTP:[email-masked]]
> > > >> > Sent:      Wednesday, April 28, 1999 3:43 PM
> > > >> > To:   Lewis, Tony; Ietf Trade WG
> > > >> > Subject:   Re: Brand IDs & their registration. Was: RE: 
Comments
> on
> > > >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > >> >
> > > >> > Tony - do your comments infer that SET.Visa will be the only
> > > e-Commerce
> > > >> > product that an IOTP product supplier can expect to see. Can 
you
> > see
> > > a
> > > >> day
> > > >> > when a Visa EMV 3.1.1 (or 3.x.x) based credit product could 
also
> be
> > > used
> > > >> > inside an IOTP product?
> > > >> > -----Original Message-----
> > > >> > From: Lewis, Tony <[email-masked]>
> > > >> > To: Ietf Trade WG <[email-masked]>
> > > >> > Date: Wednesday, April 28, 1999 13:21
> > > >> > Subject: RE: Brand IDs & their registration. Was: RE: Comments 
on
> > > >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > >> >
> > > >> >
> > > >> > >David,
> > > >> > >
> > > >> > >I am new to this group and do not know what lead to the 
current
> > > >> approach.
> > > >> > >There are undoubtedly some issues that I don't know about.
> > However,
> > > it
> > > >> > seems
> > > >> > >to me that a brand is a brand no matter what payment protocol 
is
> > > being
> > > >> > used.
> > > >> > >The only difference I see between "IOTP:Visa" and "SET:Visa" 
is
> > that
> > > >> the
> > > >> > >latter indicates that the brand is supported by a specific
> payment
> > > >> > protocol.
> > > >> > >Since you need to support brands other than those supported by
> > SET,
> > > >> there
> > > >> > >will need to be a registry. It seems to me that there should
> only
> > be
> > > >> one
> > > >> > >such registry rather than the two being proposed. I recommend
> > having
> > > a
> > > >> > >single domain for these brands. It seems reasonable to 
initially
> > > >> populate
> > > >> > it
> > > >> > >using the brands registered with SET and those non-SET brands
> you
> > > >> listed
> > > >> > in
> > > >> > >your note.
> > > >> > >
> > > >> > >Tony
> > > >> > >> ----------
> > > >> > >> From: David Burdett[SMTP:[email-masked]]
> > > >> > >> Sent: Wednesday, April 28, 1999 11:36 AM
> > > >> > >> To: Ietf Trade WG; Lewis, Tony
> > > >> > >> Subject: Brand IDs & their registration. Was: RE: Comments 
on
> > > >> > >> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > >> > >>
> > > >> > >> In the current specification the basic idea for identifying
> > brands
> > > is
> > > >> > that
> > > >> > >> they should be of the form "xxx:brandid" where "xxx" can be
> > "SET"
> > > >> which
> > > >> > >> indicates that the brandid is any valid brandid that is
> accepted
> > > by
> > > >> > SET,
> > > >> > >> or
> > > >> > >> alternatively "IOTP" which can be used to define any brand 
not
> > > >> defined
> > > >> > by
> > > >> > >> SET. The idea was that we should not need to define "Visa",
> > > >> > "MasterCard",
> > > >> > >> "American Express", etc more than once since they are 
already
> > > defined
> > > >> > and
> > > >> > >> registered by SET.
> > > >> > >>
> > > >> > >> However a couple of problems may arise ...
> > > >> > >>
> > > >> > >> USING THE SET BRAND ID FOR NON-SET PAYMENTS
> > > >> > >> Although IOTP can support SET as a payment protocol, it can
> also
> > > >> > support
> > > >> > >> credit card payments (using Secure Channel Credit Debit -
> SCCD)
> > > where
> > > >> > the
> > > >> > >> credit card information (no, name, expiration date, etc) is
> > coded
> > > >> > >> effectively in the clear but with privacy protection 
provided
> by
> > > >> using
> > > >> > a
> > > >> > >> secure channel such as SSL. In this way it provides a 
similar
> > > level
> > > >> of
> > > >> > >> privacy/security as for credit card payments that occur now
> > where
> > > a
> > > >> web
> > > >> > >> page
> > > >> > >> form is completed by the user.
> > > >> > >>
> > > >> > >> My question is, will it be reasonable to use the SET brandid
> in
> > > this
> > > >> > way
> > > >> > >> to
> > > >> > >> cover non-SET credit card payments. I *think* the answer is
> > "yes"
> > > as
> > > >> > you
> > > >> > >> can
> > > >> > >> quite imagine a situation where a consumer is offered a 
choice
> > of
> > > >> using
> > > >> > >> their VISA credit card to pay using either SET or SCCD.
> > > >> > >>
> > > >> > >> WHAT BRAND ID SHOULD BE USED FOR CO BRANDS
> > > >> > >> If a payment brand, such as a local brand or co-brand,
> chooses,
> > > >> > initiall
> > > >> > >> to
> > > >> > >> use just SCCD rather than SET then they would not (I think)
> need
> > > to
> > > >> > >> register
> > > >> > >> their brand with SET. In this case, they might register 
their
> > > brand
> > > >> as
> > > >> > an
> > > >> > >> "IOTP" brand. However if they later adopted SET, they would
> end
> > up
> > > >> with
> > > >> > >> potentially two equivalent Brand IDs. Do you think we might 
be
> > > better
> > > >> > off
> > > >> > >> with a straight IOTP brand and keep all the names under the
> > > >> procedures
> > > >> > >> defined by IANA? I'm not sure?
> > > >> > >>
> > > >> > >> REGISTERING NEW BRAND IDs
> > > >> > >> To help assist in answering the last point, the following is
> > what
> > > I'm
> > > >> > >> currently writing as the proposed IANA procedure for
> registering
> > > new
> > > >> > brand
> > > >> > >> ids. Any comments:
> > > >> > >>
> > > >> > >> >>>Clip>>>
> > > >> > >> The format of the Brand ID is either:
> > > >> > >> * SET:setbrand where setbrand is a brand which is accepted 
by
> > the
> > > >> > >> [SET] payment protocol
> > > >> > >> * IOTP:iotpbrand where iotpbrand may be:
> > > >> > >> - GeldKarte
> > > >> > >> - Mondex
> > > >> > >>
> > > >> > >> New values of the high level prefix (SET or IOTP) should be
> > > allocated
> > > >> > >> following review on the IETF Trade Working Group mailing 
list
> > and
> > > by
> > > >> > the
> > > >> > >> Designated Expert.
> > > >> > >>
> > > >> > >> Values of "setbrand" are allocated as defined in the [SET]
> > > >> > specifications.
> > > >> > >>
> > > >> > >> New values of "iotpbrand" must be announced to the IETF 
Trade
> WG
> > > >> > mailing
> > > >> > >> list and, if there are no objections within three weeks, be
> > > allocated
> > > >> > on
> > > >> > a
> > > >> > >> "first come first served" basis.
> > > >> > >> <<<End Clip<<<
> > > >> > >>
> > > >> > >> Regards
> > > >> > >>
> > > >> > >> David
> > > >> > >> > ----------
> > > >> > >> > From: Lewis, Tony[SMTP:[email-masked]]
> > > >> > >> > Sent: 28 April 1999 08:14
> > > >> > >> > To: Ietf Trade WG
> > > >> > >> > Subject: RE: Comments on
> > > >> draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> > > >> > >> > part  1
> > > >> > >> >
> > > >> > >> > In SET, the BrandID is either "brand" or "brand:product".
> > > >> > >> >
> > > >> > >> > In Japan, there are products that are co-branded.
> Essentially
> > > these
> > > >> > >> > products
> > > >> > >> > are private label cards for domestic transactions with an
> > > >> > international
> > > >> > >> > brand for non-domestic transactions. The private label can
> be
> > > >> > reflected
> > > >> > >> in
> > > >> > >> > a
> > > >> > >> > SET cardholder certificate as the "promotional card name"
> > under
> > > the
> > > >> > >> > international brand's hierarchy and/or the cardholder can
> have
> > a
> > > >> > >> > certificate
> > > >> > >> > issued under the private label hierarchy.
> > > >> > >> >
> > > >> > >> > There is no provision to carry both the private label (of
> the
> > > >> > Japanese
> > > >> > >> > credit card company) and the international brand as part 
of
> > the
> > > SET
> > > >> > >> > BrandID.
> > > >> > >> >
> > > >> > >> > Tony
> > > >
> > > >
> > >
> >-----------------------------------------------------------------------
> > > >Message addressed to: [email-masked]
> > > >Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > >To (un)subscribe send a message with "subscribe" or "unsubscribe" 
in
> > the
> > > >body to: [email-masked]
> > > >
> > >
> > >
> -----------------------------------------------------------------------
> > > Message addressed to: [email-masked]
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > body to: [email-masked]
> > >
> > 
-----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in 
the
> > body to: [email-masked]
> >
>
> 
**************************************************************************
> ********************
>
> This Email and any attached files are confidential and may also be
> privileged.
> If you are not the intended recipient, please notify the postmaster 
using
> email
> address [email-masked] or call +44 171 557 5000 and ask for the
> IT Helpdesk.  You should not copy this email and any attached files, use
> them
> for any purpose or disclose the contents to any other person; all copies
> of the
> Email and associated files in your possession should be destroyed.
>
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
>
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
>
> 
**************************************************************************
> *******************
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
>

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

This Email and any attached files are confidential and may also be 
privileged.
If you are not the intended recipient, please notify the postmaster using 
email
address [email-masked] or call +44 171 557 5000 and ask for the
IT Helpdesk.  You should not copy this email and any attached files, use 
them
for any purpose or disclose the contents to any other person; all copies of 
the
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

****************************************************************************  
*****************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: Brand IDs & their registration. Was: RE: Comments on draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
Date: Tue, 18 May 1999 02:17:05 +0100
Importance: high
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Apart from Steve Fabes, I haven't received any comments on this suggestion.
Before doing this change I'd like some additional feedback.

David

> ----------
> From: 	David Burdett[SMTP:[email-masked]]
> Sent: 	05 May 1999 12:10
> To: 	Ietf Trade WG
> Subject: 	RE: Brand IDs & their registration. Was: RE: Comments on
> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
> 
> Having read the various notes from Tony, Don and Steve on this topic. I
> think that we should have a separate IOTP brand registry, maintained by
> IANA
> under the procedures I included in an earlier email ... if only because it
> will be simpler. However I think this would mean that:
> *	we would need to copy all the SET brands to the IOTP spec
> *	we would need to also copy the SET method of defining Brand Ids to
> the IOTP spec (although we might be able to refer to the SET specs)
> 
> The last item is less than ideal since it will involve replication and
> therefore the need to keep things in step.
> 
> Thoughts?
> 
> David
> 
> > ----------
> > From: 	Lewis, Tony[SMTP:[email-masked]]
> > Sent: 	04 May 1999 17:09
> > To: 	Ietf Trade WG
> > Subject: 	RE: Brand IDs & their registration. Was: RE: Comments on
> > draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > 
> > In fact, Europay, MasterCard, and Visa have established EMVCo. (EMVCo
> does
> > not currently have a web site so I can't point you there. I'm told the
> > site
> > won't be up until July.)
> > 
> > EMV does not have brands in the same way that SET or IOTP do. EMV deals
> > with
> > application identifiers or AIDs. An AID consists of two parts: a
> > Registered
> > ID (RID) obtained from ISO and a Proprietary Extension (PIX). The RID is
> > roughly analogous to a brand. For example, Visa has an RID with a value
> of
> > 0xA000000003. Visa then assigns PIX values for various applications,
> e.g.,
> > Credit/Debit, VisaCash, etc.
> > 
> > Typically, an RID will be obtained by a payment brand, but there is no
> > guarantee that there is a one to one correspondence between a brand and
> a
> > RID.
> > 
> > As we look at a way to integrate EMV cards with SET, we expect to add
> AIDs
> > to the SET Initiation message, which will ultimately be replaced by
> IOTP.
> > 
> > Tony
> > > ----------
> > > From: 	Steve Fabes[SMTP:[email-masked]]
> > > Sent: 	Tuesday, May 04, 1999 10:33 AM
> > > To: 	[email-masked]; Ietf Trade WG
> > > Subject: 	Re: Brand IDs & their registration. Was: RE: Comments on
> > > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > 
> > > Donald, I do not have much to add but when looking at the actions of
> > SETCo
> > > we should also anticipate that the EMV world will establish EMVCo and
> > its
> > > rules will need to be considered along side those of SETCo's. The
> > > membership
> > > of the two Co's will overlap but be different and to assume the same
> > brand
> > > and operating rules may be optimistic.
> > > -----Original Message-----
> > > From: [email-masked] <[email-masked]>
> > > To: Ietf Trade WG <[email-masked]>
> > > Date: Tuesday, May 04, 1999 09:33
> > > Subject: RE: Brand IDs & their registration. Was: RE: Comments on
> > > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > 
> > > 
> > > >Regardless of EMV or whatever, it seems to me that we have a "brand"
> > > registry
> > > >problem to solve.  Credit/Debit cards are sort of odd creatures
> because
> > > they can
> > > >be used in payments via multiple different protocols.  Most stored
> > value
> > > cards
> > > >can be used via only a single protocol.
> > > >
> > > >SETco clearly operates a card brand regisgration operations, however
> > > limited and
> > > >even if it's only expressed in the brand level certificates that
> SETco
> > > allows to
> > > >be created under its root.  I think the hope was that the SET
> > > registration
> > > could
> > > >be used in IOTP for all credit/debit cards.  This would at least
> avoid
> > > the
> > > >problem where some brand was registered under different names at
> > > different
> > > >registries (where "different" could just be things like whether there
> > is
> > > really
> > > >a space between American and Express or whether the C is capitalized
> in
> > > >Mastercard or whether Visa is all caps, ...).  Is there a list of
> bands
> > > >officially supported by SETco and their official names?
> > > >
> > > >However, if SETco is inappropriate for this, because they won't
> > > "register"
> > > >brands that haven't joined", then we need a separate solution.  It
> > > certainly
> > > >isn't very difficult to set up regsitration via IANA, probably using
> > the
> > > same
> > > >Designated Expert criteria being used for other things.  The only
> > > difficulty I
> > > >can see is that some brand might get registered there for IOTP use
> and
> > > then
> > > >later join SETco or otherwise get registered in some other system
> under
> > > some
> > > >other name.  Various messyness with Discover/Novus, AT&T Universal
> Card
> > > changing
> > > >to CitiBank Universal Card and the like occur to me.  I'm not sure
> > those
> > > cases
> > > >are actually name change problems but one can image such.
> > > >
> > > >All this seems to imply that we need to be prepared to register
> > > credit/debit
> > > >card brands under "IOTP:".  I'm a bit reluctant to drop the "SET:"
> > branch
> > > of the
> > > >brand tree in IOTP.  If some brand exists under SETco but hasn't yet
> > been
> > > >registered under IOTP, it seems like it should be usable.  Of course,
> > > this
> > > means
> > > >that some brand registered under IOTP could later join SETco and
> could
> > > exist as
> > > >both IOTP:BrandX and SET:BrandX or SET:Brand-ex.  So you might get
> into
> > > >equivalence tables but these are really just an artifact of the real
> > > world
> > > being
> > > >messy and not particularly worse than brands splitting or merging.
> > > >
> > > >I don't see a major problem with us using
> > > brand:[product]:[promotional-name] if
> > > >we want, even after "SET:", although we should make it clear in that
> > case
> > > that
> > > >these values differ from those permitted in the SET protocol.  The
> > other
> > > >possibility that occurs to me would be to use brand[:product] and
> have
> > a
> > > >separate [promotional=xxx] optional attribute.
> > > >
> > > >What do people think?
> > > >
> > > >Thanks,
> > > >Donald
> > > >
> > > >Donald E. Eastlake, 3rd
> > > >17 Skyline Drive, Hawthorne, NY 10532 USA
> > > >[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
> > > >
> > > >home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
> > > >[email-masked]   tel: 1-914-276-2668
> > > >
> > > >
> > > >
> > > >David Burdett <[email-masked]> on 04/29/99 12:17:01 PM
> > > >
> > > >To:   Ietf Trade WG <[email-masked]>
> > > >cc:   "Lewis, Tony" <[email-masked]> (bcc: Donald
> > > Eastlake/Hawthorne/IBM)
> > > >Subject:  RE: Brand IDs & their registration. Was: RE: Comments on
> > > draft-ie
> > > >      tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >I agree with Tony. Smart card based EMV transactions will be the
> > dominant
> > > >payment model within a decade, probably even earlier especially in
> the
> > > >non-US part of the world. The main reasons being, in my view:
> > > >*    it will reduce fraud as it's much much harder to copy a smart
> card
> > > >than a mag stripe card
> > > >*    it makes internet credit card payments "card present"
> transactions
> > > >which should result in lower merchant fees. This also means that it
> > will
> > > be
> > > >much harder for customers to claim they never made an internet
> purchase
> > > >*    using a multi-application smart card you will be able to use
> just
> > > >one smart card for debit, credit, electronic cash, a loyalty scheme
> as
> > > well
> > > >as hold electronic tickets for anything from local cinema to your
> next
> > > >flight.
> > > >
> > > >To rephrase a MasterCard ad line, "smart cards are the future of
> > money".
> > > >
> > > >David
> > > >
> > > >> ----------
> > > >> From:   Lewis, Tony[SMTP:[email-masked]]
> > > >> Sent:   28 April 1999 20:30
> > > >> To:     Ietf Trade WG
> > > >> Subject:     RE: Brand IDs & their registration. Was: RE: Comments
> on
> > > >> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > >>
> > > >> My point is that the brand is "Visa" no matter whether using IOTP,
> > SET
> > > or
> > > >> any other protocol.
> > > >>
> > > >> As for EMV, the very first live SET 1.0 transaction was made using
> an
> > > EMV
> > > >> card with the EMV data carried inside a SET message extension. EMV
> > > credit
> > > >> and debit products are a significant part of the future of
> electronic
> > > >> commerce. I expect they will be the dominant model for payment in a
> > > >> decade.
> > > >>
> > > >> Tony
> > > >> > ----------
> > > >> > From:      Steve Fabes[SMTP:[email-masked]]
> > > >> > Sent:      Wednesday, April 28, 1999 3:43 PM
> > > >> > To:   Lewis, Tony; Ietf Trade WG
> > > >> > Subject:   Re: Brand IDs & their registration. Was: RE: Comments
> on
> > > >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > >> >
> > > >> > Tony - do your comments infer that SET.Visa will be the only
> > > e-Commerce
> > > >> > product that an IOTP product supplier can expect to see. Can you
> > see
> > > a
> > > >> day
> > > >> > when a Visa EMV 3.1.1 (or 3.x.x) based credit product could also
> be
> > > used
> > > >> > inside an IOTP product?
> > > >> > -----Original Message-----
> > > >> > From: Lewis, Tony <[email-masked]>
> > > >> > To: Ietf Trade WG <[email-masked]>
> > > >> > Date: Wednesday, April 28, 1999 13:21
> > > >> > Subject: RE: Brand IDs & their registration. Was: RE: Comments on
> > > >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > >> >
> > > >> >
> > > >> > >David,
> > > >> > >
> > > >> > >I am new to this group and do not know what lead to the current
> > > >> approach.
> > > >> > >There are undoubtedly some issues that I don't know about.
> > However,
> > > it
> > > >> > seems
> > > >> > >to me that a brand is a brand no matter what payment protocol is
> > > being
> > > >> > used.
> > > >> > >The only difference I see between "IOTP:Visa" and "SET:Visa" is
> > that
> > > >> the
> > > >> > >latter indicates that the brand is supported by a specific
> payment
> > > >> > protocol.
> > > >> > >Since you need to support brands other than those supported by
> > SET,
> > > >> there
> > > >> > >will need to be a registry. It seems to me that there should
> only
> > be
> > > >> one
> > > >> > >such registry rather than the two being proposed. I recommend
> > having
> > > a
> > > >> > >single domain for these brands. It seems reasonable to initially
> > > >> populate
> > > >> > it
> > > >> > >using the brands registered with SET and those non-SET brands
> you
> > > >> listed
> > > >> > in
> > > >> > >your note.
> > > >> > >
> > > >> > >Tony
> > > >> > >> ----------
> > > >> > >> From: David Burdett[SMTP:[email-masked]]
> > > >> > >> Sent: Wednesday, April 28, 1999 11:36 AM
> > > >> > >> To: Ietf Trade WG; Lewis, Tony
> > > >> > >> Subject: Brand IDs & their registration. Was: RE: Comments on
> > > >> > >> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > > >> > >>
> > > >> > >> In the current specification the basic idea for identifying
> > brands
> > > is
> > > >> > that
> > > >> > >> they should be of the form "xxx:brandid" where "xxx" can be
> > "SET"
> > > >> which
> > > >> > >> indicates that the brandid is any valid brandid that is
> accepted
> > > by
> > > >> > SET,
> > > >> > >> or
> > > >> > >> alternatively "IOTP" which can be used to define any brand not
> > > >> defined
> > > >> > by
> > > >> > >> SET. The idea was that we should not need to define "Visa",
> > > >> > "MasterCard",
> > > >> > >> "American Express", etc more than once since they are already
> > > defined
> > > >> > and
> > > >> > >> registered by SET.
> > > >> > >>
> > > >> > >> However a couple of problems may arise ...
> > > >> > >>
> > > >> > >> USING THE SET BRAND ID FOR NON-SET PAYMENTS
> > > >> > >> Although IOTP can support SET as a payment protocol, it can
> also
> > > >> > support
> > > >> > >> credit card payments (using Secure Channel Credit Debit -
> SCCD)
> > > where
> > > >> > the
> > > >> > >> credit card information (no, name, expiration date, etc) is
> > coded
> > > >> > >> effectively in the clear but with privacy protection provided
> by
> > > >> using
> > > >> > a
> > > >> > >> secure channel such as SSL. In this way it provides a similar
> > > level
> > > >> of
> > > >> > >> privacy/security as for credit card payments that occur now
> > where
> > > a
> > > >> web
> > > >> > >> page
> > > >> > >> form is completed by the user.
> > > >> > >>
> > > >> > >> My question is, will it be reasonable to use the SET brandid
> in
> > > this
> > > >> > way
> > > >> > >> to
> > > >> > >> cover non-SET credit card payments. I *think* the answer is
> > "yes"
> > > as
> > > >> > you
> > > >> > >> can
> > > >> > >> quite imagine a situation where a consumer is offered a choice
> > of
> > > >> using
> > > >> > >> their VISA credit card to pay using either SET or SCCD.
> > > >> > >>
> > > >> > >> WHAT BRAND ID SHOULD BE USED FOR CO BRANDS
> > > >> > >> If a payment brand, such as a local brand or co-brand,
> chooses,
> > > >> > initiall
> > > >> > >> to
> > > >> > >> use just SCCD rather than SET then they would not (I think)
> need
> > > to
> > > >> > >> register
> > > >> > >> their brand with SET. In this case, they might register their
> > > brand
> > > >> as
> > > >> > an
> > > >> > >> "IOTP" brand. However if they later adopted SET, they would
> end
> > up
> > > >> with
> > > >> > >> potentially two equivalent Brand IDs. Do you think we might be
> > > better
> > > >> > off
> > > >> > >> with a straight IOTP brand and keep all the names under the
> > > >> procedures
> > > >> > >> defined by IANA? I'm not sure?
> > > >> > >>
> > > >> > >> REGISTERING NEW BRAND IDs
> > > >> > >> To help assist in answering the last point, the following is
> > what
> > > I'm
> > > >> > >> currently writing as the proposed IANA procedure for
> registering
> > > new
> > > >> > brand
> > > >> > >> ids. Any comments:
> > > >> > >>
> > > >> > >> >>>Clip>>>
> > > >> > >> The format of the Brand ID is either:
> > > >> > >> * SET:setbrand where setbrand is a brand which is accepted by
> > the
> > > >> > >> [SET] payment protocol
> > > >> > >> * IOTP:iotpbrand where iotpbrand may be:
> > > >> > >> - GeldKarte
> > > >> > >> - Mondex
> > > >> > >>
> > > >> > >> New values of the high level prefix (SET or IOTP) should be
> > > allocated
> > > >> > >> following review on the IETF Trade Working Group mailing list
> > and
> > > by
> > > >> > the
> > > >> > >> Designated Expert.
> > > >> > >>
> > > >> > >> Values of "setbrand" are allocated as defined in the [SET]
> > > >> > specifications.
> > > >> > >>
> > > >> > >> New values of "iotpbrand" must be announced to the IETF Trade
> WG
> > > >> > mailing
> > > >> > >> list and, if there are no objections within three weeks, be
> > > allocated
> > > >> > on
> > > >> > a
> > > >> > >> "first come first served" basis.
> > > >> > >> <<<End Clip<<<
> > > >> > >>
> > > >> > >> Regards
> > > >> > >>
> > > >> > >> David
> > > >> > >> > ----------
> > > >> > >> > From: Lewis, Tony[SMTP:[email-masked]]
> > > >> > >> > Sent: 28 April 1999 08:14
> > > >> > >> > To: Ietf Trade WG
> > > >> > >> > Subject: RE: Comments on
> > > >> draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> > > >> > >> > part  1
> > > >> > >> >
> > > >> > >> > In SET, the BrandID is either "brand" or "brand:product".
> > > >> > >> >
> > > >> > >> > In Japan, there are products that are co-branded.
> Essentially
> > > these
> > > >> > >> > products
> > > >> > >> > are private label cards for domestic transactions with an
> > > >> > international
> > > >> > >> > brand for non-domestic transactions. The private label can
> be
> > > >> > reflected
> > > >> > >> in
> > > >> > >> > a
> > > >> > >> > SET cardholder certificate as the "promotional card name"
> > under
> > > the
> > > >> > >> > international brand's hierarchy and/or the cardholder can
> have
> > a
> > > >> > >> > certificate
> > > >> > >> > issued under the private label hierarchy.
> > > >> > >> >
> > > >> > >> > There is no provision to carry both the private label (of
> the
> > > >> > Japanese
> > > >> > >> > credit card company) and the international brand as part of
> > the
> > > SET
> > > >> > >> > BrandID.
> > > >> > >> >
> > > >> > >> > Tony
> > > >
> > > >
> > >
> >-----------------------------------------------------------------------
> > > >Message addressed to: [email-masked]
> > > >Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > >To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> > the
> > > >body to: [email-masked]
> > > >
> > > 
> > >
> -----------------------------------------------------------------------
> > > Message addressed to: [email-masked]
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > body to: [email-masked]
> > > 
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> > 
> 
> **************************************************************************
> ********************
> 
> This Email and any attached files are confidential and may also be
> privileged. 
> If you are not the intended recipient, please notify the postmaster using
> email 
> address [email-masked] or call +44 171 557 5000 and ask for the 
> IT Helpdesk.  You should not copy this email and any attached files, use
> them 
> for any purpose or disclose the contents to any other person; all copies
> of the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> **************************************************************************
> *******************
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>,  Don Eastlake <[email-masked]>
Subject: RE: Using XML as well as HTML 
Date: Tue, 18 May 1999 02:17:01 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The problem is that the XML style sheet (XSL) specifications are not
finalised. Specifically:
*	"Associating stylesheets with XML documents" at
http://www.w3.org/TR/xml-stylesheet is a proposed recommendation and
requires comments to be submitted by 26 May, and
*	"Extensible Stylesheet Language (XSL) Specification" at
http://www.w3.org/TR/WD-xsl is just a working draft.

The first document also states  " ... the technology explained in this
Proposed Recommendation is not the only one for its task. There are others
available or under development that allow the link to be outside the XML
document ..." which means that further changes can be anticipated.

Therefore I suggest that the a "XML Packaging" section is added to the IOTP
specification after the existing section on "HTML packaging" that says ...

"Support for XML is recommended. When XML needs to be displayed, for example
to display the content of an Order Description to a Consumer, then the
method employed is at the discretion of the implementer.

	[Note]	At the time of writing this specification, standards are
under development that specify XML style sheets that show how XML documents
should be displayed. See:
				*	"Extensible Stylesheet Language
(XSL) Specification" at http://www.w3.org/TR/WD-xsl, and
				*	"Associating stylesheets with XML
documents" at http://www.w3.org/TR/xml-stylesheet.
				Once these standards become W3C
"Recommendations", then it is anticipated that this specification will be
amended if practical.
	[Note End]	 "

... and change references to "plain text and HTML" to additionally refer to
XML  for instance ...

"For interoperability, implementations must support Plain Text, HTML and XML
as a minimum so that it can be easily displayed."

This applies to the sections on: "Order Description Content", "Payment Note"
and "Delivery Note"

Any comments?

David
> ----------
> From: 	Donald E. Eastlake 3rd[SMTP:[email-masked]]
> Sent: 	10 May 1999 19:56
> To: 	Ietf Trade WG
> Subject: 	Re: Using XML as well as HTML 
> 
> It seems to me that the solution for this involves, among other things,
> the Offer Request message we have defered until after v1.0...
> 
> I suggest we go for simplicity in v1.0 and just say that support of
> XML is recommended even though your point about XML support at some
> level being implied since IOTP uses XML syntax...
> 
> Thanks,
> Donald
> 
> From:  David Burdett <[email-masked]>
> Message-Id:  <[email-masked]>
> Date:  Fri, 30 Apr 1999 20:04:09 +0100
> 
> >I agree that XML should be recommended, the problem is how do you
> discover
> >if the consumer has XML/XSL support in their IOTP implementation? 
> >
> >If a merchant or one of the other trading roles is unsure, then they'll
> >never send order descrciptions, etc, in XML to the consumer. On the other
> >hand if a particular IOTP consumer client software becomes highly popular
> >that supports XML/XSL, then it is reasonable safe for merchants to use
> XML
> >and more might do so.
> >
> >Finally, you could argue that since to do IOTP at all, there must be XML
> >support then at least half the solution *must* be there. In this case,
> you
> >could recommend displaying a message to the user of the problem and
> >displaying XML in a very simple way.
> >
> >David
> >
> >
> >> ----------
> >> From: 	Donald E. Eastlake 3rd[SMTP:[email-masked]]
> >> Sent: 	29 April 1999 10:04
> >> To: 	Ietf Trade WG
> >> Subject: 	Re: Using XML as well as HTML 
> >> 
> >> I believe that support for XML should be recommended but not required.
> >> 
> >> Thanks,
> >> Donald
> >> 
> >> From:  David Burdett <[email-masked]>
> >> Message-Id:
> <[email-masked]>
> >> To:  Ietf Trade WG <[email-masked]>
> >> Date:  Thu, 29 Apr 1999 17:17:05 +0100
> >> 
> >> >Following on from my other email on using HTML, the spec doesn't
> >> currently
> >> >describe how XML could be used. I think that it should. We could
> provide
> >> >similar guidelines for XML/XSL to the ones for HTML. 
> >> >
> >> >Who thinks this is a good idea?
> >> >
> >> >David
> >> >
> >> >THIS EMAIL IS FOR UNRESTRICTED DISTRIBUTION
> >> >> mailto:<[email-masked]>
> >> >> Mondex International, US Advanced Technology Office
> >> >> 111 Pine St, 6th Floor, San Francisco, CA 94111
> >> >> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> >> -----------------------------------------------------------------------
> >> Message addressed to: [email-masked]
> >> Archive available at: http://www.elistx.com/archives/ietf-trade/
> >> To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> >> body to: [email-masked]
> >> 
> >
> >*************************************************************************
> ***********
> **********
> >
> >This Email and any attached files are confidential and may also be
> privileged. 
> >If you are not the intended recipient, please notify the postmaster using
> email 
> >address [email-masked] or call +44 171 557 5000 and ask for the 
> >IT Helpdesk.  You should not copy this email and any attached files, use
> them 
> >for any purpose or disclose the contents to any other person; all copies
> of the 
> >Email and associated files in your possession should be destroyed.
> >
> >Mondex International Limited
> >47-53 Cannon Street
> >London EC4M 5SQ
> >United Kingdom
> >Registered No: 3122085, England
> >
> >Phone:          +44 171 557 5000
> >Fax:            +44 171 557 5200
> >Email:          [email-masked]
> >WebSite:        http://www.mondexinternational.com
> >
> >*************************************************************************
> ***********
> *********
> >-----------------------------------------------------------------------
> >Message addressed to: [email-masked]
> >Archive available at: http://www.elistx.com/archives/ietf-trade/
> >To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> >body to: [email-masked]
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: Otp -> Iotp ??
Date: Tue, 18 May 1999 02:17:10 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

There are still some element or attribute names in the DTD that contain
"Otp" rather than "Iotp". Do we want to change them? My view is yes,
although if anyone strongly objects I'm open to persuasion.

Names to which this applies are:
*	OtpMessage, 
*	OtpTransId, 
*	OtpTransType, 
*	RespOtpMsg, 
*	OtpMsgIdPrefix, 
*	OtpMsgRef, 
*	LastReceivedOtpMsgRef, 
*	LastSentOtpMsgRef

The first is an element. The rest are attributes.

Thoughts?

David
> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Yoshiaki KAWATSURA <[email-masked]>
Cc: Ietf Trade WG <[email-masked]>
Subject: RE: PayReceiptRefs (Problem of IOTP Spec.)
Date: Tue, 18 May 1999 02:16:57 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Yoshiaki

I think I understand where you're coming from. The difficulty is all around
how the payment software (you refer to it as the payment bridge) identifies
what data it has returned as packaged content, forms the "Payment Receipt".

For those reading this that are not familiar with this part of the
specification, there are two parts of the payment response component that
contain information about a payment:
*	the Payment Receipt (that Yoshiaki is discussing) that contains a
record of the payment either from:
	*	**Payment Protocol** or other **Payment Software** generated
information if the payment protocol can generate this type of information,
or
	*	HTML or text data if it cannot
*	the Payment Note, that contains only human readable information
about the payment - as text or HTML - and may include additional information
such as account balance after a withdrawal.

The key difference is that Payment Receipt data (unlike a Payment Note) can
sometines be checked by software that understands the payment method being
used, to *prove* that the payment occurred at the *payment protocol* level.
For example both SET and Mondex can digitally sign data using payment method
specific certificates that can be independently checked after the event by
SET/Mondex aware software.

Anyway to get back to Yoshiaki's ideas ...

In order to generate a Payment Receipt from a payment protocol message, the
payment software has to be able to identify which Packaged Content elements
it has returned make up the Payment Receipt. Part of the difficulty is that
the Payment Software should be unaware of IOTP, if IOTP is to transport a
payment protocol completely transparently. As the current specification
requires that PaymentReceiptRefs, only refers to Payment Scheme Components,
it is difficult for the software to do this.

I think that Yoshiaki is suggesting instead, that the Payment Software
returns the name, or some other code, for a payment protocol message and
identifies, at the same time whether or not this particular data forms part
(or potentially all) of the receipt.

Using the name of the Packaged Content that contains the Payment Protocol
data, is a reasonable idea as the name can be set by the Payment Software
(for example it could be message name or number of a protocol message).

However Yoshiaki suggests that the "Name" should be "unique within the
transaction". I don't think this is a good idea since, for example, another
role, such as a Delivery Handler, might coincidentally use the same name and
since he knows nothing of the detail of the payment there could be
duplicate. Instead I suggest that the Name must be unique within a Payment
and to facilitate this add PaymentRef as an attribute of the Payment Scheme
Component.

So I suggest the following as changes to the specification ...

1. Change the PayReceiptRefs attribute within the PayReceipt component to
PayReceiptNameRefs

2. Remove the definition of the PayReceiptRefs attribute in the Pay Receipt
Component and add a PayReceiptNameRefs attribute with a definition as
follows ...
		"Optionally contains a list of the values of the Name
attributes of Packaged Content elements that together make up the receipt.
The Packaged Content elements are contained either within:
		*	Payment Scheme Data components exchanged between the
Payment Handler and the Consumer roles during the Payment, and/or
		*	the Payment Receipt component itself.
		Note that:
		*	each payment scheme defines in its supplement the
Names of the Packaged Content elements that must be listed in this attribute
(if any). 
		*	if a Payment Scheme Component contains Packaged
Content elements with a name that matches a name within PaymentReceiptRefs,
then those Payment Scheme Components must be referenced by Digests in the
Payment Response signature component (if such a signature is being used)
		The client software should save all the components
referenced so that the payment receipt can be reconstructed when required."

3. Add PaymentRef as a Required attribute on PaymentSchemeComponent to
identify the Payment Component to which a Payment Scheme Component is
related, so that is easier to check that the names on the PackagedContent
elements within the Payment Scheme Components for a payment are unique.

4. Change the description of the PackagedContent within the PaySchemeData
component to read ...
		"Contains payment scheme protocol information as Packaged
Content elements (see section 3.7). See the payment scheme supplement for
the definition of its content.
		Note that:
		*	the values of the Name attribute of each packaged
content element are defined by the Payment Protocol Supplement
		*	the value of each Name must be unique within a
Payment where a Payment is defined as all Payment Scheme or Payment Receipt
Components with the same value of the PaymentRef attribute"

5. Change the description of the PackagedContent within the PayReceipt to
read ...
		Contains payment scheme payment receipt information as
Packaged Content elements (see section 3.7). See the payment scheme
supplement for the definition of its content.
		Note that:
		*	the values of the Name attribute of each packaged
content element are defined by the Payment Protocol Supplement
		*	the value of each Name must be unique within a
Payment where a Payment is defined as all Payment Scheme or Payment Receipt
Components,  with the same value of the PaymentRef attribute

5. The DTD for the PaymentReceipt and PaymentSchemeData components become
...
<!-- PAYMENT SCHEME COMPONENT -->
<!ELEMENT PaySchemeData (PackagedContent+) >
<!ATTLIST PaySchemeData
 ID                 ID      #REQUIRED
 PaymentRef         NMTOKEN #REQUIRED <<<<<NEW
 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 <<<<CHANGED
 ContentSoftwareId  CDATA   #IMPLIED >

Any questions let me know.

David

> ----------
> From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> Sent: 	02 May 1999 08:30
> To: 	[email-masked]
> Cc: 	[email-masked]; [email-masked]
> Subject: 	PayReceiptRefs (Problem of IOTP Spec.)
> 
> There is a problem for PayReceiptRefs in PayReceipt component in the
> current IOTP specification.
> 
> Problem:
> In the current specification, we can not use the PayReceiptRefs.  IOTP
> Payment Bridge of the Payment Handler can not set the PayReceiptRefs
> because the Bridge can not know IOTP Component ID.  IOTP Payment Bridge
> of the Consumer can not also get the components correspond to IDs
> which is included in the PayReceiptRefs.
> 
> So I suggest the following changes.
>  
> Change:
> (a) Change PayReceiptRefs to PayReceiptRefNames element.
>     (PayReceiptRefs is dropped)
> (b) PayReceiptRefNames defines as the list of Name element in
>     PackagedContent of PaySchemeData component.
> (c) The Name element in PackagedContent must be unique in the transaction.
> (d) The PaySchemeData Component, that Name element is the same ones 
> in the token of PayReceiptRefNames, must be hashed and signed in the
> Payment
> Response signature component.
> 
> Sequence of Process:
> (1) The Payment Hander Payment Bridge set the PayReceiptRefNames.
> (2) Payment Handler OAC hashes and signs to the corresponding
> PaySchemeData.
> (3) Consumer OAC checks the signatures.
> (4) OAC picks up the PackagedContents which include the same Name
>     element in PayReceiptRefNames and passes them to the Payment Bridge as
>     PayReceiptPackagedContent in the CheckPayReceipt.
> 
> What do you think this?
> 
> P.S. I can not response till 9th May because I will go to Thai Land in
> vacation.
>  
> Thanks,
> --
> Yoshiaki Kawatsura
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: [email-masked], Tony Lewis <[email-masked]>
Cc: Ietf Trade WG <[email-masked]>
Subject: RE: Brand IDs & their registration. Was: RE: Comments on draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
Date: Tue, 18 May 1999 02:17:09 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

John/Tony

I don't think the RID+PIX is the way to go. Surely all we need is a clearly
defined name declared in a public forum (e.g. the Trade WG or its
successor). For example we could declare:
*	MasterCard (implies credit)
*	Maestro (MasterCard debit)
*	Mondex (electronic cash)
*	Visa (implies credit)
*	VisaCash (electronic cash)

The "protocols" that can be used with each brand, e.g. SETv1.0, SCCD, etc.
are then separately specified with their own individual "payment
protocol/version no" identifiers. 

There is still the need to know which payment protocols can be used with
each brand. However I don't think this an IOTP issue since:
*	Merchant's will know when they create a Brand List which protocols
are applicable for each Brand
*	Consumer's will know when they add a new brand what type of payment
instrument it is (e.g. Credit) and the consumer software can then decide
which payment protocols apply.

Do you both agree?

David

> ----------
> From:
> [email-masked][SMTP:[email-masked]]
> Sent: 	05 May 1999 23:01
> To: 	Ietf Trade WG
> Subject: 	RE: Brand IDs & their registration. Was: RE: Comments on
> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
> 
> 
> 
> My understanding is that a RID (Registered ID obtained from ISO) is
> assigned
> more to an organization or association.
> 
> It is not easy to distinguish between
> a RID, a brand, and a consumer acceptance mark.
> 
> For MasterCard, the same RID is used for:
>    - MasterCard International chip credit cards,
>    - and Maestro International pin based debit cards - which uses a
> different
>    acceptance "mark" for what some consumers may consider a "brand".
> 
> For MasterCard's RID the hexadecimal characters 0xA000000004 have been
> assigned
> by ISO to MasterCard.  The RID does not differentiate between our
> MasterCard and
> Maestro marks,
> but it is only the full RID + PIX (AID) that distinguishes what "brand" or
> mark
> is involved.
> 
> 
> 
> 
> 
> "Lewis, Tony" <[email-masked]> on 05/04/99 08:09:25 PM
> 
> To:   Ietf Trade WG <[email-masked]>
> cc:    (bcc: John Wankmueller/NYC/MASTERCARD)
> Subject:  RE: Brand IDs & their registration. Was: RE: Comments on
> draft-ie tf-t
>       rade-iotp-v1.0-protocol-03.txt, part 1
> 
> 
> 
> 
> In fact, Europay, MasterCard, and Visa have established EMVCo. (EMVCo does
> not currently have a web site so I can't point you there. I'm told the
> site
> won't be up until July.)
> 
> EMV does not have brands in the same way that SET or IOTP do. EMV deals
> with
> application identifiers or AIDs. An AID consists of two parts: a
> Registered
> ID (RID) obtained from ISO and a Proprietary Extension (PIX). The RID is
> roughly analogous to a brand. For example, Visa has an RID with a value of
> 0xA000000003. Visa then assigns PIX values for various applications, e.g.,
> Credit/Debit, VisaCash, etc.
> 
> Typically, an RID will be obtained by a payment brand, but there is no
> guarantee that there is a one to one correspondence between a brand and a
> RID.
> 
> As we look at a way to integrate EMV cards with SET, we expect to add AIDs
> to the SET Initiation message, which will ultimately be replaced by IOTP.
> 
> Tony
> > ----------
> > From:   Steve Fabes[SMTP:[email-masked]]
> > Sent:   Tuesday, May 04, 1999 10:33 AM
> > To:     [email-masked]; Ietf Trade WG
> > Subject:     Re: Brand IDs & their registration. Was: RE: Comments on
> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> >
> > Donald, I do not have much to add but when looking at the actions of
> SETCo
> > we should also anticipate that the EMV world will establish EMVCo and
> its
> > rules will need to be considered along side those of SETCo's. The
> > membership
> > of the two Co's will overlap but be different and to assume the same
> brand
> > and operating rules may be optimistic.
> > -----Original Message-----
> > From: [email-masked] <[email-masked]>
> > To: Ietf Trade WG <[email-masked]>
> > Date: Tuesday, May 04, 1999 09:33
> > Subject: RE: Brand IDs & their registration. Was: RE: Comments on
> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> >
> >
> > >Regardless of EMV or whatever, it seems to me that we have a "brand"
> > registry
> > >problem to solve.  Credit/Debit cards are sort of odd creatures because
> > they can
> > >be used in payments via multiple different protocols.  Most stored
> value
> > cards
> > >can be used via only a single protocol.
> > >
> > >SETco clearly operates a card brand regisgration operations, however
> > limited and
> > >even if it's only expressed in the brand level certificates that SETco
> > allows to
> > >be created under its root.  I think the hope was that the SET
> > registration
> > could
> > >be used in IOTP for all credit/debit cards.  This would at least avoid
> > the
> > >problem where some brand was registered under different names at
> > different
> > >registries (where "different" could just be things like whether there
> is
> > really
> > >a space between American and Express or whether the C is capitalized in
> > >Mastercard or whether Visa is all caps, ...).  Is there a list of bands
> > >officially supported by SETco and their official names?
> > >
> > >However, if SETco is inappropriate for this, because they won't
> > "register"
> > >brands that haven't joined", then we need a separate solution.  It
> > certainly
> > >isn't very difficult to set up regsitration via IANA, probably using
> the
> > same
> > >Designated Expert criteria being used for other things.  The only
> > difficulty I
> > >can see is that some brand might get registered there for IOTP use and
> > then
> > >later join SETco or otherwise get registered in some other system under
> > some
> > >other name.  Various messyness with Discover/Novus, AT&T Universal Card
> > changing
> > >to CitiBank Universal Card and the like occur to me.  I'm not sure
> those
> > cases
> > >are actually name change problems but one can image such.
> > >
> > >All this seems to imply that we need to be prepared to register
> > credit/debit
> > >card brands under "IOTP:".  I'm a bit reluctant to drop the "SET:"
> branch
> > of the
> > >brand tree in IOTP.  If some brand exists under SETco but hasn't yet
> been
> > >registered under IOTP, it seems like it should be usable.  Of course,
> > this
> > means
> > >that some brand registered under IOTP could later join SETco and could
> > exist as
> > >both IOTP:BrandX and SET:BrandX or SET:Brand-ex.  So you might get into
> > >equivalence tables but these are really just an artifact of the real
> > world
> > being
> > >messy and not particularly worse than brands splitting or merging.
> > >
> > >I don't see a major problem with us using
> > brand:[product]:[promotional-name] if
> > >we want, even after "SET:", although we should make it clear in that
> case
> > that
> > >these values differ from those permitted in the SET protocol.  The
> other
> > >possibility that occurs to me would be to use brand[:product] and have
> a
> > >separate [promotional=xxx] optional attribute.
> > >
> > >What do people think?
> > >
> > >Thanks,
> > >Donald
> > >
> > >Donald E. Eastlake, 3rd
> > >17 Skyline Drive, Hawthorne, NY 10532 USA
> > >[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
> > >
> > >home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
> > >[email-masked]   tel: 1-914-276-2668
> > >
> > >
> > >
> > >David Burdett <[email-masked]> on 04/29/99 12:17:01 PM
> > >
> > >To:   Ietf Trade WG <[email-masked]>
> > >cc:   "Lewis, Tony" <[email-masked]> (bcc: Donald
> > Eastlake/Hawthorne/IBM)
> > >Subject:  RE: Brand IDs & their registration. Was: RE: Comments on
> > draft-ie
> > >      tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > >
> > >
> > >
> > >
> > >
> > >I agree with Tony. Smart card based EMV transactions will be the
> dominant
> > >payment model within a decade, probably even earlier especially in the
> > >non-US part of the world. The main reasons being, in my view:
> > >*    it will reduce fraud as it's much much harder to copy a smart card
> > >than a mag stripe card
> > >*    it makes internet credit card payments "card present" transactions
> > >which should result in lower merchant fees. This also means that it
> will
> > be
> > >much harder for customers to claim they never made an internet purchase
> > >*    using a multi-application smart card you will be able to use just
> > >one smart card for debit, credit, electronic cash, a loyalty scheme as
> > well
> > >as hold electronic tickets for anything from local cinema to your next
> > >flight.
> > >
> > >To rephrase a MasterCard ad line, "smart cards are the future of
> money".
> > >
> > >David
> > >
> > >> ----------
> > >> From:   Lewis, Tony[SMTP:[email-masked]]
> > >> Sent:   28 April 1999 20:30
> > >> To:     Ietf Trade WG
> > >> Subject:     RE: Brand IDs & their registration. Was: RE: Comments on
> > >> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > >>
> > >> My point is that the brand is "Visa" no matter whether using IOTP,
> SET
> > or
> > >> any other protocol.
> > >>
> > >> As for EMV, the very first live SET 1.0 transaction was made using an
> > EMV
> > >> card with the EMV data carried inside a SET message extension. EMV
> > credit
> > >> and debit products are a significant part of the future of electronic
> > >> commerce. I expect they will be the dominant model for payment in a
> > >> decade.
> > >>
> > >> Tony
> > >> > ----------
> > >> > From:      Steve Fabes[SMTP:[email-masked]]
> > >> > Sent:      Wednesday, April 28, 1999 3:43 PM
> > >> > To:   Lewis, Tony; Ietf Trade WG
> > >> > Subject:   Re: Brand IDs & their registration. Was: RE: Comments on
> > >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > >> >
> > >> > Tony - do your comments infer that SET.Visa will be the only
> > e-Commerce
> > >> > product that an IOTP product supplier can expect to see. Can you
> see
> > a
> > >> day
> > >> > when a Visa EMV 3.1.1 (or 3.x.x) based credit product could also be
> > used
> > >> > inside an IOTP product?
> > >> > -----Original Message-----
> > >> > From: Lewis, Tony <[email-masked]>
> > >> > To: Ietf Trade WG <[email-masked]>
> > >> > Date: Wednesday, April 28, 1999 13:21
> > >> > Subject: RE: Brand IDs & their registration. Was: RE: Comments on
> > >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > >> >
> > >> >
> > >> > >David,
> > >> > >
> > >> > >I am new to this group and do not know what lead to the current
> > >> approach.
> > >> > >There are undoubtedly some issues that I don't know about.
> However,
> > it
> > >> > seems
> > >> > >to me that a brand is a brand no matter what payment protocol is
> > being
> > >> > used.
> > >> > >The only difference I see between "IOTP:Visa" and "SET:Visa" is
> that
> > >> the
> > >> > >latter indicates that the brand is supported by a specific payment
> > >> > protocol.
> > >> > >Since you need to support brands other than those supported by
> SET,
> > >> there
> > >> > >will need to be a registry. It seems to me that there should only
> be
> > >> one
> > >> > >such registry rather than the two being proposed. I recommend
> having
> > a
> > >> > >single domain for these brands. It seems reasonable to initially
> > >> populate
> > >> > it
> > >> > >using the brands registered with SET and those non-SET brands you
> > >> listed
> > >> > in
> > >> > >your note.
> > >> > >
> > >> > >Tony
> > >> > >> ----------
> > >> > >> From: David Burdett[SMTP:[email-masked]]
> > >> > >> Sent: Wednesday, April 28, 1999 11:36 AM
> > >> > >> To: Ietf Trade WG; Lewis, Tony
> > >> > >> Subject: Brand IDs & their registration. Was: RE: Comments on
> > >> > >> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > >> > >>
> > >> > >> In the current specification the basic idea for identifying
> brands
> > is
> > >> > that
> > >> > >> they should be of the form "xxx:brandid" where "xxx" can be
> "SET"
> > >> which
> > >> > >> indicates that the brandid is any valid brandid that is accepted
> > by
> > >> > SET,
> > >> > >> or
> > >> > >> alternatively "IOTP" which can be used to define any brand not
> > >> defined
> > >> > by
> > >> > >> SET. The idea was that we should not need to define "Visa",
> > >> > "MasterCard",
> > >> > >> "American Express", etc more than once since they are already
> > defined
> > >> > and
> > >> > >> registered by SET.
> > >> > >>
> > >> > >> However a couple of problems may arise ...
> > >> > >>
> > >> > >> USING THE SET BRAND ID FOR NON-SET PAYMENTS
> > >> > >> Although IOTP can support SET as a payment protocol, it can also
> > >> > support
> > >> > >> credit card payments (using Secure Channel Credit Debit - SCCD)
> > where
> > >> > the
> > >> > >> credit card information (no, name, expiration date, etc) is
> coded
> > >> > >> effectively in the clear but with privacy protection provided by
> > >> using
> > >> > a
> > >> > >> secure channel such as SSL. In this way it provides a similar
> > level
> > >> of
> > >> > >> privacy/security as for credit card payments that occur now
> where
> > a
> > >> web
> > >> > >> page
> > >> > >> form is completed by the user.
> > >> > >>
> > >> > >> My question is, will it be reasonable to use the SET brandid in
> > this
> > >> > way
> > >> > >> to
> > >> > >> cover non-SET credit card payments. I *think* the answer is
> "yes"
> > as
> > >> > you
> > >> > >> can
> > >> > >> quite imagine a situation where a consumer is offered a choice
> of
> > >> using
> > >> > >> their VISA credit card to pay using either SET or SCCD.
> > >> > >>
> > >> > >> WHAT BRAND ID SHOULD BE USED FOR CO BRANDS
> > >> > >> If a payment brand, such as a local brand or co-brand, chooses,
> > >> > initiall
> > >> > >> to
> > >> > >> use just SCCD rather than SET then they would not (I think) need
> > to
> > >> > >> register
> > >> > >> their brand with SET. In this case, they might register their
> > brand
> > >> as
> > >> > an
> > >> > >> "IOTP" brand. However if they later adopted SET, they would end
> up
> > >> with
> > >> > >> potentially two equivalent Brand IDs. Do you think we might be
> > better
> > >> > off
> > >> > >> with a straight IOTP brand and keep all the names under the
> > >> procedures
> > >> > >> defined by IANA? I'm not sure?
> > >> > >>
> > >> > >> REGISTERING NEW BRAND IDs
> > >> > >> To help assist in answering the last point, the following is
> what
> > I'm
> > >> > >> currently writing as the proposed IANA procedure for registering
> > new
> > >> > brand
> > >> > >> ids. Any comments:
> > >> > >>
> > >> > >> >>>Clip>>>
> > >> > >> The format of the Brand ID is either:
> > >> > >> * SET:setbrand where setbrand is a brand which is accepted by
> the
> > >> > >> [SET] payment protocol
> > >> > >> * IOTP:iotpbrand where iotpbrand may be:
> > >> > >> - GeldKarte
> > >> > >> - Mondex
> > >> > >>
> > >> > >> New values of the high level prefix (SET or IOTP) should be
> > allocated
> > >> > >> following review on the IETF Trade Working Group mailing list
> and
> > by
> > >> > the
> > >> > >> Designated Expert.
> > >> > >>
> > >> > >> Values of "setbrand" are allocated as defined in the [SET]
> > >> > specifications.
> > >> > >>
> > >> > >> New values of "iotpbrand" must be announced to the IETF Trade WG
> > >> > mailing
> > >> > >> list and, if there are no objections within three weeks, be
> > allocated
> > >> > on
> > >> > a
> > >> > >> "first come first served" basis.
> > >> > >> <<<End Clip<<<
> > >> > >>
> > >> > >> Regards
> > >> > >>
> > >> > >> David
> > >> > >> > ----------
> > >> > >> > From: Lewis, Tony[SMTP:[email-masked]]
> > >> > >> > Sent: 28 April 1999 08:14
> > >> > >> > To: Ietf Trade WG
> > >> > >> > Subject: RE: Comments on
> > >> draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> > >> > >> > part  1
> > >> > >> >
> > >> > >> > In SET, the BrandID is either "brand" or "brand:product".
> > >> > >> >
> > >> > >> > In Japan, there are products that are co-branded. Essentially
> > these
> > >> > >> > products
> > >> > >> > are private label cards for domestic transactions with an
> > >> > international
> > >> > >> > brand for non-domestic transactions. The private label can be
> > >> > reflected
> > >> > >> in
> > >> > >> > a
> > >> > >> > SET cardholder certificate as the "promotional card name"
> under
> > the
> > >> > >> > international brand's hierarchy and/or the cardholder can have
> a
> > >> > >> > certificate
> > >> > >> > issued under the private label hierarchy.
> > >> > >> >
> > >> > >> > There is no provision to carry both the private label (of the
> > >> > Japanese
> > >> > >> > credit card company) and the international brand as part of
> the
> > SET
> > >> > >> > BrandID.
> > >> > >> >
> > >> > >> > Tony
> > >
> > >
> > >-----------------------------------------------------------------------
> > >Message addressed to: [email-masked]
> > >Archive available at: http://www.elistx.com/archives/ietf-trade/
> > >To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > >body to: [email-masked]
> > >
> >
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> >
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 
> 
> 
> 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, Part  2 of 2
Date: Tue, 18 May 1999 02:17:13 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

See comments below marked with ### ...

David

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	05 May 1999 14:31
> To: 	IETF TRADE WG
> Subject: 	Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, Part
> 2 of 2
> 
> I've gone over the rest of the document and have the following
> suggestions:
> 
> 
> INQUIRY:
> 
> I'm not sure why inquiry is restricted as much as it is.  Seems like the
> thing
> to do is to describe the function it performs.  Then point out that the
> customer
> role is probably intermittantly connected and is not required to and is
> unlikely
> to respond to inquires even if it is connected.  And then perhaps, as
> guidance
> for the implementation of some sort of "Inquire" UI button at the customer
> site,
> suggest it inquire of the last role to which a message was sent or all
> roles.
> In particular, I see no reason not to allow server to server inquires.
### Agreed. Plan to change the section titled "WHICH TRADING ROLES CAN
RECEIVE INQUIRY REQUESTS" to ...

MAKING INQUIRIES OF ANOTHER TRADING ROLE
One Trading Role may make an inquiry of any other Trading Role at any point
in time. 
IOTP aware software that supports the Consumer Trading Role may not:
		*	digitally sign a response if requested, since it may
not have the capability, or
		*	respond to an Inquiry Request at all since it may
not be on-line, or may consider that the request is not reasonable since,
for example, the Request was not digitally signed.
As a guideline:
		*	the Consumer should send a Transaction Status
Inquiry Block to a Trading Role only after the following events have
occurred:
		*	to the Merchant, after sending TPO Selection Block,
		*	to the Payment Handler, after sending Payment
Request Block,
		*	to the Delivery Handler, after sending Delivery
Request Block,
		*	other Trading Roles should send a Transaction Status
Inquiry Block to the Consumer only after receiving a message from the
Consumer and before sending the final "Response" message to the Consumer
		*	there are no restrictions on non-Consumer Trading
Roles sending Inquiries to other trading roles.
##

> MISCELLANEOUS:
> 
> Section 7 first paragrah and figure: might be confusing to some readers.
> First
> paragraph says Trading Block has Trading Components and optionally
> Signature
> Component but figure only shows a Signature Component as part of a
> Signature
> Block... 
## Re-worded initial paragraphs as follows:
Trading Blocks are child elements of the top level IOTP Messages that are
sent in the form of [XML] documents directly between the different Trading
Roles that are taking part in a trade.

Each Trading Blocks consist of one or more Trading Components (see section
7). ##

>  Suggest that Trading Block components be labeled Trading Comp.##Agreed##
> except
> one labeled Siganture Comp.  Also, might note somehow that the Certificate
> Comp.
> is optional...## Also agreed ##
> 
> Section 7.9, OTP -> IOTP.
> Section 7.10, same.
##Agreed to both. There are still some instances of "otp" in element and
attribute names - see other email. ##

> Section 7.16, first sentence, suggest inserting "if required" after
> "Certificates".
##Agreed##

> Sections 7.16.1, .2, .3, &.4: suggest adding "With" to the subject titles
> or
> perhaps even "Signature Block With".
## Agreed. Also added new section 7.16.5 titled "Signature Block with
Delivery Response" as it is missing. It is very similar to section 7.16.3##

> Section 8.2.2: I'm not sure that a flat statement that a PING does not
> start an
> IOTP aware 'application' is necessarily correct.  This could be
> implemented in
> different ways.  In any case, it seems to be contradicated by the
> immediately
> following sentence.  Perhaps there should just be some words about it
> being
> intended to test connectivity and basic listening / reponse functions and
> need
> not start a full blown IOTP application or do any deep tests, or words to
> that
> effect.
## Agreed ##

> Section 10:
>      In URLs, "ftp:" should be followed by "//".
##Done##
>      merchant.com is a real highly active web site. Suggest occurances of
> it be
> replaced by "example.com" which is actually resreved for this purpose.
> Another
> possibility is using the ".example" top level domain name which is also
> reserved
> for use in examples.
##Done##
>      suggest at least one BrandLogoNetLocn per example be an "http://" URL
> to
> show that it need not always be ftp.
##Done##
>      BrandIDs do not correspond to text elsewhere about Brands...
##Fixed##
>      In 10.2 example, closes of <PackagedContent ...> sometimes are
> missing the
> "/" right after the "<" and in some cases have attributes...
##Fixed##
>      In 10.4, CyberCash is the company, which offers a number of services,
> including CyberCoin.  Most references seem to be to CyberCoin.  ccash.com
> is yet
> another different real (French language) site.  Suggest ccash.example or
> cybercash.com.  (mxbankuk.com doesn't exist yet but who knows...)
## Fixed##

> TRIVIA:
> 
> Section 7.7, Content, Status, last sentence "of" -> "if"
> Section 7.10, same.
##Both fixed##

> Section 8.1.12, figure 33, "TPO Block only i last ..." -> "TPO Block only
> if
> last..."
##Fixed##

> Section 8.2.1, "inquiring on transaction" -> "inquiring about a
> transaction"
>      "component hold the" -> "component holds the"
>      "contain for encapsulated" -> "contain encapsulated"
##Fixed##

> Section 9: suggest lower casing the upper case occurances of "GIF".
##Fixed##

> DTD:
>      I didn't review the DTD in detail.
> 
> 
> GLOSSARY:
> 
> Delivery Handler: suggest dropping the word "physically".  Maybe
> substitute
> "directly"?
##Agreed##

> IOTP Transaction: "of IOTP" -> "of the IOTP"
##Fixed##

> Payment Instrument: CybeCash -> CyberCoin or CyberCash's CyberCoin
> ##Fixed##
> 
> Promotional Brand:  I don't think use here and in Section 10 doesn't
> correspond
> with text elsewhere about brands.
##Deleted examples##

> Transaction Type: last item of bulleted list doesn't read like it should
> be a
> list member.
##Renamed Transaction Type as IOTP Transaction Type and moved to earlier in
the glossary. It now seems to make sense.##

> Thanks,
> Donald
> 
> Donald E. Eastlake, 3rd
> 17 Skyline Drive, Hawthorne, NY 10532 USA
> [email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
> 
> home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
> [email-masked]   tel: 1-914-276-2668
> 
> 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>,  Don Eastlake <[email-masked]>
Subject: RE: Links in HTML data 
Date: Tue, 18 May 1999 02:16:59 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

OK ... Don's convinced me ! You can point back to the "Main" page. After all
we can't completely control what people do anyway.

David

> ----------
> From: 	Donald E. Eastlake 3rd[SMTP:[email-masked]]
> Sent: 	05 May 1999 05:18
> To: 	Ietf Trade WG
> Subject: 	Re: Links in HTML data 
> 
> 
> This whole area seems to be more painful that you would think at
> first.
> 
> My comment was because there seemed to me to be no problem with
> circular links, etc., as long as everything pointed to was included.
> Thus, if the Main page points to pages A and B, I don't see it as a
> problem, as long as Main, A, & B are all included in the message, if
> page A links to page B and/or page B links to page A and/or either A
> or B link to Main.  Mainy web sites have a "return to mail page
> button" and as long as both the subsidiary and main pages are included
> in the probably signed message, what is the problem?
> 
> Part of the reason for allowing links was so that images and sounds,
> etc., could be included as long as the data is also in the message and
> so can't be changed.  As long as the message is self contained and
> there is an appropriate user interface, this seems like an
> advantage. At least, as David point out below, people are likely to do
> it no matter what we say :-)
> 
> Anyway, I continue to believe there is no problem with pointers in
> subsidiary HTML pages that are included in the message having links
> back to the main page.
> 
> Thanks,
> Donald
> 
> 
> From:  David Burdett <[email-masked]>
> Message-Id:  <[email-masked]>
> To:  Ietf Trade WG <[email-masked]>
> Date:  Thu, 29 Apr 1999 17:17:04 +0100
> 
> >I think I better add some clarification on this topic.
> >
> >Initially, the IOTP specs said that order descriptions, payment notes,
> etc,
> >should be simple "plain text" to ensure interoperability and help avoid
> the
> >problems that Hannu, Donn and Eric have described. It was then realised
> that
> >both pilot implementations based on the v 0.9 spec used HTML and/or XML
> and
> >not "plain text".
> >
> >Conclusion: People don't want to use plain text therefore we better
> include
> >a method of handling HTML or XML in the specification. If we don't then
> >people will use HTML/XML anyway and pretty well all implementations will
> be
> >non-conformant !!
> >
> >Exactly what the specification currently says is attached below but
> >essentially it is designed to avoid the problems that have been raised.
> >Don's comment was the sentence at the end of the second bullet point
> which
> >says:
> >
> >	"... the "Main" Packaged Content element must not be referred to
> >from the HTML in any other Packaged Content"
> >
> >The general idea is that packaged HTML should really appear to the user
> as a
> >simple single or multi page document, much like users would receive in
> the
> >real world, where *everything* required to generate the document is
> included
> >as packaged content in the Order Description. It therefore doesn't really
> >make sense, in my view, to be able to follow a link that takes you to the
> >"Main" packaged content from elsewhere.
> >
> >On the other hand you don't want to ban links entirely for example you
> might
> >want to include in the HTML buttons which say "click here for customer
> care"
> >which could take you to a web page where you could report problems. This
> >could make sense. However another a link which dynamically downloaded
> over
> >the web a GIF of your order description would not since the GIF could be
> >changed after the event. IMOH though I don't think this type of behaviour
> by
> >merchants will be particularly widespread. Thoughts anyone on this topic?
> >
> >David
> >
> >======= Extract from the v 03 spec ========
> >  3.8.1 Packaging HTML
> >
> >  The packaged content may contain HTML. In this case the following
> >  conventions are followed:
> >
> >  o references to any documents, images or other things, such as
> >    sounds or web pages, which can affect the recipient's
> >    understanding of the data which is being packaged must refer to
> >    other Packaged Elements contained within the same parent
> >    element, e.g. an Order Description
> >
> >  o if more than one Packaged Content element is included within a
> >    parent element in order to meet the previous requirement, then
> >    the Name attribute of the top level Packaged Content from which
> >    references to all other Packaged Elements can be determined,
> >    should have a value of Main. This means that the "Main"
> >    Packaged Content element must not be referred to from the HTML
> >    in any other Packaged Content
> >
> >  o relative references to other documents, images, etc. from one
> >    Packaged Content element to another are realised by setting the
> >    value of the relative reference to the Name attribute of
> >    another Packaged Content element at the same level and within
> >    the same parent element
> >
> >  o no external references that require the reference to be
> >    resolved immediately should be used. As this could make the
> >    HTML difficult or impossible to display completely
> >
> >  o [MIME] is used to encapsulate the data inside each Packaged
> >    Element. This means that the information in the MIME header
> >    used to identify the type of data which has been encapsulated
> >    and therefore how it should be displayed.
> >
> >  If the above conventions are not followed by, for example, including
> >  external references which must be resolved, then the recipient of the
> >  HTML should be informed.
> >
> >  [Note]   As an implementation guideline the values of the Name
> >           Attributes allocated to Packaged Content elements should
> >           make it possible to extract each Packaged Content into a
> >           directory and then display the HTML directly
> >  [Note End]             
> >
> >
> >> ----------
> >> From: 	Hannu Nikkanen[SMTP:[email-masked]]
> >> Sent: 	29 April 1999 01:05
> >> To: 	Ietf Trade WG
> >> Subject: 	Re: Links in HTML data
> >> 
> >> Hi,
> >> 
> >> I believe that "what you see is what you sign" would be a better
> approach.
> >> 
> >> In principle, graphics could be used to insert logos of other companies
> or
> >> some text, which the signer could not distinguish from the signed part.
> >> 
> >> Even if the risk is low, it may lower consumer trust, which probably is
> >> one
> >> of the main commercial goals. 
> >> 
> >> Hannu
> >> 
> >> At 22:45 28.4.1999 +0100, you wrote:
> >> >Don Eastlake says in his email:
> >> >
> >> >	"Section 3.8.1: I don't understand why sub-pages of an HTML main
> >> >page couldn't have links back to the main page."
> >> >
> >> >In IOTP, where HTML is being used to describe a document such as an
> order
> >> >description or a payment note, then it is, in many ways being provided
> as
> >> an
> >> >alternative to a single, or multi-page "real world" document. These
> >> >documents should not in general be :"multi-media" documents, since for
> >> >purposes of non-refutability, the document should be self-contained
> and
> >> not
> >> >reliant on other records held elsewhere. For this reason links should
> >> only
> >> >be used to allow, for example, graphics and other display devices to
> be
> >> >included in the document.
> >> >
> >> >Therefore in my opinion, this should not be allowed. What do other
> people
> >> >think?
> >> >
> >> >David
> >> >> mailto:<[email-masked]>
> >> >> Mondex International, US Advanced Technology Office
> >> >> 111 Pine St, 6th Floor, San Francisco, CA 94111
> >> >> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: "Seidl, Roland A" <[email-masked]>
Cc: Ietf Trade WG <[email-masked]>
Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt
Date: Mon, 17 May 1999 20:06:22 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Seidl

Apologies for the delay in getting back to you but I was at CardTech
SecurTech in Chicago all last week. Answers to your questions are included
below, marked with a ##.

I've also copied this reply to the Trade WG.

David

> ----------
> From: 	Seidl, Roland A[SMTP:[email-masked]]
> Sent: 	05 May 1999 19:26
> To: 	'SMTP:[email-masked]'
> Subject: 	Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt
> 
> I am just starting to look at this draft and there are a number of
> comments
> I would like to offer.
> 
> 1) Fig. 3 has three Signature(offer) components, one in the Consumer side
> (step 5),
>     one in the Merchant side (step 4), and a third in the Payment Handler
> (step 7).
> 
> This is confusing. The text refers to an "Offer Response Signature" -
> there is no such
> labelled component in the diagram. [This refers to the Signature(Offer) of
> the
> Merchant???]. In step 7, the Signature(offer) is presumably a copy of the
> Consumer
> Signatuer(Offer).
> 
> I suggest that unless these signatures are copies which are passed from
> one
> message to the next they should have distinct labels in the diagram
## The the "Offer" signature in the diagram has been relabeled "Offer
Response". They are all copies of the original created by the Merchant.##

> 2) Similar comment for fig. 4
##Changed in similar way to above.##

> 3) Figure 8 has errors. There is a missing 2 from TransID comp., should be
> M1.2.
>  The second 'Trading block' should have identifiers M1.9 through M1.13,
> which are
> distinct from those of the first 'Trading block'.
## Both fixed##

> Similarly for fig. 9
## Also fixed##

> 4) TPO Block is mentioned in 3.11.1, 4.4.2.9, Fig. 13, 6.1, 6.16, 6.17.2
> and 6.17.5
> before TPO Trading Block is defined in 7.1. There should be a forward
> reference to
> section 7.1 at least in the first occurrence of TPO blokc in 3.11.1
## Forward references added ##

> 5) Page 71 'Cancelling a complete should' -- this should read
>      'Cancelling a complete transaction should'
## Corrected ##

> 6) Section 3.11.1 mentions SenderNetLocn, SecureSenderNetLocn,
> CancelNetLocn.
> Could these and other similar references be collected in an appendix which
> indicates
> the role associated with these 'Net' locations and the purpose assigned to
> each.
## Included forward reference to ProtocolOptionsComponent which describes
what these attributes are used for.##

> 7) Figure 10. is so cluttered (the fault of having to use a 'text' based
> diagram) that it
> is difficult to comprehend. This could be alleviated by splitting the
> diagram, so that
> there are seperate portioins for each of the 'Type of Block' paths (or
> possibly
> split into pairs).
## Sounds like a good idea ... do you want to have a go at doing a revised
diagram ? ##

> I am not convinced that the diagram logic 6a -> 6b -> 6d -> 6e is correct!
> Surely it should be 6a -> 6b -> 6d -> 6c.
> 
> Why is 'Processing of Block Complete' checked after 'Request Received
> Before'?
> Surely you need to wait for block processing to be completed before
> checking to
> see if the request has been received previously? If it is NOT necessary to
> wait for
> block processing completion to determine if a request has been received
> previously
> the why not truncate processing and go straight to step 6c
## I see your point. Hopefully the revised diagram below answers your
question ? (View in a fixed font)
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

                            -------------
                           |    Input    |
                           | IOTP Message|
                            -------------
                                  |
                                  v
                           1. Check for transport -------------->
                           or message level errors   Errors      |
                                      |OK                        |
                                      v                          |
   11. Generate output <-------2. More Blocks <----------------- + -
         message               No    to process?                 |  |
            |                        |Yes                        |  |
            v                         v                          |  |
      -------------           3. Check Block OK ---------------> |  |
     |    Output   |                 |               Errors      |  |
     | IOTP Message|                 |Checks OK                  |  |
      -------------                  v                           |  |
                    ---------4. Type of  Block ? -------         |  |
                   |           |           |            |        |  |
      ---------Status       Action   Encapsulating     Error     |  |
     |         Request      Request      Block         Block     |  |
     |                         |           |             |       |  |
     |                         v           v             v       |  |
     |                 6a. Action     7. Process     8.Error     |  |
     |                  Request -    encapsulated     Block ?    |  |
     |                  received      message and       |        |  |
     |                   before?--     generate --      v        |  |
     |                   |        |     response   |   STOP   ---   |
     |                   |Yes     |No        OK|   |         |      |
     |                   v        v            |   |Errors   v      |
     |       6b. Processing 6e. Process Action |   ------> 9. Gen   |
     |          of Block    Request & generate-+--------->Error     |
     |        Complete ?-     response block-  | Errors   Block &   |
     |           |       |                   | |           store    |
     |           |       |                   | |            |       |
     |           |Yes    |No           Ok or | |            |       |
     |           |        ---        Warning |  --------    |       |
     v           v           v               v          |   |       |
5. Generate  6c. Retrieve  6d. Do nothing 6f. Store     |   |       |
   Status     and resend    as earlier    request &     |   |       |
  Response     previous    request will   response      |   |       |
   Block        Block    provide response   block       |   |       |
     |            |                           |         v   v       |
      ---------------------------------------------- 10. Add block--
                                                     to output
                                                     message

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
##

> 8) Figure 11. Output from block 7. [OK] doesn't obviously go anywhere
> [This is a
> problem of splitting diagram across page]. There are 7 lines exiting
> bottom of page,
> but only 6 entering top of next. I assume that 6b[OK] -> 6c. Now does 7 ->
> 10 as for
> figure 10. or as the text implies 7 -> 6d (presumably via 6c). There also
> appears to
> be a missing link from block 10 back to 2. This diagram would also be
> improved
> by splitting it in someway (as for fig 10)
## Points noted. The original diagram had some miss-aligned characters. This
has now been fixed (see new diagram below). Also do you want to have a go at
a new version of this diagram as well?##
## Corrected diagram ...
*+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*+*+**+*+*+*+*+*+*+*+*+*+*

                            -------------
                           |    Input    |
                           | IOTP Message|
                            -------------
                                  |
                                  v
                           1. Check for transport -->
                           or message level errors   |Errors
                                      |OK            |
                                      v              |
11.Blocks to be sent?<---------2. More Blocks <----------------------
             |    |No       No    to process?       |                ^
          Yes|    v                   |Yes          |                |
             v   STOP                 v             |                |
      12. Generate            3. Check Block OK --->|                |
     output message                  |              |Errors          |
          |                          |Checks OK     |                |
          v                          v              |                |
    -------------   ------  4. Type of  Block ? ----|                |
   |    Output   | |        |    |           |      |                | 
   | IOTP Message| |    ----     |           |      |                |
    -------------  |   |         |           |      |                |
       ------------    |         |           |      |                |
      |              --          |           |      |                |
      v             v            v           v      |                |
    Status       Action    Encapsulating  Error     |                |
   Request      Response       Block      Block     |                |
     |             |             |          |       |                |
     |             v             v          v       |                |
     |       6a. Action   7. Process 8a.Error Block---- > Transient  |
     |        Response  encapsulated     severity ? |       Error    |
     |        received     message      |Hard Error |      (retry)   |
     |        before ?         |  |         |       |         |      |
     |       Yes|   |No      Ok|  |         v       |       WAIT     |
     |      (Ig-|   |          |  |       STOP      |         |      |
     |      nore|)  v          |  |                 v         v      |
     |          | 6b. Process  |   -------> 9. Generate      8b.     |
     |          |    Action    |  Errors    Error Block    Retrieve  |
     |          |   Response --+---------->  & store      and resend |
     |          |     Block    |  Errors          |        previous  |
     |          |       |Ok    |                  |        Block(s)  |
     |          |       v      v                  |          |       |
     |          |         6c. New                 |          |       |
     |          |         request                 |          |       |
     |          |        required?                |          |       |
     |          |     No|    |Yes  6d. Generate   |          |       |
     |          |       |     ----> Request       |          |       |
     |          |       |          Block & Store  v          v       |
     v          |       |              |           10. Add Block to  |
      ----------+-------+------------------------>  output message ->|
                v       v                                            |
                 --------------------------------------------------->

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

> I notice from the archives that in response to one e-mail concerning the
> diagrams,
> you made mention of a 'Word' version, and the problems of conversion
> between
> these and a text format. I suggest the publication of a link to the 'Word'
> document
> might be extremely useful for people trying to read the text draft.
## Nice idea but, the "text" version is now the "master". It is also a lot
of work to keep two sets of diagrams in step. If someone wants to volunteer
to do "pretty" diagrams, I'll send them a word version of the text spec
(complete with text diagrams) so that they can provide an alternative
version.##

> That's as far as I've gotten so far. I hope these comments are of some
> use. I will
> forward any others (if there are any) after I have progressed further
> throught the
> document
## Thanks##

> Regards
> Roland SEIDL
> Telstra Research
> Phone: + 61 3 9253 6161
> Fax:      +61 3 9253 6485
> [email-masked]
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Lewis, Tony" <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: Question for IOTP Authentication
Date: Wed, 12 May 1999 23:04:00 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Sorry for the delayed response. I've been pretty much in non-stop meetings
since your message arrived.

We haven't specified the user interface for merchant authentication so this
is my personal vision; others from SETCo might offer a different perspective
on the UI. I'm expecting that merchants will eventually have a logo
available either on their home page or very early in the browsing
experience. Cardholders will come to recognize the logo as one that
indicates that the merchant can be authenticated. When the cardholder clicks
on the logo, a dialogue will begin with the wallet. At the conclusion of the
dialogue, the wallet will announce to the cardholder either that the
merchant has been authenticated or that it has not.

The benefit to cardholders is that they will be able to authenticate a
merchant before disclosing identifying information (name, address, etc.) or
personal information (dress size, medical condition, etc.).

The benefit to merchants is that cardholders will be more likely to do
business with a merchant that a financial institution certifies as having an
ongoing relationship.

Drilling down to the technical details, I envision a solution where the
financial institution creates a daily "I still trust this merchant" message
that will be included as part of the "Authenticate me" dialogue. This is an
improvement over a signed message from the merchant because it confirms an
ongoing relationship. (If SET had a merchant CRL, the signed message plus a
CRL check would serve the same purpose.)

In our SET pilots, cardholders have liked the fact that the merchant is
authenticated during the purchase phase, but have asked for that
authentication to occur earlier in the shopping experience.

Tony
> ----------
> From: 	David Burdett[SMTP:[email-masked]]
> Sent: 	Wednesday, May 05, 1999 12:10 PM
> To: 	Ietf Trade WG; Lewis, Tony
> Subject: 	RE: Question for IOTP Authentication
> 
> Tony
> 
> Thanks for the clarification, however, the SET  "authenticate me" is new
> to
> me so I'd appreciate your clarification on a couple of things so that I
> can
> see where it's coming from:
> 
> *	have you thought about what a user would do to authenticate a
> merchant if they don't want to pay using SET?
> *	what benefits, in business terms, would a user get from doing an SET
> "authenticate me" rather than some other form of merchant authentication,
> e.g. a straightforward IOTP authentication which returned a digital
> signature that carried specific assertions?
> 
> David
> 
> 
> > ----------
> > From: 	Lewis, Tony[SMTP:[email-masked]]
> > Sent: 	04 May 1999 08:20
> > To: 	ietf-trade
> > Subject: 	RE: Question for IOTP Authentication
> > 
> > David,
> > 
> > I'm replying to the list since the answer to your off-list question to
> me
> > is
> > likely to be of general interest.
> > 
> > We are looking for a way to support an "Authenticate Me" button on a
> > merchant web site. When this button is clicked, it will invoke the SET
> > wallet, which will validate the merchant certificate, the payment
> gateway
> > certificate and a special signed message. If the validation is
> successful,
> > the wallet will then display a message indicating that this is a valid
> SET
> > merchant.
> > 
> > The flow would be something like this:
> > 
> > Click: "Authenticate Me"
> > 
> > <--- Authentication Wake up
> > ---> PInitReq
> > <--- PInitRes
> > 
> > Wallet: "This is a valid SET merchant."
> > 
> > 
> > I'm suggesting that IOTP can be used for the wake up if we treat this as
> a
> > "null" payment (one where the payment phase is elided).
> > 
> > By the way, "BAG" is the "SETCo Business Advisors Group", which will
> hold
> > its first meeting next week.
> > 
> > Tony
> > > ----------
> > > From: 	David Burdett[SMTP:[email-masked]]
> > > Sent: 	Monday, May 03, 1999 3:00 PM
> > > To: 	Lewis, Tony
> > > Subject: 	RE: Question for IOTP Authentication
> > > 
> > > Tony
> > > 
> > > I don't quite understand what Yoshiaki is talking about in his email.
> > When
> > > he refers to the BAG requirement, what does he mean? I also don't
> quite
> > > understand how a "null" payment could be used as part of the solution
> as
> > > you
> > > describe.
> > > 
> > > It's just that I'm trying to understand the requirement so that I can
> > see
> > > how IOTP could meet the need.
> > > 
> > > Clarification will be greatly appreciated.
> > > 
> > > David
> > > 
> > > 
> > > 
> > > > ----------
> > > > From: 	Lewis, Tony[SMTP:[email-masked]]
> > > > Sent: 	03 May 1999 11:50
> > > > To: 	[email-masked]
> > > > Subject: 	RE: Question for IOTP Authentication
> > > > 
> > > > Yes, this authentication is performed prior to the shopping phase,
> but
> > > > can't
> > > > it be processed as a null payment and use both IOTP and SET
> > > authentication
> > > > mechanisms?
> > > > 
> > > > Tony
> > > > > ----------
> > > > > From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> > > > > Sent: 	Sunday, May 02, 1999 8:19 AM
> > > > > To: 	[email-masked]
> > > > > Cc: 	Lewis, Tony; [email-masked];
> > > > [email-masked]
> > > > > Subject: 	RE: Question for IOTP Authentication
> > > > > 
> > > > > Tony mentioned to me the Mercahnt authentication has to do prior
> to
> > > > > shopping phase, this is out of IOTP. So we can use separete
> > > > > authentication only.
> > > > > 
> > > > > We need to define the SET Specific authentication, which
> > > > > satisfy the requirement to the BAG Requirement, in SETCo.  because
> > > > > consumer have to confirm whether Merchant is authorized by the
> > > > > Acquirer and this requirement is payment dependent(IOTP is the
> > payment
> > > > > scheme independent messaging protocol).
> > > > > 
> > > > > I believe that the merit of using IOTP authentication is that we
> > > > > can be concerned IOTP Authentication transaction with IOTP
> > > > > Purchase transaction.
> > > > > 
> > > > > --
> > > > > Yoshiaki Kawatsura Hitachi, Ltd.
> > > > > 
> > > > > 
> > > > > 
> > > > > >>>>> Fri, 30 Apr 1999 20:04:11 +0100,
> > > > > 	David Burdett <[email-masked]> said:
> > > > > 
> > > > > > Tony
> > > > > > 
> > > > > > I can think of three ways that IOTP might be able to meet the
> > > > > requirement
> > > > > > you describe:
> > > > > > *	using the Packaged Content element in the Pay Protocol
> > > element (see
> > > > > > section 6.6.4),
> > > > > > *	the Consumer authenticates the Merchant separately using an
> > > > > > authentication transaction, or 
> > > > > > *	a combination of the two.
> > > > > > 
> > > > > > Each is discussed in a bit more detail below.
> > > > > > 
> > > > > > PAY PROTOCOL ELEMENT
> > > > > > This involves the merchant including the relevent certificate
> and
> > > > > message
> > > > > > from the acquirer in the PackagedContent element in the Pay
> > Protocol
> > > > > element
> > > > > > for SET of the Brand List (see spec section  6.6.4), then if the
> > > > > Consumer
> > > > > > wants to use SET for a payment they just pass the data to the
> SET
> > > > > payment
> > > > > > software working within IOTP which then checks the credentials.
> > > > > > 
> > > > > > The advantage of this approach is that the certificate will
> always
> > > be
> > > > > there
> > > > > > and no extra messages will be required to retrieve it. The
> > > > disadvantage
> > > > > is
> > > > > > that it increases the size of the messages.
> > > > > > 
> > > > > > SEPARATE CONSUMER AUTHENTICATION OF THE MERCHANT
> > > > > > In this case, the SET software recognises that there a
> certificate
> > > and
> > > > > > message from the acquirer is needed and makes a request to the
> > IOTP
> > > > > software
> > > > > > to obtain it. When this need occurs, a separate IOTP
> > Authentication
> > > > > > Transaction (see spec section 8.1.6) is used to get the
> > information.
> > > 
> > > > > > 
> > > > > > This would involve:
> > > > > > *	the Consumer sending an IOTPAuthentication Request message
> > > to the
> > > > > > merchant specifying in the Algorithm element that the Merchant
> > > should
> > > > > do,
> > > > > > for example, a SET merchant authentication, then
> > > > > > *	the Merchant replying with a Authentication Response message
> > > > > > including the necessary certificate and acquirer message in the
> > > > Packaged
> > > > > > Content.
> > > > > > 
> > > > > > COMBINATION
> > > > > > An alternative might be to include some fingerprint of the
> > > > > > certificate/message in the PayProtocol element, so that the
> > consumer
> > > > SET
> > > > > > software can check if it already has a copy of it. If it hasn't
> > then
> > > a
> > > > > > separate consumer initiated IOTP Athentication of the merchant
> > could
> > > > be
> > > > > used
> > > > > > to obtain it.
> > > > > > 
> > > > > > Does this make sense?
> > > > > > 
> > > > > > David
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > ----------
> > > > > > > From: 	Lewis, Tony[SMTP:[email-masked]]
> > > > > > > Sent: 	29 April 1999 17:36
> > > > > > > To: 	Yoshiaki KAWATSURA
> > > > > > > Cc: 	Ietf Trade WG
> > > > > > > Subject: 	RE: Question for IOTP Authentication
> > > > > > > 
> > > > > > > David,
> > > > > > > 
> > > > > > > I believe this proposal originates from requirements that
> SETCo
> > > has
> > > > > > > defined
> > > > > > > for SET 2.0 although when we discussed the approach outlined
> by
> > > > > Yoshiaki
> > > > > > > at
> > > > > > > our meeting last week, we recommended some changes.
> > > > > > > 
> > > > > > > I believe what we will need is the ability for the merchant to
> > > push
> > > > > some
> > > > > > > data (certificates and a signed message from the acquirer) to
> > the
> > > > > > > cardholder
> > > > > > > wallet who will use that data to authenticate the merchant. If
> > > that
> > > > > can be
> > > > > > > accomplished with the existing authentication transaction then
> I
> > > > > believe
> > > > > > > your change will satisfy our needs.
> > > > > > > 
> > > > > > > However, there may be other issues behind the input from
> Hitachi
> > > so
> > > > > > > Yoshiaki
> > > > > > > should also respond.
> > > > > > > 
> > > > > > > Tony
> > > > > > > > ----------
> > > > > > > > From: 	David Burdett[SMTP:[email-masked]]
> > > > > > > > Sent: 	Thursday, April 29, 1999 4:00 PM
> > > > > > > > To: 	Yoshiaki KAWATSURA
> > > > > > > > Cc: 	Ietf Trade WG
> > > > > > > > Subject: 	RE: Question for IOTP Authentication
> > > > > > > > 
> > > > > > > > Yoshiaki
> > > > > > > > 
> > > > > > > > As you can see I'm catching up on all the Trade WG emails
> and
> > > have
> > > > > > > thought
> > > > > > > > about your suggestion. In principle I can see why allowing a
> > > > > Consumer to
> > > > > > > > authenticate a Merchant is reasonable as, in the current
> > version
> > > > of
> > > > > the
> > > > > > > > specification, it states that a Conumer can authenticate a
> > > Payment
> > > > > > > Handler
> > > > > > > > or a Delivery Handler (see section 8.1.13 second bullet
> point)
> > > and
> > > > > > > > therefore
> > > > > > > > it is logical that a Consumer should also be able to
> > > authenticate
> > > > a
> > > > > > > > Merchant.
> > > > > > > > 
> > > > > > > > However the method you suggest below for authenticating a
> > > Merchant
> > > > > is
> > > > > > > > different from the way the Consumer authenticates a Payment
> > > > Handler
> > > > > or
> > > > > > > > Delivery Handler in that it is integrated into the
> transaction
> > > > (e.g
> > > > > a
> > > > > > > > purchase) which implies a further variation on the message
> > flow.
> > > > So,
> > > > > I
> > > > > > > > suggest that we meet your requirement by simply changing the
> > > first
> > > > > > > bullet
> > > > > > > > point in section 8.1.13 to read the authentication
> transaction
> > > can
> > > > > be
> > > > > > > used
> > > > > > > > ... " by a Consumer to authenticate a *Merchant*, Payment
> > > Handler
> > > > or
> > > > > a
> > > > > > > > Delivery Handler ..."
> > > > > > > > 
> > > > > > > > Is this OK?
> > > > > > > > 
> > > > > > > > David
> > > > > > > > 		
> > > > > > > > 
> > > > > > > > > ----------
> > > > > > > > > From: 	Yoshiaki
> KAWATSURA[SMTP:[email-masked]]
> > > > > > > > > Sent: 	29 March 1999 22:45
> > > > > > > > > To: 	[email-masked]
> > > > > > > > > Cc: 	[email-masked]; [email-masked];
> > > > > > > > [email-masked];
> > > > > > > > > [email-masked]
> > > > > > > > > Subject: 	RE: Question for IOTP Authentication
> > > > > > > > > 
> > > > > > > > > David,
> > > > > > > > > I agree with your suggestion.
> > > > > > > > > But I also want to add the Merchant Authenticaton by
> > Consumer 
> > > > > > > > > prior to IOTP Purchase Transaction.
> > > > > > > > > 
> > > > > > > > > These are the same flow as follows,
> > > > > > > > > 
> > > > > > > > > Consumer             Merchant
> > > > > > > > >    <-------------------
> > > > > > > > >          TPO
> > > > > > > > > 
> > > > > > > > >    ------------------->
> > > > > > > > >       Auth Req
> > > > > > > > > 
> > > > > > > > >    <------------------
> > > > > > > > >       Auth Res
> > > > > > > > > 
> > > > > > > > > and Status Block is not sent to the Merchant.
> > > > > > > > > 
> > > > > > > > > After Consumer receives the Auth Response,
> > > > > > > > > 1. If prior to IOTP purchase transaction
> > > > > > > > > Success: Consumer sends the message to the Success
> > > NetLocation.
> > > > > > > > > Fail: Stop
> > > > > > > > > 
> > > > > > > > > 2. If in the IOTP Purchase Transaction
> > > > > > > > > Success: Continue the transaction
> > > > > > > > > Fail: Stop.
> > > > > > > > > 
> > > > > > > > > Make sense?
> > > > > > > > > 
> > > > > > > > > This is minor change and I think there is no affect in the
> > > IOTP
> > > > > > > > protocol.
> > > > > > > > > Regards,
> > > > > > > > > ----
> > > > > > > > > Yoshiaki Kawatsura : E-mail [email-masked]
> > > > > > > > >  Business & Information Systems Development Devision,
> > > > Hitachi,Ltd.
> > > > > > > > > Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > >  >>>>> Fri, 26 Mar 1999 18:20:48 -0000,
> > > > > > > > > 	 David Burdett <[email-masked]> said:
> > > > > > > > > 
> > > > > > > > >  >Yoshiaki
> > > > > > > > >  >
> > > > > > > > >  >The current version of IOTP does not support
> > authentication
> > > of
> > > > > the
> > > > > > > > > Merchant
> > > > > > > > >  >by the Consumer. Part of the reasoning behind this is
> that
> > > the
> > > > > > > > Merchant
> > > > > > > > > will
> > > > > > > > >  >include a signature in the offer which can be used for
> > this
> > > > > purpose.
> > > > > > > > >  >HOwever, as you say, the consumer might not want to give
> > > > address
> > > > > > > > > information
> > > > > > > > >  >until they have authenticated the Merchant.
> > > > > > > > >  >
> > > > > > > > >  >You could actually do this although section 8.1.13 does
> > not
> > > > > > > > specifically
> > > > > > > > >  >state this. What would be requried is that, after the
> > > Consumer
> > > > > has
> > > > > > > > > received
> > > > > > > > >  >the TPO, he authenticates the merchant with a separate
> > > > > > > Authentication
> > > > > > > > >  >transaction and then if its  OK continues with the
> > original
> > > > > > > > transaction.
> > > > > > > > >  >
> > > > > > > > >  >Would this make sense? If you think it does then please
> > post
> > > > the
> > > > > > > idea
> > > > > > > > to
> > > > > > > > > the
> > > > > > > > >  >list. I don't know though if we want to include this in
> > v1.0
> > > > > > > although
> > > > > > > > it
> > > > > > > > >  >could easily go into v 2.0
> > > > > > > > >  >
> > > > > > > > >  >David
> > > > > > > > >  >
> > > > > > > > >  >> ----------
> > > > > > > > >  >> From: 	Yoshiaki
> > > KAWATSURA[SMTP:[email-masked]]
> > > > > > > > >  >> Sent: 	25 March 1999 22:46
> > > > > > > > >  >> To: 	[email-masked]; [email-masked];
> > > > > > > > > [email-masked]
> > > > > > > > >  >> Cc: 	[email-masked]
> > > > > > > > >  >> Subject: 	Question for IOTP Authentication
> > > > > > > > >  >> 
> > > > > > > > >  >> Don and David,
> > > > > > > > >  >> I have a couple of question for IOTP Authentication.
> > > > > > > > >  >> 
> > > > > > > > >  >> Consumer wants to send private information such as
> home
> > > > > address to
> > > > > > > > >  >> authenticated merchants only for Offer. In fact, SET
> is
> > > > > attempting
> > > > > > > > to
> > > > > > > > >  >> support simliar functionality. I believe that IOTP
> > should
> > > > > support
> > > > > > > > > this.
> > > > > > > > >  >> 
> > > > > > > > >  >> IOTP version 1.0 cannot do this function in Offer
> > > Exchange,
> > > > > since
> > > > > > > > the
> > > > > > > > >  >> Offer Exchange is simplified. The idea would be that
> > > > initially
> > > > > > > IOTP
> > > > > > > > >  >> processes an Authentication, then a Web browser sends
> a
> > > > > private
> > > > > > > > >  >> information for Offer, and finally IOTP does Purchase
> > > > > Transaction.
> > > > > > > > In
> > > > > > > > >  >> IOTP version 1.0, IOTP supports a Consumer
> > Authentication
> > > by
> > > > > > > > Merchant,
> > > > > > > > >  >> however, IOTP does not support a Merchant
> Authentication
> > > by
> > > > > > > > >  >> Consumer. Is this correct?
> > > > > > > > >  >> 
> > > > > > > > >  >> If this is correct, will IOTP version 2.0 support the
> > > > Merchant
> > > > > > > > >  >> Authentication by Consumer?
> > > > > > > > >  >> 
> > > > > > > > >  >> Regards,
> > > > > > > > >  >> 
> > > > > > > > >  >> --
> > > > > > > > >  >> Yoshiaki Kawatsura
> > > > > > > > >  >> Hitachi, Ltd.
> > > > > > > > >  >> 
> > > > > > > > >  >
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> >
> **************************************************************************
> > > > > > > > ********************
> > > > > > > > 
> > > > > > > > This Email and any attached files are confidential and may
> > also
> > > be
> > > > > > > > privileged. 
> > > > > > > > If you are not the intended recipient, please notify the
> > > > postmaster
> > > > > > > using
> > > > > > > > email 
> > > > > > > > address [email-masked] or call +44 171 557 5000 and
> ask
> > > for
> > > > > the 
> > > > > > > > IT Helpdesk.  You should not copy this email and any
> attached
> > > > files,
> > > > > use
> > > > > > > > them 
> > > > > > > > for any purpose or disclose the contents to any other
> person;
> > > all
> > > > > copies
> > > > > > > > of the 
> > > > > > > > Email and associated files in your possession should be
> > > destroyed.
> > > > > > > > 
> > > > > > > > Mondex International Limited
> > > > > > > > 47-53 Cannon Street
> > > > > > > > London EC4M 5SQ
> > > > > > > > United Kingdom
> > > > > > > > Registered No: 3122085, England
> > > > > > > > 
> > > > > > > > Phone:          +44 171 557 5000
> > > > > > > > Fax:            +44 171 557 5200
> > > > > > > > Email:          [email-masked]
> > > > > > > > WebSite:        http://www.mondexinternational.com
> > > > > > > > 
> > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> >
> **************************************************************************
> > > > > > > > *******************
> > > > > > > >
> > > > >
> > >
> -----------------------------------------------------------------------
> > > > > > > > Message addressed to: [email-masked]
> > > > > > > > Archive available at:
> > http://www.elistx.com/archives/ietf-trade/
> > > > > > > > To (un)subscribe send a message with "subscribe" or
> > > "unsubscribe"
> > > > in
> > > > > the
> > > > > > > > body to: [email-masked]
> > > > > > > > 
> > > > > > >
> > > > >
> > >
> -----------------------------------------------------------------------
> > > > > > > Message addressed to: [email-masked]
> > > > > > > Archive available at:
> http://www.elistx.com/archives/ietf-trade/
> > > > > > > To (un)subscribe send a message with "subscribe" or
> > "unsubscribe"
> > > in
> > > > > the
> > > > > > > body to: [email-masked]
> > > > > > > 
> > > > > > 
> > > > > >
> > > > >
> > > >
> > >
> >
> **************************************************************************
> > > > > ********************
> > > > > > 
> > > > > > This Email and any attached files are confidential and may also
> be
> > > > > privileged. 
> > > > > > If you are not the intended recipient, please notify the
> > postmaster
> > > > > using email 
> > > > > > address [email-masked] or call +44 171 557 5000 and ask
> for
> > > the
> > > > 
> > > > > > IT Helpdesk.  You should not copy this email and any attached
> > files,
> > > > use
> > > > > them 
> > > > > > for any purpose or disclose the contents to any other person;
> all
> > > > copies
> > > > > of the 
> > > > > > Email and associated files in your possession should be
> destroyed.
> > > > > > 
> > > > > > Mondex International Limited
> > > > > > 47-53 Cannon Street
> > > > > > London EC4M 5SQ
> > > > > > United Kingdom
> > > > > > Registered No: 3122085, England
> > > > > > 
> > > > > > Phone:          +44 171 557 5000
> > > > > > Fax:            +44 171 557 5200
> > > > > > Email:          [email-masked]
> > > > > > WebSite:        http://www.mondexinternational.com
> > > > > > 
> > > > > >
> > > > >
> > > >
> > >
> >
> **************************************************************************
> > > > > *******************
> > > > > > 
> > > > > 
> > > >
> > -----------------------------------------------------------------------
> > > > Message addressed to: [email-masked]
> > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> > the
> > > > body to: [email-masked]
> > > > 
> > > 
> > >
> >
> **************************************************************************
> > > ********************
> > > 
> > > This Email and any attached files are confidential and may also be
> > > privileged. 
> > > If you are not the intended recipient, please notify the postmaster
> > using
> > > email 
> > > address [email-masked] or call +44 171 557 5000 and ask for the
> 
> > > IT Helpdesk.  You should not copy this email and any attached files,
> use
> > > them 
> > > for any purpose or disclose the contents to any other person; all
> copies
> > > of the 
> > > Email and associated files in your possession should be destroyed.
> > > 
> > > Mondex International Limited
> > > 47-53 Cannon Street
> > > London EC4M 5SQ
> > > United Kingdom
> > > Registered No: 3122085, England
> > > 
> > > Phone:          +44 171 557 5000
> > > Fax:            +44 171 557 5200
> > > Email:          [email-masked]
> > > WebSite:        http://www.mondexinternational.com
> > > 
> > >
> >
> **************************************************************************
> > > *******************
> > > 
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> > 
> 
> **************************************************************************
> ********************
> 
> This Email and any attached files are confidential and may also be
> privileged. 
> If you are not the intended recipient, please notify the postmaster using
> email 
> address [email-masked] or call +44 171 557 5000 and ask for the 
> IT Helpdesk.  You should not copy this email and any attached files, use
> them 
> for any purpose or disclose the contents to any other person; all copies
> of the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> **************************************************************************
> *******************
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: Werner Hans <[email-masked]>
To: [email-masked]
Date: Wed, 12 May 1999 11:31:53 +0200
Subject: IOTP Architecture and Payment API 1.0.1a
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--Message-Boundary-22118
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

Hi

the appendix contains the most recent version of the Payment API 
documents which fixes two mistakes 
 - removal of Customer Care messages from XML-definition and
 - removal of some superfluous explanation
and extends the technical identification of Payment Instruments. 
Now, both some identifier and a narrative name is assigned to each
payment instrument.

Werner
------------------------------
Werner Hans - Systemanalytiker
Atos
Pascalstrasse 19
D-52076 Aachen
Tel.: +49 -2408 148349
<www.atos-group.de>

--Message-Boundary-22118
Content-type: text/plain; charset=US-ASCII
Content-disposition: inline
Content-description: Attachment information.

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  iotpar101a.zip
     Date:  12 May 1999, 11:15
     Size:  550171 bytes.
     Type:  ZIP-archive

--Message-Boundary-22118
Content-type: Application/ZIP; name="iotpar101a.zip"
Content-disposition: attachment; filename="iotpar101a.zip"
Content-transfer-encoding: BASE64

--Message-Boundary-22118--
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: [email-masked],  Yoshiaki KAWATSURA <[email-masked]>
Cc: Ietf Trade WG <[email-masked]>
Subject: RE: PayReceiptRefs (Problem of IOTP Spec.)
Date: Tue, 11 May 1999 14:23:06 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Yoshiaki

I have read it and it's on my list of things to do. Unfortunately I didn't
have the time last week and this week I'm at CardTech Securtech all week in
Chicago. I hope to respond to you next week. Hope this is OK.

David

> ----------
> From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> Sent: 	10 May 1999 00:24
> To: 	[email-masked]
> Cc: 	[email-masked]; [email-masked]
> Subject: 	Re: PayReceiptRefs (Problem of IOTP Spec.)
> 
> David,
> I sent the following mail two weeks ago. Did you have a chance to read it?
> Please let me know some comments for my proposal.
> 
> Thanks,
> --
> Yoshiaki Kawatsura
> 
> --
> There is a problem for PayReceiptRefs in PayReceipt component in the
> current IOTP specification.
> 
> Problem:
> In the current specification, we can not use the PayReceiptRefs.  IOTP
> Payment Bridge of the Payment Handler can not set the PayReceiptRefs
> because the Bridge can not know IOTP Component ID.  IOTP Payment Bridge
> of the Consumer can not also get the components correspond to IDs
> which is included in the PayReceiptRefs.
> 
> So I suggest the following changes.
>  
> Change:
> (a) Change PayReceiptRefs to PayReceiptRefNames element.
>     (PayReceiptRefs is dropped)
> (b) PayReceiptRefNames defines as the list of Name element in
>     PackagedContent of PaySchemeData component.
> (c) The Name element in PackagedContent must be unique in the transaction.
> (d) The PaySchemeData Component, that Name element is the same ones 
> in the token of PayReceiptRefNames, must be hashed and signed in the
> Payment
> Response signature component.
> 
> Sequence of Process:
> (1) The Payment Hander Payment Bridge set the PayReceiptRefNames.
> (2) Payment Handler OAC hashes and signs to the corresponding
> PaySchemeData.
> (3) Consumer OAC checks the signatures.
> (4) OAC picks up the PackagedContents which include the same Name
>     element in PayReceiptRefNames and passes them to the Payment Bridge as
>     PayReceiptPackagedContent in the CheckPayReceipt.
> 
> What do you think this?
> 
> 
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-mime-detector-00.txt
Date: Tue, 11 May 1999 08:48:54 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	Title		: HTTP MIME Type Handler Detection
	Author(s)	: C. Smith, D. Eastlake 3rd, D. Soroka
	Filename	: draft-ietf-trade-mime-detector-00.txt
	Pages		: 12
	Date		: 10-May-99
	
Entities composing web pages to provide services over HTTP frequently
have the problem of not knowing what MIME types have handlers
installed at a user's browser.  For example, whether an IOTP or VRML
or SET or some streaming media handler is available.  In many cases
they would want to display different web pages or content depending
on a MIME handler's availability.  This document summarizes a
reasonable technique to solve this problem for most of the browsers
actually deployed on the Internet as of April 1999.  It is intended
to be of practical use to implementors during the period before the
wide deployment of superior standards based techniques which may be
developed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-mime-detector-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-trade-mime-detector-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trade-mime-detector-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-mime-detector-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-trade-mime-detector-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: Ietf Trade WG <[email-masked]>
Subject: Re: Using XML as well as HTML 
Date: Mon, 10 May 1999 22:56:39 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

It seems to me that the solution for this involves, among other things,
the Offer Request message we have defered until after v1.0...

I suggest we go for simplicity in v1.0 and just say that support of
XML is recommended even though your point about XML support at some
level being implied since IOTP uses XML syntax...

Thanks,
Donald

From:  David Burdett <[email-masked]>
Message-Id:  <[email-masked]>
Date:  Fri, 30 Apr 1999 20:04:09 +0100

>I agree that XML should be recommended, the problem is how do you discover
>if the consumer has XML/XSL support in their IOTP implementation? 
>
>If a merchant or one of the other trading roles is unsure, then they'll
>never send order descrciptions, etc, in XML to the consumer. On the other
>hand if a particular IOTP consumer client software becomes highly popular
>that supports XML/XSL, then it is reasonable safe for merchants to use XML
>and more might do so.
>
>Finally, you could argue that since to do IOTP at all, there must be XML
>support then at least half the solution *must* be there. In this case, you
>could recommend displaying a message to the user of the problem and
>displaying XML in a very simple way.
>
>David
>
>
>> ----------
>> From: 	Donald E. Eastlake 3rd[SMTP:[email-masked]]
>> Sent: 	29 April 1999 10:04
>> To: 	Ietf Trade WG
>> Subject: 	Re: Using XML as well as HTML 
>> 
>> I believe that support for XML should be recommended but not required.
>> 
>> Thanks,
>> Donald
>> 
>> From:  David Burdett <[email-masked]>
>> Message-Id:  <[email-masked]>
>> To:  Ietf Trade WG <[email-masked]>
>> Date:  Thu, 29 Apr 1999 17:17:05 +0100
>> 
>> >Following on from my other email on using HTML, the spec doesn't
>> currently
>> >describe how XML could be used. I think that it should. We could provide
>> >similar guidelines for XML/XSL to the ones for HTML. 
>> >
>> >Who thinks this is a good idea?
>> >
>> >David
>> >
>> >THIS EMAIL IS FOR UNRESTRICTED DISTRIBUTION
>> >> mailto:<[email-masked]>
>> >> Mondex International, US Advanced Technology Office
>> >> 111 Pine St, 6th Floor, San Francisco, CA 94111
>> >> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
>> -----------------------------------------------------------------------
>> Message addressed to: [email-masked]
>> Archive available at: http://www.elistx.com/archives/ietf-trade/
>> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>> body to: [email-masked]
>> 
>
>************************************************************************************
**********
>
>This Email and any attached files are confidential and may also be privileged. 
>If you are not the intended recipient, please notify the postmaster using email 
>address [email-masked] or call +44 171 557 5000 and ask for the 
>IT Helpdesk.  You should not copy this email and any attached files, use them 
>for any purpose or disclose the contents to any other person; all copies of the 
>Email and associated files in your possession should be destroyed.
>
>Mondex International Limited
>47-53 Cannon Street
>London EC4M 5SQ
>United Kingdom
>Registered No: 3122085, England
>
>Phone:          +44 171 557 5000
>Fax:            +44 171 557 5200
>Email:          [email-masked]
>WebSite:        http://www.mondexinternational.com
>
>************************************************************************************
*********
>-----------------------------------------------------------------------
>Message addressed to: [email-masked]
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: [email-masked]
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: Re: PayReceiptRefs (Problem of IOTP Spec.)
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Mon, 10 May 1999 16:24:52 +0900 (JST)
Lines: 43
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,
I sent the following mail two weeks ago. Did you have a chance to read it?
Please let me know some comments for my proposal.

Thanks,
--
Yoshiaki Kawatsura

--
There is a problem for PayReceiptRefs in PayReceipt component in the
current IOTP specification.

Problem:
In the current specification, we can not use the PayReceiptRefs.  IOTP
Payment Bridge of the Payment Handler can not set the PayReceiptRefs
because the Bridge can not know IOTP Component ID.  IOTP Payment Bridge
of the Consumer can not also get the components correspond to IDs
which is included in the PayReceiptRefs.

So I suggest the following changes.
 
Change:
(a) Change PayReceiptRefs to PayReceiptRefNames element.
    (PayReceiptRefs is dropped)
(b) PayReceiptRefNames defines as the list of Name element in
    PackagedContent of PaySchemeData component.
(c) The Name element in PackagedContent must be unique in the transaction.
(d) The PaySchemeData Component, that Name element is the same ones 
in the token of PayReceiptRefNames, must be hashed and signed in the Payment
Response signature component.

Sequence of Process:
(1) The Payment Hander Payment Bridge set the PayReceiptRefNames.
(2) Payment Handler OAC hashes and signs to the corresponding PaySchemeData.
(3) Consumer OAC checks the signatures.
(4) OAC picks up the PackagedContents which include the same Name
    element in PayReceiptRefNames and passes them to the Payment Bridge as
    PayReceiptPackagedContent in the CheckPayReceipt.

What do you think this?

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: Ietf Trade WG <[email-masked]>
Date: Thu, 6 May 1999 02:01:08 -0400
Subject: RE: Brand IDs & their registration. Was: RE: Comments on draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

My understanding is that a RID (Registered ID obtained from ISO) is assigned
more to an organization or association.

It is not easy to distinguish between
a RID, a brand, and a consumer acceptance mark.

For MasterCard, the same RID is used for:
   - MasterCard International chip credit cards,
   - and Maestro International pin based debit cards - which uses a different
   acceptance "mark" for what some consumers may consider a "brand".

For MasterCard's RID the hexadecimal characters 0xA000000004 have been assigned
by ISO to MasterCard.  The RID does not differentiate between our MasterCard and
Maestro marks,
but it is only the full RID + PIX (AID) that distinguishes what "brand" or mark
is involved.

"Lewis, Tony" <[email-masked]> on 05/04/99 08:09:25 PM

To:   Ietf Trade WG <[email-masked]>
cc:    (bcc: John Wankmueller/NYC/MASTERCARD)
Subject:  RE: Brand IDs & their registration. Was: RE: Comments on draft-ie tf-t
      rade-iotp-v1.0-protocol-03.txt, part 1

In fact, Europay, MasterCard, and Visa have established EMVCo. (EMVCo does
not currently have a web site so I can't point you there. I'm told the site
won't be up until July.)

EMV does not have brands in the same way that SET or IOTP do. EMV deals with
application identifiers or AIDs. An AID consists of two parts: a Registered
ID (RID) obtained from ISO and a Proprietary Extension (PIX). The RID is
roughly analogous to a brand. For example, Visa has an RID with a value of
0xA000000003. Visa then assigns PIX values for various applications, e.g.,
Credit/Debit, VisaCash, etc.

Typically, an RID will be obtained by a payment brand, but there is no
guarantee that there is a one to one correspondence between a brand and a
RID.

As we look at a way to integrate EMV cards with SET, we expect to add AIDs
to the SET Initiation message, which will ultimately be replaced by IOTP.

Tony
> ----------
> From:   Steve Fabes[SMTP:[email-masked]]
> Sent:   Tuesday, May 04, 1999 10:33 AM
> To:     [email-masked]; Ietf Trade WG
> Subject:     Re: Brand IDs & their registration. Was: RE: Comments on
> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
>
> Donald, I do not have much to add but when looking at the actions of SETCo
> we should also anticipate that the EMV world will establish EMVCo and its
> rules will need to be considered along side those of SETCo's. The
> membership
> of the two Co's will overlap but be different and to assume the same brand
> and operating rules may be optimistic.
> -----Original Message-----
> From: [email-masked] <[email-masked]>
> To: Ietf Trade WG <[email-masked]>
> Date: Tuesday, May 04, 1999 09:33
> Subject: RE: Brand IDs & their registration. Was: RE: Comments on
> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
>
>
> >Regardless of EMV or whatever, it seems to me that we have a "brand"
> registry
> >problem to solve.  Credit/Debit cards are sort of odd creatures because
> they can
> >be used in payments via multiple different protocols.  Most stored value
> cards
> >can be used via only a single protocol.
> >
> >SETco clearly operates a card brand regisgration operations, however
> limited and
> >even if it's only expressed in the brand level certificates that SETco
> allows to
> >be created under its root.  I think the hope was that the SET
> registration
> could
> >be used in IOTP for all credit/debit cards.  This would at least avoid
> the
> >problem where some brand was registered under different names at
> different
> >registries (where "different" could just be things like whether there is
> really
> >a space between American and Express or whether the C is capitalized in
> >Mastercard or whether Visa is all caps, ...).  Is there a list of bands
> >officially supported by SETco and their official names?
> >
> >However, if SETco is inappropriate for this, because they won't
> "register"
> >brands that haven't joined", then we need a separate solution.  It
> certainly
> >isn't very difficult to set up regsitration via IANA, probably using the
> same
> >Designated Expert criteria being used for other things.  The only
> difficulty I
> >can see is that some brand might get registered there for IOTP use and
> then
> >later join SETco or otherwise get registered in some other system under
> some
> >other name.  Various messyness with Discover/Novus, AT&T Universal Card
> changing
> >to CitiBank Universal Card and the like occur to me.  I'm not sure those
> cases
> >are actually name change problems but one can image such.
> >
> >All this seems to imply that we need to be prepared to register
> credit/debit
> >card brands under "IOTP:".  I'm a bit reluctant to drop the "SET:" branch
> of the
> >brand tree in IOTP.  If some brand exists under SETco but hasn't yet been
> >registered under IOTP, it seems like it should be usable.  Of course,
> this
> means
> >that some brand registered under IOTP could later join SETco and could
> exist as
> >both IOTP:BrandX and SET:BrandX or SET:Brand-ex.  So you might get into
> >equivalence tables but these are really just an artifact of the real
> world
> being
> >messy and not particularly worse than brands splitting or merging.
> >
> >I don't see a major problem with us using
> brand:[product]:[promotional-name] if
> >we want, even after "SET:", although we should make it clear in that case
> that
> >these values differ from those permitted in the SET protocol.  The other
> >possibility that occurs to me would be to use brand[:product] and have a
> >separate [promotional=xxx] optional attribute.
> >
> >What do people think?
> >
> >Thanks,
> >Donald
> >
> >Donald E. Eastlake, 3rd
> >17 Skyline Drive, Hawthorne, NY 10532 USA
> >[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
> >
> >home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
> >[email-masked]   tel: 1-914-276-2668
> >
> >
> >
> >David Burdett <[email-masked]> on 04/29/99 12:17:01 PM
> >
> >To:   Ietf Trade WG <[email-masked]>
> >cc:   "Lewis, Tony" <[email-masked]> (bcc: Donald
> Eastlake/Hawthorne/IBM)
> >Subject:  RE: Brand IDs & their registration. Was: RE: Comments on
> draft-ie
> >      tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> >
> >
> >
> >
> >
> >I agree with Tony. Smart card based EMV transactions will be the dominant
> >payment model within a decade, probably even earlier especially in the
> >non-US part of the world. The main reasons being, in my view:
> >*    it will reduce fraud as it's much much harder to copy a smart card
> >than a mag stripe card
> >*    it makes internet credit card payments "card present" transactions
> >which should result in lower merchant fees. This also means that it will
> be
> >much harder for customers to claim they never made an internet purchase
> >*    using a multi-application smart card you will be able to use just
> >one smart card for debit, credit, electronic cash, a loyalty scheme as
> well
> >as hold electronic tickets for anything from local cinema to your next
> >flight.
> >
> >To rephrase a MasterCard ad line, "smart cards are the future of money".
> >
> >David
> >
> >> ----------
> >> From:   Lewis, Tony[SMTP:[email-masked]]
> >> Sent:   28 April 1999 20:30
> >> To:     Ietf Trade WG
> >> Subject:     RE: Brand IDs & their registration. Was: RE: Comments on
> >> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> >>
> >> My point is that the brand is "Visa" no matter whether using IOTP, SET
> or
> >> any other protocol.
> >>
> >> As for EMV, the very first live SET 1.0 transaction was made using an
> EMV
> >> card with the EMV data carried inside a SET message extension. EMV
> credit
> >> and debit products are a significant part of the future of electronic
> >> commerce. I expect they will be the dominant model for payment in a
> >> decade.
> >>
> >> Tony
> >> > ----------
> >> > From:      Steve Fabes[SMTP:[email-masked]]
> >> > Sent:      Wednesday, April 28, 1999 3:43 PM
> >> > To:   Lewis, Tony; Ietf Trade WG
> >> > Subject:   Re: Brand IDs & their registration. Was: RE: Comments on
> >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> >> >
> >> > Tony - do your comments infer that SET.Visa will be the only
> e-Commerce
> >> > product that an IOTP product supplier can expect to see. Can you see
> a
> >> day
> >> > when a Visa EMV 3.1.1 (or 3.x.x) based credit product could also be
> used
> >> > inside an IOTP product?
> >> > -----Original Message-----
> >> > From: Lewis, Tony <[email-masked]>
> >> > To: Ietf Trade WG <[email-masked]>
> >> > Date: Wednesday, April 28, 1999 13:21
> >> > Subject: RE: Brand IDs & their registration. Was: RE: Comments on
> >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> >> >
> >> >
> >> > >David,
> >> > >
> >> > >I am new to this group and do not know what lead to the current
> >> approach.
> >> > >There are undoubtedly some issues that I don't know about. However,
> it
> >> > seems
> >> > >to me that a brand is a brand no matter what payment protocol is
> being
> >> > used.
> >> > >The only difference I see between "IOTP:Visa" and "SET:Visa" is that
> >> the
> >> > >latter indicates that the brand is supported by a specific payment
> >> > protocol.
> >> > >Since you need to support brands other than those supported by SET,
> >> there
> >> > >will need to be a registry. It seems to me that there should only be
> >> one
> >> > >such registry rather than the two being proposed. I recommend having
> a
> >> > >single domain for these brands. It seems reasonable to initially
> >> populate
> >> > it
> >> > >using the brands registered with SET and those non-SET brands you
> >> listed
> >> > in
> >> > >your note.
> >> > >
> >> > >Tony
> >> > >> ----------
> >> > >> From: David Burdett[SMTP:[email-masked]]
> >> > >> Sent: Wednesday, April 28, 1999 11:36 AM
> >> > >> To: Ietf Trade WG; Lewis, Tony
> >> > >> Subject: Brand IDs & their registration. Was: RE: Comments on
> >> > >> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> >> > >>
> >> > >> In the current specification the basic idea for identifying brands
> is
> >> > that
> >> > >> they should be of the form "xxx:brandid" where "xxx" can be "SET"
> >> which
> >> > >> indicates that the brandid is any valid brandid that is accepted
> by
> >> > SET,
> >> > >> or
> >> > >> alternatively "IOTP" which can be used to define any brand not
> >> defined
> >> > by
> >> > >> SET. The idea was that we should not need to define "Visa",
> >> > "MasterCard",
> >> > >> "American Express", etc more than once since they are already
> defined
> >> > and
> >> > >> registered by SET.
> >> > >>
> >> > >> However a couple of problems may arise ...
> >> > >>
> >> > >> USING THE SET BRAND ID FOR NON-SET PAYMENTS
> >> > >> Although IOTP can support SET as a payment protocol, it can also
> >> > support
> >> > >> credit card payments (using Secure Channel Credit Debit - SCCD)
> where
> >> > the
> >> > >> credit card information (no, name, expiration date, etc) is coded
> >> > >> effectively in the clear but with privacy protection provided by
> >> using
> >> > a
> >> > >> secure channel such as SSL. In this way it provides a similar
> level
> >> of
> >> > >> privacy/security as for credit card payments that occur now where
> a
> >> web
> >> > >> page
> >> > >> form is completed by the user.
> >> > >>
> >> > >> My question is, will it be reasonable to use the SET brandid in
> this
> >> > way
> >> > >> to
> >> > >> cover non-SET credit card payments. I *think* the answer is "yes"
> as
> >> > you
> >> > >> can
> >> > >> quite imagine a situation where a consumer is offered a choice of
> >> using
> >> > >> their VISA credit card to pay using either SET or SCCD.
> >> > >>
> >> > >> WHAT BRAND ID SHOULD BE USED FOR CO BRANDS
> >> > >> If a payment brand, such as a local brand or co-brand, chooses,
> >> > initiall
> >> > >> to
> >> > >> use just SCCD rather than SET then they would not (I think) need
> to
> >> > >> register
> >> > >> their brand with SET. In this case, they might register their
> brand
> >> as
> >> > an
> >> > >> "IOTP" brand. However if they later adopted SET, they would end up
> >> with
> >> > >> potentially two equivalent Brand IDs. Do you think we might be
> better
> >> > off
> >> > >> with a straight IOTP brand and keep all the names under the
> >> procedures
> >> > >> defined by IANA? I'm not sure?
> >> > >>
> >> > >> REGISTERING NEW BRAND IDs
> >> > >> To help assist in answering the last point, the following is what
> I'm
> >> > >> currently writing as the proposed IANA procedure for registering
> new
> >> > brand
> >> > >> ids. Any comments:
> >> > >>
> >> > >> >>>Clip>>>
> >> > >> The format of the Brand ID is either:
> >> > >> * SET:setbrand where setbrand is a brand which is accepted by the
> >> > >> [SET] payment protocol
> >> > >> * IOTP:iotpbrand where iotpbrand may be:
> >> > >> - GeldKarte
> >> > >> - Mondex
> >> > >>
> >> > >> New values of the high level prefix (SET or IOTP) should be
> allocated
> >> > >> following review on the IETF Trade Working Group mailing list and
> by
> >> > the
> >> > >> Designated Expert.
> >> > >>
> >> > >> Values of "setbrand" are allocated as defined in the [SET]
> >> > specifications.
> >> > >>
> >> > >> New values of "iotpbrand" must be announced to the IETF Trade WG
> >> > mailing
> >> > >> list and, if there are no objections within three weeks, be
> allocated
> >> > on
> >> > a
> >> > >> "first come first served" basis.
> >> > >> <<<End Clip<<<
> >> > >>
> >> > >> Regards
> >> > >>
> >> > >> David
> >> > >> > ----------
> >> > >> > From: Lewis, Tony[SMTP:[email-masked]]
> >> > >> > Sent: 28 April 1999 08:14
> >> > >> > To: Ietf Trade WG
> >> > >> > Subject: RE: Comments on
> >> draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> >> > >> > part  1
> >> > >> >
> >> > >> > In SET, the BrandID is either "brand" or "brand:product".
> >> > >> >
> >> > >> > In Japan, there are products that are co-branded. Essentially
> these
> >> > >> > products
> >> > >> > are private label cards for domestic transactions with an
> >> > international
> >> > >> > brand for non-domestic transactions. The private label can be
> >> > reflected
> >> > >> in
> >> > >> > a
> >> > >> > SET cardholder certificate as the "promotional card name" under
> the
> >> > >> > international brand's hierarchy and/or the cardholder can have a
> >> > >> > certificate
> >> > >> > issued under the private label hierarchy.
> >> > >> >
> >> > >> > There is no provision to carry both the private label (of the
> >> > Japanese
> >> > >> > credit card company) and the international brand as part of the
> SET
> >> > >> > BrandID.
> >> > >> >
> >> > >> > Tony
> >
> >
> >-----------------------------------------------------------------------
> >Message addressed to: [email-masked]
> >Archive available at: http://www.elistx.com/archives/ietf-trade/
> >To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> >body to: [email-masked]
> >
>
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
>
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Yarar, Hakan" <[email-masked]>
To: [email-masked]
Cc: clj <[email-masked]>
Subject: Products supporting IOTP
Date: Thu, 6 May 1999 09:47:31 +0200 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Hi all,

MS Site Server Commerce does not support IOTP (at least for the time being).
Is there any available product instead of Site Server ? 
I would like contact with companies that have an available product
supporting IOTP
or working to implement IOTP.

Regards
--
Hakan Yarar
NCR SE-Copenhagen, Software R&D Department
Tlf. : +45 38157594, Fax : +45 38331522

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: IETF TRADE WG <[email-masked]>
Date: Wed, 5 May 1999 17:31:31 -0400
Subject: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, Part 2 of 2
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I've gone over the rest of the document and have the following suggestions:

INQUIRY:

I'm not sure why inquiry is restricted as much as it is.  Seems like the thing
to do is to describe the function it performs.  Then point out that the customer
role is probably intermittantly connected and is not required to and is unlikely
to respond to inquires even if it is connected.  And then perhaps, as guidance
for the implementation of some sort of "Inquire" UI button at the customer site,
suggest it inquire of the last role to which a message was sent or all roles.
In particular, I see no reason not to allow server to server inquires.

MISCELLANEOUS:

Section 7 first paragrah and figure: might be confusing to some readers.  First
paragraph says Trading Block has Trading Components and optionally Signature
Component but figure only shows a Signature Component as part of a Signature
Block...  Suggest that Trading Block components be labeled Trading Comp. except
one labeled Siganture Comp.  Also, might note somehow that the Certificate Comp.
is optional...

Section 7.9, OTP -> IOTP.
Section 7.10, same.

Section 7.16, first sentence, suggest inserting "if required" after
"Certificates".

Sections 7.16.1, .2, .3, &.4: suggest adding "With" to the subject titles or
perhaps even "Signature Block With".

Section 8.2.2: I'm not sure that a flat statement that a PING does not start an
IOTP aware 'application' is necessarily correct.  This could be implemented in
different ways.  In any case, it seems to be contradicated by the immediately
following sentence.  Perhaps there should just be some words about it being
intended to test connectivity and basic listening / reponse functions and need
not start a full blown IOTP application or do any deep tests, or words to that
effect.

Section 10:
     In URLs, "ftp:" should be followed by "//".
     merchant.com is a real highly active web site. Suggest occurances of it be
replaced by "example.com" which is actually resreved for this purpose.  Another
possibility is using the ".example" top level domain name which is also reserved
for use in examples.
     suggest at least one BrandLogoNetLocn per example be an "http://" URL to
show that it need not always be ftp.
     BrandIDs do not correspond to text elsewhere about Brands...
     In 10.2 example, closes of <PackagedContent ...> sometimes are missing the
"/" right after the "<" and in some cases have attributes...
     In 10.4, CyberCash is the company, which offers a number of services,
including CyberCoin.  Most references seem to be to CyberCoin.  ccash.com is yet
another different real (French language) site.  Suggest ccash.example or
cybercash.com.  (mxbankuk.com doesn't exist yet but who knows...)

TRIVIA:

Section 7.7, Content, Status, last sentence "of" -> "if"
Section 7.10, same.

Section 8.1.12, figure 33, "TPO Block only i last ..." -> "TPO Block only if
last..."

Section 8.2.1, "inquiring on transaction" -> "inquiring about a transaction"
     "component hold the" -> "component holds the"
     "contain for encapsulated" -> "contain encapsulated"

Section 9: suggest lower casing the upper case occurances of "GIF".

DTD:
     I didn't review the DTD in detail.

GLOSSARY:

Delivery Handler: suggest dropping the word "physically".  Maybe substitute
"directly"?

IOTP Transaction: "of IOTP" -> "of the IOTP"

Payment Instrument: CybeCash -> CyberCoin or CyberCash's CyberCoin

Promotional Brand:  I don't think use here and in Section 10 doesn't correspond
with text elsewhere about brands.

Transaction Type: last item of bulleted list doesn't read like it should be a
list member.

Thanks,
Donald

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
[email-masked]   tel: 1-914-276-2668

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: Steve Fabes <[email-masked]>
To: David Burdett <[email-masked]>,  Ietf Trade WG <[email-masked]>
Subject: Re: Brand IDs & their registration. Was: RE: Comments on draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
Date: Wed, 5 May 1999 13:53:34 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Referencing SET spec must be preferred - but having linked to it we are a
tad vulnerable to changes that they make within the SET closed world. As
long as we are careful to only link to their method of brand Id we should be
OK - it does infer that IETF Trade Group must now keep an open eye on SET.
-----Original Message-----
From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Date: Wednesday, May 05, 1999 12:43
Subject: RE: Brand IDs & their registration. Was: RE: Comments on draft-ie
tf-t rade-iotp-v1.0-protocol-03.txt, part 1

>Having read the various notes from Tony, Don and Steve on this topic. I
>think that we should have a separate IOTP brand registry, maintained by
IANA
>under the procedures I included in an earlier email ... if only because it
>will be simpler. However I think this would mean that:
>* we would need to copy all the SET brands to the IOTP spec
>* we would need to also copy the SET method of defining Brand Ids to
>the IOTP spec (although we might be able to refer to the SET specs)
>
>The last item is less than ideal since it will involve replication and
>therefore the need to keep things in step.
>
>Thoughts?
>
>David
>
>> ----------
>> From: Lewis, Tony[SMTP:[email-masked]]
>> Sent: 04 May 1999 17:09
>> To: Ietf Trade WG
>> Subject: RE: Brand IDs & their registration. Was: RE: Comments on
>> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
>>
>> In fact, Europay, MasterCard, and Visa have established EMVCo. (EMVCo
does
>> not currently have a web site so I can't point you there. I'm told the
>> site
>> won't be up until July.)
>>
>> EMV does not have brands in the same way that SET or IOTP do. EMV deals
>> with
>> application identifiers or AIDs. An AID consists of two parts: a
>> Registered
>> ID (RID) obtained from ISO and a Proprietary Extension (PIX). The RID is
>> roughly analogous to a brand. For example, Visa has an RID with a value
of
>> 0xA000000003. Visa then assigns PIX values for various applications,
e.g.,
>> Credit/Debit, VisaCash, etc.
>>
>> Typically, an RID will be obtained by a payment brand, but there is no
>> guarantee that there is a one to one correspondence between a brand and a
>> RID.
>>
>> As we look at a way to integrate EMV cards with SET, we expect to add
AIDs
>> to the SET Initiation message, which will ultimately be replaced by IOTP.
>>
>> Tony
>> > ----------
>> > From: Steve Fabes[SMTP:[email-masked]]
>> > Sent: Tuesday, May 04, 1999 10:33 AM
>> > To: [email-masked]; Ietf Trade WG
>> > Subject: Re: Brand IDs & their registration. Was: RE: Comments on
>> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
>> >
>> > Donald, I do not have much to add but when looking at the actions of
>> SETCo
>> > we should also anticipate that the EMV world will establish EMVCo and
>> its
>> > rules will need to be considered along side those of SETCo's. The
>> > membership
>> > of the two Co's will overlap but be different and to assume the same
>> brand
>> > and operating rules may be optimistic.
>> > -----Original Message-----
>> > From: [email-masked] <[email-masked]>
>> > To: Ietf Trade WG <[email-masked]>
>> > Date: Tuesday, May 04, 1999 09:33
>> > Subject: RE: Brand IDs & their registration. Was: RE: Comments on
>> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
>> >
>> >
>> > >Regardless of EMV or whatever, it seems to me that we have a "brand"
>> > registry
>> > >problem to solve.  Credit/Debit cards are sort of odd creatures
because
>> > they can
>> > >be used in payments via multiple different protocols.  Most stored
>> value
>> > cards
>> > >can be used via only a single protocol.
>> > >
>> > >SETco clearly operates a card brand regisgration operations, however
>> > limited and
>> > >even if it's only expressed in the brand level certificates that SETco
>> > allows to
>> > >be created under its root.  I think the hope was that the SET
>> > registration
>> > could
>> > >be used in IOTP for all credit/debit cards.  This would at least avoid
>> > the
>> > >problem where some brand was registered under different names at
>> > different
>> > >registries (where "different" could just be things like whether there
>> is
>> > really
>> > >a space between American and Express or whether the C is capitalized
in
>> > >Mastercard or whether Visa is all caps, ...).  Is there a list of
bands
>> > >officially supported by SETco and their official names?
>> > >
>> > >However, if SETco is inappropriate for this, because they won't
>> > "register"
>> > >brands that haven't joined", then we need a separate solution.  It
>> > certainly
>> > >isn't very difficult to set up regsitration via IANA, probably using
>> the
>> > same
>> > >Designated Expert criteria being used for other things.  The only
>> > difficulty I
>> > >can see is that some brand might get registered there for IOTP use and
>> > then
>> > >later join SETco or otherwise get registered in some other system
under
>> > some
>> > >other name.  Various messyness with Discover/Novus, AT&T Universal
Card
>> > changing
>> > >to CitiBank Universal Card and the like occur to me.  I'm not sure
>> those
>> > cases
>> > >are actually name change problems but one can image such.
>> > >
>> > >All this seems to imply that we need to be prepared to register
>> > credit/debit
>> > >card brands under "IOTP:".  I'm a bit reluctant to drop the "SET:"
>> branch
>> > of the
>> > >brand tree in IOTP.  If some brand exists under SETco but hasn't yet
>> been
>> > >registered under IOTP, it seems like it should be usable.  Of course,
>> > this
>> > means
>> > >that some brand registered under IOTP could later join SETco and could
>> > exist as
>> > >both IOTP:BrandX and SET:BrandX or SET:Brand-ex.  So you might get
into
>> > >equivalence tables but these are really just an artifact of the real
>> > world
>> > being
>> > >messy and not particularly worse than brands splitting or merging.
>> > >
>> > >I don't see a major problem with us using
>> > brand:[product]:[promotional-name] if
>> > >we want, even after "SET:", although we should make it clear in that
>> case
>> > that
>> > >these values differ from those permitted in the SET protocol.  The
>> other
>> > >possibility that occurs to me would be to use brand[:product] and have
>> a
>> > >separate [promotional=xxx] optional attribute.
>> > >
>> > >What do people think?
>> > >
>> > >Thanks,
>> > >Donald
>> > >
>> > >Donald E. Eastlake, 3rd
>> > >17 Skyline Drive, Hawthorne, NY 10532 USA
>> > >[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
>> > >
>> > >home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
>> > >[email-masked]   tel: 1-914-276-2668
>> > >
>> > >
>> > >
>> > >David Burdett <[email-masked]> on 04/29/99 12:17:01 PM
>> > >
>> > >To:   Ietf Trade WG <[email-masked]>
>> > >cc:   "Lewis, Tony" <[email-masked]> (bcc: Donald
>> > Eastlake/Hawthorne/IBM)
>> > >Subject:  RE: Brand IDs & their registration. Was: RE: Comments on
>> > draft-ie
>> > >      tf-t rade-iotp-v1.0-protocol-03.txt, part  1
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >I agree with Tony. Smart card based EMV transactions will be the
>> dominant
>> > >payment model within a decade, probably even earlier especially in the
>> > >non-US part of the world. The main reasons being, in my view:
>> > >*    it will reduce fraud as it's much much harder to copy a smart
card
>> > >than a mag stripe card
>> > >*    it makes internet credit card payments "card present"
transactions
>> > >which should result in lower merchant fees. This also means that it
>> will
>> > be
>> > >much harder for customers to claim they never made an internet
purchase
>> > >*    using a multi-application smart card you will be able to use just
>> > >one smart card for debit, credit, electronic cash, a loyalty scheme as
>> > well
>> > >as hold electronic tickets for anything from local cinema to your next
>> > >flight.
>> > >
>> > >To rephrase a MasterCard ad line, "smart cards are the future of
>> money".
>> > >
>> > >David
>> > >
>> > >> ----------
>> > >> From:   Lewis, Tony[SMTP:[email-masked]]
>> > >> Sent:   28 April 1999 20:30
>> > >> To:     Ietf Trade WG
>> > >> Subject:     RE: Brand IDs & their registration. Was: RE: Comments
on
>> > >> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part  1
>> > >>
>> > >> My point is that the brand is "Visa" no matter whether using IOTP,
>> SET
>> > or
>> > >> any other protocol.
>> > >>
>> > >> As for EMV, the very first live SET 1.0 transaction was made using
an
>> > EMV
>> > >> card with the EMV data carried inside a SET message extension. EMV
>> > credit
>> > >> and debit products are a significant part of the future of
electronic
>> > >> commerce. I expect they will be the dominant model for payment in a
>> > >> decade.
>> > >>
>> > >> Tony
>> > >> > ----------
>> > >> > From:      Steve Fabes[SMTP:[email-masked]]
>> > >> > Sent:      Wednesday, April 28, 1999 3:43 PM
>> > >> > To:   Lewis, Tony; Ietf Trade WG
>> > >> > Subject:   Re: Brand IDs & their registration. Was: RE: Comments
on
>> > >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
>> > >> >
>> > >> > Tony - do your comments infer that SET.Visa will be the only
>> > e-Commerce
>> > >> > product that an IOTP product supplier can expect to see. Can you
>> see
>> > a
>> > >> day
>> > >> > when a Visa EMV 3.1.1 (or 3.x.x) based credit product could also
be
>> > used
>> > >> > inside an IOTP product?
>> > >> > -----Original Message-----
>> > >> > From: Lewis, Tony <[email-masked]>
>> > >> > To: Ietf Trade WG <[email-masked]>
>> > >> > Date: Wednesday, April 28, 1999 13:21
>> > >> > Subject: RE: Brand IDs & their registration. Was: RE: Comments on
>> > >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
>> > >> >
>> > >> >
>> > >> > >David,
>> > >> > >
>> > >> > >I am new to this group and do not know what lead to the current
>> > >> approach.
>> > >> > >There are undoubtedly some issues that I don't know about.
>> However,
>> > it
>> > >> > seems
>> > >> > >to me that a brand is a brand no matter what payment protocol is
>> > being
>> > >> > used.
>> > >> > >The only difference I see between "IOTP:Visa" and "SET:Visa" is
>> that
>> > >> the
>> > >> > >latter indicates that the brand is supported by a specific
payment
>> > >> > protocol.
>> > >> > >Since you need to support brands other than those supported by
>> SET,
>> > >> there
>> > >> > >will need to be a registry. It seems to me that there should only
>> be
>> > >> one
>> > >> > >such registry rather than the two being proposed. I recommend
>> having
>> > a
>> > >> > >single domain for these brands. It seems reasonable to initially
>> > >> populate
>> > >> > it
>> > >> > >using the brands registered with SET and those non-SET brands you
>> > >> listed
>> > >> > in
>> > >> > >your note.
>> > >> > >
>> > >> > >Tony
>> > >> > >> ----------
>> > >> > >> From: David Burdett[SMTP:[email-masked]]
>> > >> > >> Sent: Wednesday, April 28, 1999 11:36 AM
>> > >> > >> To: Ietf Trade WG; Lewis, Tony
>> > >> > >> Subject: Brand IDs & their registration. Was: RE: Comments on
>> > >> > >> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
>> > >> > >>
>> > >> > >> In the current specification the basic idea for identifying
>> brands
>> > is
>> > >> > that
>> > >> > >> they should be of the form "xxx:brandid" where "xxx" can be
>> "SET"
>> > >> which
>> > >> > >> indicates that the brandid is any valid brandid that is
accepted
>> > by
>> > >> > SET,
>> > >> > >> or
>> > >> > >> alternatively "IOTP" which can be used to define any brand not
>> > >> defined
>> > >> > by
>> > >> > >> SET. The idea was that we should not need to define "Visa",
>> > >> > "MasterCard",
>> > >> > >> "American Express", etc more than once since they are already
>> > defined
>> > >> > and
>> > >> > >> registered by SET.
>> > >> > >>
>> > >> > >> However a couple of problems may arise ...
>> > >> > >>
>> > >> > >> USING THE SET BRAND ID FOR NON-SET PAYMENTS
>> > >> > >> Although IOTP can support SET as a payment protocol, it can
also
>> > >> > support
>> > >> > >> credit card payments (using Secure Channel Credit Debit - SCCD)
>> > where
>> > >> > the
>> > >> > >> credit card information (no, name, expiration date, etc) is
>> coded
>> > >> > >> effectively in the clear but with privacy protection provided
by
>> > >> using
>> > >> > a
>> > >> > >> secure channel such as SSL. In this way it provides a similar
>> > level
>> > >> of
>> > >> > >> privacy/security as for credit card payments that occur now
>> where
>> > a
>> > >> web
>> > >> > >> page
>> > >> > >> form is completed by the user.
>> > >> > >>
>> > >> > >> My question is, will it be reasonable to use the SET brandid in
>> > this
>> > >> > way
>> > >> > >> to
>> > >> > >> cover non-SET credit card payments. I *think* the answer is
>> "yes"
>> > as
>> > >> > you
>> > >> > >> can
>> > >> > >> quite imagine a situation where a consumer is offered a choice
>> of
>> > >> using
>> > >> > >> their VISA credit card to pay using either SET or SCCD.
>> > >> > >>
>> > >> > >> WHAT BRAND ID SHOULD BE USED FOR CO BRANDS
>> > >> > >> If a payment brand, such as a local brand or co-brand, chooses,
>> > >> > initiall
>> > >> > >> to
>> > >> > >> use just SCCD rather than SET then they would not (I think)
need
>> > to
>> > >> > >> register
>> > >> > >> their brand with SET. In this case, they might register their
>> > brand
>> > >> as
>> > >> > an
>> > >> > >> "IOTP" brand. However if they later adopted SET, they would end
>> up
>> > >> with
>> > >> > >> potentially two equivalent Brand IDs. Do you think we might be
>> > better
>> > >> > off
>> > >> > >> with a straight IOTP brand and keep all the names under the
>> > >> procedures
>> > >> > >> defined by IANA? I'm not sure?
>> > >> > >>
>> > >> > >> REGISTERING NEW BRAND IDs
>> > >> > >> To help assist in answering the last point, the following is
>> what
>> > I'm
>> > >> > >> currently writing as the proposed IANA procedure for
registering
>> > new
>> > >> > brand
>> > >> > >> ids. Any comments:
>> > >> > >>
>> > >> > >> >>>Clip>>>
>> > >> > >> The format of the Brand ID is either:
>> > >> > >> * SET:setbrand where setbrand is a brand which is accepted by
>> the
>> > >> > >> [SET] payment protocol
>> > >> > >> * IOTP:iotpbrand where iotpbrand may be:
>> > >> > >> - GeldKarte
>> > >> > >> - Mondex
>> > >> > >>
>> > >> > >> New values of the high level prefix (SET or IOTP) should be
>> > allocated
>> > >> > >> following review on the IETF Trade Working Group mailing list
>> and
>> > by
>> > >> > the
>> > >> > >> Designated Expert.
>> > >> > >>
>> > >> > >> Values of "setbrand" are allocated as defined in the [SET]
>> > >> > specifications.
>> > >> > >>
>> > >> > >> New values of "iotpbrand" must be announced to the IETF Trade
WG
>> > >> > mailing
>> > >> > >> list and, if there are no objections within three weeks, be
>> > allocated
>> > >> > on
>> > >> > a
>> > >> > >> "first come first served" basis.
>> > >> > >> <<<End Clip<<<
>> > >> > >>
>> > >> > >> Regards
>> > >> > >>
>> > >> > >> David
>> > >> > >> > ----------
>> > >> > >> > From: Lewis, Tony[SMTP:[email-masked]]
>> > >> > >> > Sent: 28 April 1999 08:14
>> > >> > >> > To: Ietf Trade WG
>> > >> > >> > Subject: RE: Comments on
>> > >> draft-ietf-trade-iotp-v1.0-protocol-03.txt,
>> > >> > >> > part  1
>> > >> > >> >
>> > >> > >> > In SET, the BrandID is either "brand" or "brand:product".
>> > >> > >> >
>> > >> > >> > In Japan, there are products that are co-branded. Essentially
>> > these
>> > >> > >> > products
>> > >> > >> > are private label cards for domestic transactions with an
>> > >> > international
>> > >> > >> > brand for non-domestic transactions. The private label can be
>> > >> > reflected
>> > >> > >> in
>> > >> > >> > a
>> > >> > >> > SET cardholder certificate as the "promotional card name"
>> under
>> > the
>> > >> > >> > international brand's hierarchy and/or the cardholder can
have
>> a
>> > >> > >> > certificate
>> > >> > >> > issued under the private label hierarchy.
>> > >> > >> >
>> > >> > >> > There is no provision to carry both the private label (of the
>> > >> > Japanese
>> > >> > >> > credit card company) and the international brand as part of
>> the
>> > SET
>> > >> > >> > BrandID.
>> > >> > >> >
>> > >> > >> > Tony
>> > >
>> > >
>> >
>-----------------------------------------------------------------------
>> > >Message addressed to: [email-masked]
>> > >Archive available at: http://www.elistx.com/archives/ietf-trade/
>> > >To (un)subscribe send a message with "subscribe" or "unsubscribe" in
>> the
>> > >body to: [email-masked]
>> > >
>> >
>> > -----------------------------------------------------------------------
>> > Message addressed to: [email-masked]
>> > Archive available at: http://www.elistx.com/archives/ietf-trade/
>> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
the
>> > body to: [email-masked]
>> >
>> -----------------------------------------------------------------------
>> Message addressed to: [email-masked]
>> Archive available at: http://www.elistx.com/archives/ietf-trade/
>> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>> body to: [email-masked]
>>
>
>***************************************************************************
*******************
>
>This Email and any attached files are confidential and may also be
privileged.
>If you are not the intended recipient, please notify the postmaster using
email
>address [email-masked] or call +44 171 557 5000 and ask for the
>IT Helpdesk.  You should not copy this email and any attached files, use
them
>for any purpose or disclose the contents to any other person; all copies of
the
>Email and associated files in your possession should be destroyed.
>
>Mondex International Limited
>47-53 Cannon Street
>London EC4M 5SQ
>United Kingdom
>Registered No: 3122085, England
>
>Phone:          +44 171 557 5000
>Fax:            +44 171 557 5200
>Email:          [email-masked]
>WebSite:        http://www.mondexinternational.com
>
>***************************************************************************
******************
>-----------------------------------------------------------------------
>Message addressed to: [email-masked]
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: [email-masked]
>

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>, Tony Lewis <[email-masked]>
Subject: RE: Question for IOTP Authentication
Date: Wed, 5 May 1999 20:10:41 +0100 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Tony

Thanks for the clarification, however, the SET  "authenticate me" is new to
me so I'd appreciate your clarification on a couple of things so that I can
see where it's coming from:

*	have you thought about what a user would do to authenticate a
merchant if they don't want to pay using SET?
*	what benefits, in business terms, would a user get from doing an SET
"authenticate me" rather than some other form of merchant authentication,
e.g. a straightforward IOTP authentication which returned a digital
signature that carried specific assertions?

David

> ----------
> From: 	Lewis, Tony[SMTP:[email-masked]]
> Sent: 	04 May 1999 08:20
> To: 	ietf-trade
> Subject: 	RE: Question for IOTP Authentication
> 
> David,
> 
> I'm replying to the list since the answer to your off-list question to me
> is
> likely to be of general interest.
> 
> We are looking for a way to support an "Authenticate Me" button on a
> merchant web site. When this button is clicked, it will invoke the SET
> wallet, which will validate the merchant certificate, the payment gateway
> certificate and a special signed message. If the validation is successful,
> the wallet will then display a message indicating that this is a valid SET
> merchant.
> 
> The flow would be something like this:
> 
> Click: "Authenticate Me"
> 
> <--- Authentication Wake up
> ---> PInitReq
> <--- PInitRes
> 
> Wallet: "This is a valid SET merchant."
> 
> 
> I'm suggesting that IOTP can be used for the wake up if we treat this as a
> "null" payment (one where the payment phase is elided).
> 
> By the way, "BAG" is the "SETCo Business Advisors Group", which will hold
> its first meeting next week.
> 
> Tony
> > ----------
> > From: 	David Burdett[SMTP:[email-masked]]
> > Sent: 	Monday, May 03, 1999 3:00 PM
> > To: 	Lewis, Tony
> > Subject: 	RE: Question for IOTP Authentication
> > 
> > Tony
> > 
> > I don't quite understand what Yoshiaki is talking about in his email.
> When
> > he refers to the BAG requirement, what does he mean? I also don't quite
> > understand how a "null" payment could be used as part of the solution as
> > you
> > describe.
> > 
> > It's just that I'm trying to understand the requirement so that I can
> see
> > how IOTP could meet the need.
> > 
> > Clarification will be greatly appreciated.
> > 
> > David
> > 
> > 
> > 
> > > ----------
> > > From: 	Lewis, Tony[SMTP:[email-masked]]
> > > Sent: 	03 May 1999 11:50
> > > To: 	[email-masked]
> > > Subject: 	RE: Question for IOTP Authentication
> > > 
> > > Yes, this authentication is performed prior to the shopping phase, but
> > > can't
> > > it be processed as a null payment and use both IOTP and SET
> > authentication
> > > mechanisms?
> > > 
> > > Tony
> > > > ----------
> > > > From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> > > > Sent: 	Sunday, May 02, 1999 8:19 AM
> > > > To: 	[email-masked]
> > > > Cc: 	Lewis, Tony; [email-masked];
> > > [email-masked]
> > > > Subject: 	RE: Question for IOTP Authentication
> > > > 
> > > > Tony mentioned to me the Mercahnt authentication has to do prior to
> > > > shopping phase, this is out of IOTP. So we can use separete
> > > > authentication only.
> > > > 
> > > > We need to define the SET Specific authentication, which
> > > > satisfy the requirement to the BAG Requirement, in SETCo.  because
> > > > consumer have to confirm whether Merchant is authorized by the
> > > > Acquirer and this requirement is payment dependent(IOTP is the
> payment
> > > > scheme independent messaging protocol).
> > > > 
> > > > I believe that the merit of using IOTP authentication is that we
> > > > can be concerned IOTP Authentication transaction with IOTP
> > > > Purchase transaction.
> > > > 
> > > > --
> > > > Yoshiaki Kawatsura Hitachi, Ltd.
> > > > 
> > > > 
> > > > 
> > > > >>>>> Fri, 30 Apr 1999 20:04:11 +0100,
> > > > 	David Burdett <[email-masked]> said:
> > > > 
> > > > > Tony
> > > > > 
> > > > > I can think of three ways that IOTP might be able to meet the
> > > > requirement
> > > > > you describe:
> > > > > *	using the Packaged Content element in the Pay Protocol
> > element (see
> > > > > section 6.6.4),
> > > > > *	the Consumer authenticates the Merchant separately using an
> > > > > authentication transaction, or 
> > > > > *	a combination of the two.
> > > > > 
> > > > > Each is discussed in a bit more detail below.
> > > > > 
> > > > > PAY PROTOCOL ELEMENT
> > > > > This involves the merchant including the relevent certificate and
> > > > message
> > > > > from the acquirer in the PackagedContent element in the Pay
> Protocol
> > > > element
> > > > > for SET of the Brand List (see spec section  6.6.4), then if the
> > > > Consumer
> > > > > wants to use SET for a payment they just pass the data to the SET
> > > > payment
> > > > > software working within IOTP which then checks the credentials.
> > > > > 
> > > > > The advantage of this approach is that the certificate will always
> > be
> > > > there
> > > > > and no extra messages will be required to retrieve it. The
> > > disadvantage
> > > > is
> > > > > that it increases the size of the messages.
> > > > > 
> > > > > SEPARATE CONSUMER AUTHENTICATION OF THE MERCHANT
> > > > > In this case, the SET software recognises that there a certificate
> > and
> > > > > message from the acquirer is needed and makes a request to the
> IOTP
> > > > software
> > > > > to obtain it. When this need occurs, a separate IOTP
> Authentication
> > > > > Transaction (see spec section 8.1.6) is used to get the
> information.
> > 
> > > > > 
> > > > > This would involve:
> > > > > *	the Consumer sending an IOTPAuthentication Request message
> > to the
> > > > > merchant specifying in the Algorithm element that the Merchant
> > should
> > > > do,
> > > > > for example, a SET merchant authentication, then
> > > > > *	the Merchant replying with a Authentication Response message
> > > > > including the necessary certificate and acquirer message in the
> > > Packaged
> > > > > Content.
> > > > > 
> > > > > COMBINATION
> > > > > An alternative might be to include some fingerprint of the
> > > > > certificate/message in the PayProtocol element, so that the
> consumer
> > > SET
> > > > > software can check if it already has a copy of it. If it hasn't
> then
> > a
> > > > > separate consumer initiated IOTP Athentication of the merchant
> could
> > > be
> > > > used
> > > > > to obtain it.
> > > > > 
> > > > > Does this make sense?
> > > > > 
> > > > > David
> > > > > 
> > > > > 
> > > > > 
> > > > > > ----------
> > > > > > From: 	Lewis, Tony[SMTP:[email-masked]]
> > > > > > Sent: 	29 April 1999 17:36
> > > > > > To: 	Yoshiaki KAWATSURA
> > > > > > Cc: 	Ietf Trade WG
> > > > > > Subject: 	RE: Question for IOTP Authentication
> > > > > > 
> > > > > > David,
> > > > > > 
> > > > > > I believe this proposal originates from requirements that SETCo
> > has
> > > > > > defined
> > > > > > for SET 2.0 although when we discussed the approach outlined by
> > > > Yoshiaki
> > > > > > at
> > > > > > our meeting last week, we recommended some changes.
> > > > > > 
> > > > > > I believe what we will need is the ability for the merchant to
> > push
> > > > some
> > > > > > data (certificates and a signed message from the acquirer) to
> the
> > > > > > cardholder
> > > > > > wallet who will use that data to authenticate the merchant. If
> > that
> > > > can be
> > > > > > accomplished with the existing authentication transaction then I
> > > > believe
> > > > > > your change will satisfy our needs.
> > > > > > 
> > > > > > However, there may be other issues behind the input from Hitachi
> > so
> > > > > > Yoshiaki
> > > > > > should also respond.
> > > > > > 
> > > > > > Tony
> > > > > > > ----------
> > > > > > > From: 	David Burdett[SMTP:[email-masked]]
> > > > > > > Sent: 	Thursday, April 29, 1999 4:00 PM
> > > > > > > To: 	Yoshiaki KAWATSURA
> > > > > > > Cc: 	Ietf Trade WG
> > > > > > > Subject: 	RE: Question for IOTP Authentication
> > > > > > > 
> > > > > > > Yoshiaki
> > > > > > > 
> > > > > > > As you can see I'm catching up on all the Trade WG emails and
> > have
> > > > > > thought
> > > > > > > about your suggestion. In principle I can see why allowing a
> > > > Consumer to
> > > > > > > authenticate a Merchant is reasonable as, in the current
> version
> > > of
> > > > the
> > > > > > > specification, it states that a Conumer can authenticate a
> > Payment
> > > > > > Handler
> > > > > > > or a Delivery Handler (see section 8.1.13 second bullet point)
> > and
> > > > > > > therefore
> > > > > > > it is logical that a Consumer should also be able to
> > authenticate
> > > a
> > > > > > > Merchant.
> > > > > > > 
> > > > > > > However the method you suggest below for authenticating a
> > Merchant
> > > > is
> > > > > > > different from the way the Consumer authenticates a Payment
> > > Handler
> > > > or
> > > > > > > Delivery Handler in that it is integrated into the transaction
> > > (e.g
> > > > a
> > > > > > > purchase) which implies a further variation on the message
> flow.
> > > So,
> > > > I
> > > > > > > suggest that we meet your requirement by simply changing the
> > first
> > > > > > bullet
> > > > > > > point in section 8.1.13 to read the authentication transaction
> > can
> > > > be
> > > > > > used
> > > > > > > ... " by a Consumer to authenticate a *Merchant*, Payment
> > Handler
> > > or
> > > > a
> > > > > > > Delivery Handler ..."
> > > > > > > 
> > > > > > > Is this OK?
> > > > > > > 
> > > > > > > David
> > > > > > > 		
> > > > > > > 
> > > > > > > > ----------
> > > > > > > > From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> > > > > > > > Sent: 	29 March 1999 22:45
> > > > > > > > To: 	[email-masked]
> > > > > > > > Cc: 	[email-masked]; [email-masked];
> > > > > > > [email-masked];
> > > > > > > > [email-masked]
> > > > > > > > Subject: 	RE: Question for IOTP Authentication
> > > > > > > > 
> > > > > > > > David,
> > > > > > > > I agree with your suggestion.
> > > > > > > > But I also want to add the Merchant Authenticaton by
> Consumer 
> > > > > > > > prior to IOTP Purchase Transaction.
> > > > > > > > 
> > > > > > > > These are the same flow as follows,
> > > > > > > > 
> > > > > > > > Consumer             Merchant
> > > > > > > >    <-------------------
> > > > > > > >          TPO
> > > > > > > > 
> > > > > > > >    ------------------->
> > > > > > > >       Auth Req
> > > > > > > > 
> > > > > > > >    <------------------
> > > > > > > >       Auth Res
> > > > > > > > 
> > > > > > > > and Status Block is not sent to the Merchant.
> > > > > > > > 
> > > > > > > > After Consumer receives the Auth Response,
> > > > > > > > 1. If prior to IOTP purchase transaction
> > > > > > > > Success: Consumer sends the message to the Success
> > NetLocation.
> > > > > > > > Fail: Stop
> > > > > > > > 
> > > > > > > > 2. If in the IOTP Purchase Transaction
> > > > > > > > Success: Continue the transaction
> > > > > > > > Fail: Stop.
> > > > > > > > 
> > > > > > > > Make sense?
> > > > > > > > 
> > > > > > > > This is minor change and I think there is no affect in the
> > IOTP
> > > > > > > protocol.
> > > > > > > > Regards,
> > > > > > > > ----
> > > > > > > > Yoshiaki Kawatsura : E-mail [email-masked]
> > > > > > > >  Business & Information Systems Development Devision,
> > > Hitachi,Ltd.
> > > > > > > > Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
> > > > > > > > 
> > > > > > > > 
> > > > > > > >  >>>>> Fri, 26 Mar 1999 18:20:48 -0000,
> > > > > > > > 	 David Burdett <[email-masked]> said:
> > > > > > > > 
> > > > > > > >  >Yoshiaki
> > > > > > > >  >
> > > > > > > >  >The current version of IOTP does not support
> authentication
> > of
> > > > the
> > > > > > > > Merchant
> > > > > > > >  >by the Consumer. Part of the reasoning behind this is that
> > the
> > > > > > > Merchant
> > > > > > > > will
> > > > > > > >  >include a signature in the offer which can be used for
> this
> > > > purpose.
> > > > > > > >  >HOwever, as you say, the consumer might not want to give
> > > address
> > > > > > > > information
> > > > > > > >  >until they have authenticated the Merchant.
> > > > > > > >  >
> > > > > > > >  >You could actually do this although section 8.1.13 does
> not
> > > > > > > specifically
> > > > > > > >  >state this. What would be requried is that, after the
> > Consumer
> > > > has
> > > > > > > > received
> > > > > > > >  >the TPO, he authenticates the merchant with a separate
> > > > > > Authentication
> > > > > > > >  >transaction and then if its  OK continues with the
> original
> > > > > > > transaction.
> > > > > > > >  >
> > > > > > > >  >Would this make sense? If you think it does then please
> post
> > > the
> > > > > > idea
> > > > > > > to
> > > > > > > > the
> > > > > > > >  >list. I don't know though if we want to include this in
> v1.0
> > > > > > although
> > > > > > > it
> > > > > > > >  >could easily go into v 2.0
> > > > > > > >  >
> > > > > > > >  >David
> > > > > > > >  >
> > > > > > > >  >> ----------
> > > > > > > >  >> From: 	Yoshiaki
> > KAWATSURA[SMTP:[email-masked]]
> > > > > > > >  >> Sent: 	25 March 1999 22:46
> > > > > > > >  >> To: 	[email-masked]; [email-masked];
> > > > > > > > [email-masked]
> > > > > > > >  >> Cc: 	[email-masked]
> > > > > > > >  >> Subject: 	Question for IOTP Authentication
> > > > > > > >  >> 
> > > > > > > >  >> Don and David,
> > > > > > > >  >> I have a couple of question for IOTP Authentication.
> > > > > > > >  >> 
> > > > > > > >  >> Consumer wants to send private information such as home
> > > > address to
> > > > > > > >  >> authenticated merchants only for Offer. In fact, SET is
> > > > attempting
> > > > > > > to
> > > > > > > >  >> support simliar functionality. I believe that IOTP
> should
> > > > support
> > > > > > > > this.
> > > > > > > >  >> 
> > > > > > > >  >> IOTP version 1.0 cannot do this function in Offer
> > Exchange,
> > > > since
> > > > > > > the
> > > > > > > >  >> Offer Exchange is simplified. The idea would be that
> > > initially
> > > > > > IOTP
> > > > > > > >  >> processes an Authentication, then a Web browser sends a
> > > > private
> > > > > > > >  >> information for Offer, and finally IOTP does Purchase
> > > > Transaction.
> > > > > > > In
> > > > > > > >  >> IOTP version 1.0, IOTP supports a Consumer
> Authentication
> > by
> > > > > > > Merchant,
> > > > > > > >  >> however, IOTP does not support a Merchant Authentication
> > by
> > > > > > > >  >> Consumer. Is this correct?
> > > > > > > >  >> 
> > > > > > > >  >> If this is correct, will IOTP version 2.0 support the
> > > Merchant
> > > > > > > >  >> Authentication by Consumer?
> > > > > > > >  >> 
> > > > > > > >  >> Regards,
> > > > > > > >  >> 
> > > > > > > >  >> --
> > > > > > > >  >> Yoshiaki Kawatsura
> > > > > > > >  >> Hitachi, Ltd.
> > > > > > > >  >> 
> > > > > > > >  >
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > >
> > > > > >
> > > >
> > >
> >
> **************************************************************************
> > > > > > > ********************
> > > > > > > 
> > > > > > > This Email and any attached files are confidential and may
> also
> > be
> > > > > > > privileged. 
> > > > > > > If you are not the intended recipient, please notify the
> > > postmaster
> > > > > > using
> > > > > > > email 
> > > > > > > address [email-masked] or call +44 171 557 5000 and ask
> > for
> > > > the 
> > > > > > > IT Helpdesk.  You should not copy this email and any attached
> > > files,
> > > > use
> > > > > > > them 
> > > > > > > for any purpose or disclose the contents to any other person;
> > all
> > > > copies
> > > > > > > of the 
> > > > > > > Email and associated files in your possession should be
> > destroyed.
> > > > > > > 
> > > > > > > Mondex International Limited
> > > > > > > 47-53 Cannon Street
> > > > > > > London EC4M 5SQ
> > > > > > > United Kingdom
> > > > > > > Registered No: 3122085, England
> > > > > > > 
> > > > > > > Phone:          +44 171 557 5000
> > > > > > > Fax:            +44 171 557 5200
> > > > > > > Email:          [email-masked]
> > > > > > > WebSite:        http://www.mondexinternational.com
> > > > > > > 
> > > > > > >
> > > > > >
> > > >
> > >
> >
> **************************************************************************
> > > > > > > *******************
> > > > > > >
> > > >
> > -----------------------------------------------------------------------
> > > > > > > Message addressed to: [email-masked]
> > > > > > > Archive available at:
> http://www.elistx.com/archives/ietf-trade/
> > > > > > > To (un)subscribe send a message with "subscribe" or
> > "unsubscribe"
> > > in
> > > > the
> > > > > > > body to: [email-masked]
> > > > > > > 
> > > > > >
> > > >
> > -----------------------------------------------------------------------
> > > > > > Message addressed to: [email-masked]
> > > > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > > > To (un)subscribe send a message with "subscribe" or
> "unsubscribe"
> > in
> > > > the
> > > > > > body to: [email-masked]
> > > > > > 
> > > > > 
> > > > >
> > > >
> > >
> >
> **************************************************************************
> > > > ********************
> > > > > 
> > > > > This Email and any attached files are confidential and may also be
> > > > privileged. 
> > > > > If you are not the intended recipient, please notify the
> postmaster
> > > > using email 
> > > > > address [email-masked] or call +44 171 557 5000 and ask for
> > the
> > > 
> > > > > IT Helpdesk.  You should not copy this email and any attached
> files,
> > > use
> > > > them 
> > > > > for any purpose or disclose the contents to any other person; all
> > > copies
> > > > of the 
> > > > > Email and associated files in your possession should be destroyed.
> > > > > 
> > > > > Mondex International Limited
> > > > > 47-53 Cannon Street
> > > > > London EC4M 5SQ
> > > > > United Kingdom
> > > > > Registered No: 3122085, England
> > > > > 
> > > > > Phone:          +44 171 557 5000
> > > > > Fax:            +44 171 557 5200
> > > > > Email:          [email-masked]
> > > > > WebSite:        http://www.mondexinternational.com
> > > > > 
> > > > >
> > > >
> > >
> >
> **************************************************************************
> > > > *******************
> > > > > 
> > > > 
> > >
> -----------------------------------------------------------------------
> > > Message addressed to: [email-masked]
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > body to: [email-masked]
> > > 
> > 
> >
> **************************************************************************
> > ********************
> > 
> > This Email and any attached files are confidential and may also be
> > privileged. 
> > If you are not the intended recipient, please notify the postmaster
> using
> > email 
> > address [email-masked] or call +44 171 557 5000 and ask for the 
> > IT Helpdesk.  You should not copy this email and any attached files, use
> > them 
> > for any purpose or disclose the contents to any other person; all copies
> > of the 
> > Email and associated files in your possession should be destroyed.
> > 
> > Mondex International Limited
> > 47-53 Cannon Street
> > London EC4M 5SQ
> > United Kingdom
> > Registered No: 3122085, England
> > 
> > Phone:          +44 171 557 5000
> > Fax:            +44 171 557 5200
> > Email:          [email-masked]
> > WebSite:        http://www.mondexinternational.com
> > 
> >
> **************************************************************************
> > *******************
> > 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: Brand IDs & their registration. Was: RE: Comments on draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
Date: Wed, 5 May 1999 20:10:46 +0100 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Having read the various notes from Tony, Don and Steve on this topic. I
think that we should have a separate IOTP brand registry, maintained by IANA
under the procedures I included in an earlier email ... if only because it
will be simpler. However I think this would mean that:
*	we would need to copy all the SET brands to the IOTP spec
*	we would need to also copy the SET method of defining Brand Ids to
the IOTP spec (although we might be able to refer to the SET specs)

The last item is less than ideal since it will involve replication and
therefore the need to keep things in step.

Thoughts?

David

> ----------
> From: 	Lewis, Tony[SMTP:[email-masked]]
> Sent: 	04 May 1999 17:09
> To: 	Ietf Trade WG
> Subject: 	RE: Brand IDs & their registration. Was: RE: Comments on
> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
> 
> In fact, Europay, MasterCard, and Visa have established EMVCo. (EMVCo does
> not currently have a web site so I can't point you there. I'm told the
> site
> won't be up until July.)
> 
> EMV does not have brands in the same way that SET or IOTP do. EMV deals
> with
> application identifiers or AIDs. An AID consists of two parts: a
> Registered
> ID (RID) obtained from ISO and a Proprietary Extension (PIX). The RID is
> roughly analogous to a brand. For example, Visa has an RID with a value of
> 0xA000000003. Visa then assigns PIX values for various applications, e.g.,
> Credit/Debit, VisaCash, etc.
> 
> Typically, an RID will be obtained by a payment brand, but there is no
> guarantee that there is a one to one correspondence between a brand and a
> RID.
> 
> As we look at a way to integrate EMV cards with SET, we expect to add AIDs
> to the SET Initiation message, which will ultimately be replaced by IOTP.
> 
> Tony
> > ----------
> > From: 	Steve Fabes[SMTP:[email-masked]]
> > Sent: 	Tuesday, May 04, 1999 10:33 AM
> > To: 	[email-masked]; Ietf Trade WG
> > Subject: 	Re: Brand IDs & their registration. Was: RE: Comments on
> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > 
> > Donald, I do not have much to add but when looking at the actions of
> SETCo
> > we should also anticipate that the EMV world will establish EMVCo and
> its
> > rules will need to be considered along side those of SETCo's. The
> > membership
> > of the two Co's will overlap but be different and to assume the same
> brand
> > and operating rules may be optimistic.
> > -----Original Message-----
> > From: [email-masked] <[email-masked]>
> > To: Ietf Trade WG <[email-masked]>
> > Date: Tuesday, May 04, 1999 09:33
> > Subject: RE: Brand IDs & their registration. Was: RE: Comments on
> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > 
> > 
> > >Regardless of EMV or whatever, it seems to me that we have a "brand"
> > registry
> > >problem to solve.  Credit/Debit cards are sort of odd creatures because
> > they can
> > >be used in payments via multiple different protocols.  Most stored
> value
> > cards
> > >can be used via only a single protocol.
> > >
> > >SETco clearly operates a card brand regisgration operations, however
> > limited and
> > >even if it's only expressed in the brand level certificates that SETco
> > allows to
> > >be created under its root.  I think the hope was that the SET
> > registration
> > could
> > >be used in IOTP for all credit/debit cards.  This would at least avoid
> > the
> > >problem where some brand was registered under different names at
> > different
> > >registries (where "different" could just be things like whether there
> is
> > really
> > >a space between American and Express or whether the C is capitalized in
> > >Mastercard or whether Visa is all caps, ...).  Is there a list of bands
> > >officially supported by SETco and their official names?
> > >
> > >However, if SETco is inappropriate for this, because they won't
> > "register"
> > >brands that haven't joined", then we need a separate solution.  It
> > certainly
> > >isn't very difficult to set up regsitration via IANA, probably using
> the
> > same
> > >Designated Expert criteria being used for other things.  The only
> > difficulty I
> > >can see is that some brand might get registered there for IOTP use and
> > then
> > >later join SETco or otherwise get registered in some other system under
> > some
> > >other name.  Various messyness with Discover/Novus, AT&T Universal Card
> > changing
> > >to CitiBank Universal Card and the like occur to me.  I'm not sure
> those
> > cases
> > >are actually name change problems but one can image such.
> > >
> > >All this seems to imply that we need to be prepared to register
> > credit/debit
> > >card brands under "IOTP:".  I'm a bit reluctant to drop the "SET:"
> branch
> > of the
> > >brand tree in IOTP.  If some brand exists under SETco but hasn't yet
> been
> > >registered under IOTP, it seems like it should be usable.  Of course,
> > this
> > means
> > >that some brand registered under IOTP could later join SETco and could
> > exist as
> > >both IOTP:BrandX and SET:BrandX or SET:Brand-ex.  So you might get into
> > >equivalence tables but these are really just an artifact of the real
> > world
> > being
> > >messy and not particularly worse than brands splitting or merging.
> > >
> > >I don't see a major problem with us using
> > brand:[product]:[promotional-name] if
> > >we want, even after "SET:", although we should make it clear in that
> case
> > that
> > >these values differ from those permitted in the SET protocol.  The
> other
> > >possibility that occurs to me would be to use brand[:product] and have
> a
> > >separate [promotional=xxx] optional attribute.
> > >
> > >What do people think?
> > >
> > >Thanks,
> > >Donald
> > >
> > >Donald E. Eastlake, 3rd
> > >17 Skyline Drive, Hawthorne, NY 10532 USA
> > >[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
> > >
> > >home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
> > >[email-masked]   tel: 1-914-276-2668
> > >
> > >
> > >
> > >David Burdett <[email-masked]> on 04/29/99 12:17:01 PM
> > >
> > >To:   Ietf Trade WG <[email-masked]>
> > >cc:   "Lewis, Tony" <[email-masked]> (bcc: Donald
> > Eastlake/Hawthorne/IBM)
> > >Subject:  RE: Brand IDs & their registration. Was: RE: Comments on
> > draft-ie
> > >      tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > >
> > >
> > >
> > >
> > >
> > >I agree with Tony. Smart card based EMV transactions will be the
> dominant
> > >payment model within a decade, probably even earlier especially in the
> > >non-US part of the world. The main reasons being, in my view:
> > >*    it will reduce fraud as it's much much harder to copy a smart card
> > >than a mag stripe card
> > >*    it makes internet credit card payments "card present" transactions
> > >which should result in lower merchant fees. This also means that it
> will
> > be
> > >much harder for customers to claim they never made an internet purchase
> > >*    using a multi-application smart card you will be able to use just
> > >one smart card for debit, credit, electronic cash, a loyalty scheme as
> > well
> > >as hold electronic tickets for anything from local cinema to your next
> > >flight.
> > >
> > >To rephrase a MasterCard ad line, "smart cards are the future of
> money".
> > >
> > >David
> > >
> > >> ----------
> > >> From:   Lewis, Tony[SMTP:[email-masked]]
> > >> Sent:   28 April 1999 20:30
> > >> To:     Ietf Trade WG
> > >> Subject:     RE: Brand IDs & their registration. Was: RE: Comments on
> > >> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > >>
> > >> My point is that the brand is "Visa" no matter whether using IOTP,
> SET
> > or
> > >> any other protocol.
> > >>
> > >> As for EMV, the very first live SET 1.0 transaction was made using an
> > EMV
> > >> card with the EMV data carried inside a SET message extension. EMV
> > credit
> > >> and debit products are a significant part of the future of electronic
> > >> commerce. I expect they will be the dominant model for payment in a
> > >> decade.
> > >>
> > >> Tony
> > >> > ----------
> > >> > From:      Steve Fabes[SMTP:[email-masked]]
> > >> > Sent:      Wednesday, April 28, 1999 3:43 PM
> > >> > To:   Lewis, Tony; Ietf Trade WG
> > >> > Subject:   Re: Brand IDs & their registration. Was: RE: Comments on
> > >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > >> >
> > >> > Tony - do your comments infer that SET.Visa will be the only
> > e-Commerce
> > >> > product that an IOTP product supplier can expect to see. Can you
> see
> > a
> > >> day
> > >> > when a Visa EMV 3.1.1 (or 3.x.x) based credit product could also be
> > used
> > >> > inside an IOTP product?
> > >> > -----Original Message-----
> > >> > From: Lewis, Tony <[email-masked]>
> > >> > To: Ietf Trade WG <[email-masked]>
> > >> > Date: Wednesday, April 28, 1999 13:21
> > >> > Subject: RE: Brand IDs & their registration. Was: RE: Comments on
> > >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > >> >
> > >> >
> > >> > >David,
> > >> > >
> > >> > >I am new to this group and do not know what lead to the current
> > >> approach.
> > >> > >There are undoubtedly some issues that I don't know about.
> However,
> > it
> > >> > seems
> > >> > >to me that a brand is a brand no matter what payment protocol is
> > being
> > >> > used.
> > >> > >The only difference I see between "IOTP:Visa" and "SET:Visa" is
> that
> > >> the
> > >> > >latter indicates that the brand is supported by a specific payment
> > >> > protocol.
> > >> > >Since you need to support brands other than those supported by
> SET,
> > >> there
> > >> > >will need to be a registry. It seems to me that there should only
> be
> > >> one
> > >> > >such registry rather than the two being proposed. I recommend
> having
> > a
> > >> > >single domain for these brands. It seems reasonable to initially
> > >> populate
> > >> > it
> > >> > >using the brands registered with SET and those non-SET brands you
> > >> listed
> > >> > in
> > >> > >your note.
> > >> > >
> > >> > >Tony
> > >> > >> ----------
> > >> > >> From: David Burdett[SMTP:[email-masked]]
> > >> > >> Sent: Wednesday, April 28, 1999 11:36 AM
> > >> > >> To: Ietf Trade WG; Lewis, Tony
> > >> > >> Subject: Brand IDs & their registration. Was: RE: Comments on
> > >> > >> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > >> > >>
> > >> > >> In the current specification the basic idea for identifying
> brands
> > is
> > >> > that
> > >> > >> they should be of the form "xxx:brandid" where "xxx" can be
> "SET"
> > >> which
> > >> > >> indicates that the brandid is any valid brandid that is accepted
> > by
> > >> > SET,
> > >> > >> or
> > >> > >> alternatively "IOTP" which can be used to define any brand not
> > >> defined
> > >> > by
> > >> > >> SET. The idea was that we should not need to define "Visa",
> > >> > "MasterCard",
> > >> > >> "American Express", etc more than once since they are already
> > defined
> > >> > and
> > >> > >> registered by SET.
> > >> > >>
> > >> > >> However a couple of problems may arise ...
> > >> > >>
> > >> > >> USING THE SET BRAND ID FOR NON-SET PAYMENTS
> > >> > >> Although IOTP can support SET as a payment protocol, it can also
> > >> > support
> > >> > >> credit card payments (using Secure Channel Credit Debit - SCCD)
> > where
> > >> > the
> > >> > >> credit card information (no, name, expiration date, etc) is
> coded
> > >> > >> effectively in the clear but with privacy protection provided by
> > >> using
> > >> > a
> > >> > >> secure channel such as SSL. In this way it provides a similar
> > level
> > >> of
> > >> > >> privacy/security as for credit card payments that occur now
> where
> > a
> > >> web
> > >> > >> page
> > >> > >> form is completed by the user.
> > >> > >>
> > >> > >> My question is, will it be reasonable to use the SET brandid in
> > this
> > >> > way
> > >> > >> to
> > >> > >> cover non-SET credit card payments. I *think* the answer is
> "yes"
> > as
> > >> > you
> > >> > >> can
> > >> > >> quite imagine a situation where a consumer is offered a choice
> of
> > >> using
> > >> > >> their VISA credit card to pay using either SET or SCCD.
> > >> > >>
> > >> > >> WHAT BRAND ID SHOULD BE USED FOR CO BRANDS
> > >> > >> If a payment brand, such as a local brand or co-brand, chooses,
> > >> > initiall
> > >> > >> to
> > >> > >> use just SCCD rather than SET then they would not (I think) need
> > to
> > >> > >> register
> > >> > >> their brand with SET. In this case, they might register their
> > brand
> > >> as
> > >> > an
> > >> > >> "IOTP" brand. However if they later adopted SET, they would end
> up
> > >> with
> > >> > >> potentially two equivalent Brand IDs. Do you think we might be
> > better
> > >> > off
> > >> > >> with a straight IOTP brand and keep all the names under the
> > >> procedures
> > >> > >> defined by IANA? I'm not sure?
> > >> > >>
> > >> > >> REGISTERING NEW BRAND IDs
> > >> > >> To help assist in answering the last point, the following is
> what
> > I'm
> > >> > >> currently writing as the proposed IANA procedure for registering
> > new
> > >> > brand
> > >> > >> ids. Any comments:
> > >> > >>
> > >> > >> >>>Clip>>>
> > >> > >> The format of the Brand ID is either:
> > >> > >> * SET:setbrand where setbrand is a brand which is accepted by
> the
> > >> > >> [SET] payment protocol
> > >> > >> * IOTP:iotpbrand where iotpbrand may be:
> > >> > >> - GeldKarte
> > >> > >> - Mondex
> > >> > >>
> > >> > >> New values of the high level prefix (SET or IOTP) should be
> > allocated
> > >> > >> following review on the IETF Trade Working Group mailing list
> and
> > by
> > >> > the
> > >> > >> Designated Expert.
> > >> > >>
> > >> > >> Values of "setbrand" are allocated as defined in the [SET]
> > >> > specifications.
> > >> > >>
> > >> > >> New values of "iotpbrand" must be announced to the IETF Trade WG
> > >> > mailing
> > >> > >> list and, if there are no objections within three weeks, be
> > allocated
> > >> > on
> > >> > a
> > >> > >> "first come first served" basis.
> > >> > >> <<<End Clip<<<
> > >> > >>
> > >> > >> Regards
> > >> > >>
> > >> > >> David
> > >> > >> > ----------
> > >> > >> > From: Lewis, Tony[SMTP:[email-masked]]
> > >> > >> > Sent: 28 April 1999 08:14
> > >> > >> > To: Ietf Trade WG
> > >> > >> > Subject: RE: Comments on
> > >> draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> > >> > >> > part  1
> > >> > >> >
> > >> > >> > In SET, the BrandID is either "brand" or "brand:product".
> > >> > >> >
> > >> > >> > In Japan, there are products that are co-branded. Essentially
> > these
> > >> > >> > products
> > >> > >> > are private label cards for domestic transactions with an
> > >> > international
> > >> > >> > brand for non-domestic transactions. The private label can be
> > >> > reflected
> > >> > >> in
> > >> > >> > a
> > >> > >> > SET cardholder certificate as the "promotional card name"
> under
> > the
> > >> > >> > international brand's hierarchy and/or the cardholder can have
> a
> > >> > >> > certificate
> > >> > >> > issued under the private label hierarchy.
> > >> > >> >
> > >> > >> > There is no provision to carry both the private label (of the
> > >> > Japanese
> > >> > >> > credit card company) and the international brand as part of
> the
> > SET
> > >> > >> > BrandID.
> > >> > >> >
> > >> > >> > Tony
> > >
> > >
> > >-----------------------------------------------------------------------
> > >Message addressed to: [email-masked]
> > >Archive available at: http://www.elistx.com/archives/ietf-trade/
> > >To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > >body to: [email-masked]
> > >
> > 
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> > 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: New IOTP spec doiagram style. Comments please.
Date: Wed, 5 May 1999 20:10:35 +0100 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

OK. I'll update the diagrams.

David

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	03 May 1999 12:56
> To: 	Trade WG
> Subject: 	Re: New IOTP spec doiagram style. Comments please.
> 
> I think that for the back-and-forth flow type diagrams, the revised form
> will
> improve things by being more compact without loss of info.
> 
> Thanks,
> Donald
> 
> Donald E. Eastlake, 3rd
> 17 Skyline Drive, Hawthorne, NY 10532 USA
> [email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
> 
> home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
> [email-masked]   tel: 1-914-276-2668
> 
> 
> 
> David Burdett <[email-masked]> on 04/28/99 05:45:41 PM
> 
> To:   Ietf Trade WG <[email-masked]>
> cc:    (bcc: Donald Eastlake/Hawthorne/IBM)
> Subject:  New IOTP spec doiagram style. Comments please.
> 
> 
> 
> 
> 
> One of the comments that Don Eastlake makes about the latest version of
> the
> IOTP spec is as follows ...
> 
>      "Page spanning figures, like Figure 3, are really pretty messy.  It
> would be better if the text could be made much more terse and this and
> similar figures started high on a page so they aren't split by a page
> boundary."
> 
> I agree with Don that the diagrams are messy, but they contain the same
> text
> as in an earlier version which used a drawing package to create them using
> just "text". If the diagrams are made more terse, then some of the
> explanation will have to be omitted.
> 
> An alternative is to adopt a different type of text diagram (see example
> below which should be viewed in a fixed font).
> Do people think this style is better. If there is a reasonable consensus
> that it is then I will change the diagrams, otherwise I am inclined to
> leave
> as is.
> 
> David
> EXAMPLE of partially re-worked figure 3. See the current spec for the
> original.
> 
>  CONSUMER               <<< IOTP MESSAGE >>>                    MERCHANT
>   1. Consumer decides to trade and sends information about the
>      transaction (requests an offer) to the Merchant, e.g.
>      using HTML
> 
>         >>>Information on what is being paid for (outside scope of
> IOTP)>>>
> 
>                            2. Merchant decides which payment brand and
>                               currencies/amounts to offer, places them in
> a
> Brand
>                               List Component and sends them to the
> Consumer
> 
>                            <<<< Brand List Component <<<<
> 
>   3. Consumer selects the payment brand, protocol and
>      currency/amount, creates a Brand Selection Component and
>      send it to the Merchant
> 
>                         >>>> Brand Selection Component >>>>
> 
>                            4. Merchant checks Brand Selection, creates
> Payment
>                               Amount information, optionally sings it to
>                               authorise payment and sends it to the
> Consumer
> 
>                <<< Pay Amount; Organisations: Merchant  <<<
>                <<< & Payment Handler; Signature (Offer) <<<
> 
>   5 Consumer checks the Payment Amount information and if OK
>      reuqests that the payment starts by sending a Payment
>      Request to the Payment Handler
> 
>        >>>      Brand List; Brand Selection; Pay Amount; Pay Scheme;
> >>>
>        >>> Organisations: Merchant and Payment Handler; Signature (Offer)
> >>>
> 
>                                       etc ...
> 
> 
> THIS EMAIL IS FOR UNLIMITED DISTRIBUTION
> > mailto:<[email-masked]>
> > Mondex International, US Advanced Technology Office
> > 111 Pine St, 6th Floor, San Francisco, CA 94111
> > Tel/Voicemail: +1 415 645 6973   Fax: +1 415 956 9370
> >
> 
> 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: IANA Considerations
Date: Wed, 5 May 1999 20:10:38 +0100 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Noted

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	03 May 1999 12:52
> To: 	Ietf Trade WG
> Subject: 	Re: IANA Considerations
> 
> This is good but I believe some minor wording change is still needed.  In
> particular:
> 
> On the mailing list: RFCs can not assume the perpertual existence of a
> working
> group.  It can say the IETF Trade Mailing List, but it can't say the Trade
> WG
> Mailing List.  The actual mailing list address should be given
> <[email-masked]>.
> 
> On the Designated Expert, it should probably explicitly say they are
> appointed
> by the IESG.  While the TRADE WG exists, the IESG is likely to defer to
> the WG
> on whom to appoint but there needs to be a mechaism that would survive the
> termination of the working group.
> 
> Thanks,
> Donald
> 
> Donald E. Eastlake, 3rd
> 17 Skyline Drive, Hawthorne, NY 10532 USA
> [email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
> 
> home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
> [email-masked]   tel: 1-914-276-2668
> 
> 
> 
> David Burdett <[email-masked]> on 04/28/99 05:45:37 PM
> 
> To:   Ietf Trade WG <[email-masked]>
> cc:    (bcc: Donald Eastlake/Hawthorne/IBM)
> Subject:  IANA Considerations
> 
> 
> 
> 
> 
> Below is the revised text for IANA considerations for the IOTP
> specification. Essentially it consists of a re-worked section 3.7.3 from
> the
> last draft as a new section 11.
> 
> If anyone has any comments please let me know.
> 
> David
> ========================
> 11. IANA Considerations
> 
> 11.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.
> 
>   Element Type/                      Attribute Values
>  Attribute Name
> 
> Algorithm/        "sha1" - indicates that authentication consists of
> Name              [SHA1] has of the challenge data
> (When Algorithm
> is a child of an  "signature" - indicates that authentication consists
> AuthData          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 Authentication Methods that
>                   begin with "pay:", new values are allocated
>                   following review on the IETF Trade Working Group
>                   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.
>                   [Note End]
> 
> 
> Brand/BrandId     "SET:setbrand" where setbrand is a brand which is
>                   accepted by the [SET] payment protocol
> 
>                   "IOTP:iotpbrand" where iotpbrand may be:
>                   o "GeldKarte"
>                   o "Mondex"
> 
>                   New values of the high level prefix (SET or IOTP)
>                   are allocated following review on the IETF Trade
>                   Working Group mailing list and by the Designated
>                   Expert.
> 
>                   Values of "setbrand" are allocated as defined in the
>                   [SET] specifications.
> 
>                   New values of "iotpbrand" must be announced to the
>                   IETF Trade WG 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 code as defined by [ISO4217]
> 
>                   If CurrCodeType is "IOTP" then new values must be
>                   announced to the IETF Trade WG 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.
>                   [Note End]
> 
> 
> 
> CurrencyAmount/   "ISO4217-A"
> CurrCodeType
>                   "IOTP"
> 
>                   New values of CurrCodeType attribute are allocated
>                   following review on the IETF Trade Working Group
>                   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 Working
>                   Group 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 Working
>                   Group 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/        "OtpTransaction"
> 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 delivery method is
>                   used.
> 
> Status/           Offer
> StatusType
>                   Payment
> 
>                   Delivery
> 
>                   Authentication
> 
>                   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 Working
>                     Group 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).
>                   [Note End]
> 
> 
> 
> 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 Working
>                     Group mailing list and by the Designated Expert.
> 
>                   [Note]   The document describing new values for the
>                            Trading Role attribute may be combined with
>                            documents that describe new Status Types
>                            (see above) and types of signatures (see
>                             below).
>                   [Note End]
> 
> 
> 
> TransId/          "BaselineAuthentication"
> OtpTransType
>                   "BaselineDeposit"
> 
>                   "BaselinePurchase"
> 
>                   "BaselineRefund"
> 
>                   "BaselineWithdrawal"
> 
>                   "BaselineValueExchange"
> 
>                   "BaselineInquiry"
> 
>                   "BaselinePing"
> 
>                   New values of the OtpTransType attribute are
>                   allocated following:
>                   o publication to the IETF Trade Working Group, 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/        "OfferResponse"
> Content
> (see Signature    "PaymentResponse"
> Component)
>                   "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 Working
>                     Group mailing list and by the Designated Expert.
> 
>                   [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).
>                   [Note End]
> 
> 
> 11.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.
> ===================================================
> 
> THIS EMAIL IS FOR UNLIMITED DISTRIBUTION
> 
> > mailto:<[email-masked]>
> > Mondex International, US Advanced Technology Office
> > 111 Pine St, 6th Floor, San Francisco, CA 94111
> > Tel/Voicemail: +1 415 645 6973   Fax: +1 415 956 9370
> >
> 
> **************************************************************************
> *****************
> 
> 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: Ietf Trade WG <[email-masked]>
Subject: Re: Links in HTML data 
Date: Wed, 05 May 1999 08:18:00 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This whole area seems to be more painful that you would think at
first.

My comment was because there seemed to me to be no problem with
circular links, etc., as long as everything pointed to was included.
Thus, if the Main page points to pages A and B, I don't see it as a
problem, as long as Main, A, & B are all included in the message, if
page A links to page B and/or page B links to page A and/or either A
or B link to Main.  Mainy web sites have a "return to mail page
button" and as long as both the subsidiary and main pages are included
in the probably signed message, what is the problem?

Part of the reason for allowing links was so that images and sounds,
etc., could be included as long as the data is also in the message and
so can't be changed.  As long as the message is self contained and
there is an appropriate user interface, this seems like an
advantage. At least, as David point out below, people are likely to do
it no matter what we say :-)

Anyway, I continue to believe there is no problem with pointers in
subsidiary HTML pages that are included in the message having links
back to the main page.

Thanks,
Donald

From:  David Burdett <[email-masked]>
Message-Id:  <[email-masked]>
To:  Ietf Trade WG <[email-masked]>
Date:  Thu, 29 Apr 1999 17:17:04 +0100

>I think I better add some clarification on this topic.
>
>Initially, the IOTP specs said that order descriptions, payment notes, etc,
>should be simple "plain text" to ensure interoperability and help avoid the
>problems that Hannu, Donn and Eric have described. It was then realised that
>both pilot implementations based on the v 0.9 spec used HTML and/or XML and
>not "plain text".
>
>Conclusion: People don't want to use plain text therefore we better include
>a method of handling HTML or XML in the specification. If we don't then
>people will use HTML/XML anyway and pretty well all implementations will be
>non-conformant !!
>
>Exactly what the specification currently says is attached below but
>essentially it is designed to avoid the problems that have been raised.
>Don's comment was the sentence at the end of the second bullet point which
>says:
>
>	"... the "Main" Packaged Content element must not be referred to
>from the HTML in any other Packaged Content"
>
>The general idea is that packaged HTML should really appear to the user as a
>simple single or multi page document, much like users would receive in the
>real world, where *everything* required to generate the document is included
>as packaged content in the Order Description. It therefore doesn't really
>make sense, in my view, to be able to follow a link that takes you to the
>"Main" packaged content from elsewhere.
>
>On the other hand you don't want to ban links entirely for example you might
>want to include in the HTML buttons which say "click here for customer care"
>which could take you to a web page where you could report problems. This
>could make sense. However another a link which dynamically downloaded over
>the web a GIF of your order description would not since the GIF could be
>changed after the event. IMOH though I don't think this type of behaviour by
>merchants will be particularly widespread. Thoughts anyone on this topic?
>
>David
>
>======= Extract from the v 03 spec ========
>  3.8.1 Packaging HTML
>
>  The packaged content may contain HTML. In this case the following
>  conventions are followed:
>
>  o references to any documents, images or other things, such as
>    sounds or web pages, which can affect the recipient's
>    understanding of the data which is being packaged must refer to
>    other Packaged Elements contained within the same parent
>    element, e.g. an Order Description
>
>  o if more than one Packaged Content element is included within a
>    parent element in order to meet the previous requirement, then
>    the Name attribute of the top level Packaged Content from which
>    references to all other Packaged Elements can be determined,
>    should have a value of Main. This means that the "Main"
>    Packaged Content element must not be referred to from the HTML
>    in any other Packaged Content
>
>  o relative references to other documents, images, etc. from one
>    Packaged Content element to another are realised by setting the
>    value of the relative reference to the Name attribute of
>    another Packaged Content element at the same level and within
>    the same parent element
>
>  o no external references that require the reference to be
>    resolved immediately should be used. As this could make the
>    HTML difficult or impossible to display completely
>
>  o [MIME] is used to encapsulate the data inside each Packaged
>    Element. This means that the information in the MIME header
>    used to identify the type of data which has been encapsulated
>    and therefore how it should be displayed.
>
>  If the above conventions are not followed by, for example, including
>  external references which must be resolved, then the recipient of the
>  HTML should be informed.
>
>  [Note]   As an implementation guideline the values of the Name
>           Attributes allocated to Packaged Content elements should
>           make it possible to extract each Packaged Content into a
>           directory and then display the HTML directly
>  [Note End]             
>
>
>> ----------
>> From: 	Hannu Nikkanen[SMTP:[email-masked]]
>> Sent: 	29 April 1999 01:05
>> To: 	Ietf Trade WG
>> Subject: 	Re: Links in HTML data
>> 
>> Hi,
>> 
>> I believe that "what you see is what you sign" would be a better approach.
>> 
>> In principle, graphics could be used to insert logos of other companies or
>> some text, which the signer could not distinguish from the signed part.
>> 
>> Even if the risk is low, it may lower consumer trust, which probably is
>> one
>> of the main commercial goals. 
>> 
>> Hannu
>> 
>> At 22:45 28.4.1999 +0100, you wrote:
>> >Don Eastlake says in his email:
>> >
>> >	"Section 3.8.1: I don't understand why sub-pages of an HTML main
>> >page couldn't have links back to the main page."
>> >
>> >In IOTP, where HTML is being used to describe a document such as an order
>> >description or a payment note, then it is, in many ways being provided as
>> an
>> >alternative to a single, or multi-page "real world" document. These
>> >documents should not in general be :"multi-media" documents, since for
>> >purposes of non-refutability, the document should be self-contained and
>> not
>> >reliant on other records held elsewhere. For this reason links should
>> only
>> >be used to allow, for example, graphics and other display devices to be
>> >included in the document.
>> >
>> >Therefore in my opinion, this should not be allowed. What do other people
>> >think?
>> >
>> >David
>> >> mailto:<[email-masked]>
>> >> Mondex International, US Advanced Technology Office
>> >> 111 Pine St, 6th Floor, San Francisco, CA 94111
>> >> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Lewis, Tony" <[email-masked]>
To: ietf-trade <[email-masked]>
Subject: RE: Question for IOTP Authentication
Date: Tue, 4 May 1999 18:58:11 -0700 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I thought I sent this to the list, but just realized that I did not.
> ----------
> From: 	Lewis, Tony
> Sent: 	Tuesday, May 04, 1999 5:14 PM
> To: 	'Steve Fabes'
> Subject: 	RE: Question for IOTP Authentication
> 
> I think the transaction time is orthogonal to the authentication. The
> entire user experience will go something like this:
> 
> Enter web site.
> Press "Authenticate me".
> Shop.
> Press "Pay".
> Obtain certificates (SET PInitReq).
> Press "Confirm payment".
> Send purchase request (SET PReq).
> 
> There will likely be substantial clock time between the authentication
> request and the purchase.
> 
> Tony
> ----------
> From: 	Steve Fabes[SMTP:[email-masked]]
> Sent: 	Tuesday, May 04, 1999 3:27 PM
> To: 	Lewis, Tony
> Cc: 	Ietf Trade WG
> Subject: 	Re: Question for IOTP Authentication
> 
> What would this do to the txn time and number of messages going across?
> -----Original Message-----
> From: Lewis, Tony <[email-masked]>
> To: [email-masked] <[email-masked]>
> Date: Monday, May 03, 1999 12:20
> Subject: RE: Question for IOTP Authentication
> 
> 
> >Yes, this authentication is performed prior to the shopping phase, but
> can't
> >it be processed as a null payment and use both IOTP and SET
> authentication
> >mechanisms?
> >
> >Tony
> >> ----------
> >> From: Yoshiaki KAWATSURA[SMTP:[email-masked]]
> >> Sent: Sunday, May 02, 1999 8:19 AM
> >> To: [email-masked]
> >> Cc: Lewis, Tony; [email-masked]; [email-masked]
> >> Subject: RE: Question for IOTP Authentication
> >>
> >> Tony mentioned to me the Mercahnt authentication has to do prior to
> >> shopping phase, this is out of IOTP. So we can use separete
> >> authentication only.
> >>
> >> We need to define the SET Specific authentication, which
> >> satisfy the requirement to the BAG Requirement, in SETCo.  because
> >> consumer have to confirm whether Merchant is authorized by the
> >> Acquirer and this requirement is payment dependent(IOTP is the payment
> >> scheme independent messaging protocol).
> >>
> >> I believe that the merit of using IOTP authentication is that we
> >> can be concerned IOTP Authentication transaction with IOTP
> >> Purchase transaction.
> >>
> >> --
> >> Yoshiaki Kawatsura Hitachi, Ltd.
> >>
> >>
> >>
> >> >>>>> Fri, 30 Apr 1999 20:04:11 +0100,
> >> David Burdett <[email-masked]> said:
> >>
> >> > Tony
> >> >
> >> > I can think of three ways that IOTP might be able to meet the
> >> requirement
> >> > you describe:
> >> > * using the Packaged Content element in the Pay Protocol element (see
> >> > section 6.6.4),
> >> > * the Consumer authenticates the Merchant separately using an
> >> > authentication transaction, or
> >> > * a combination of the two.
> >> >
> >> > Each is discussed in a bit more detail below.
> >> >
> >> > PAY PROTOCOL ELEMENT
> >> > This involves the merchant including the relevent certificate and
> >> message
> >> > from the acquirer in the PackagedContent element in the Pay Protocol
> >> element
> >> > for SET of the Brand List (see spec section  6.6.4), then if the
> >> Consumer
> >> > wants to use SET for a payment they just pass the data to the SET
> >> payment
> >> > software working within IOTP which then checks the credentials.
> >> >
> >> > The advantage of this approach is that the certificate will always be
> >> there
> >> > and no extra messages will be required to retrieve it. The
> disadvantage
> >> is
> >> > that it increases the size of the messages.
> >> >
> >> > SEPARATE CONSUMER AUTHENTICATION OF THE MERCHANT
> >> > In this case, the SET software recognises that there a certificate
> and
> >> > message from the acquirer is needed and makes a request to the IOTP
> >> software
> >> > to obtain it. When this need occurs, a separate IOTP Authentication
> >> > Transaction (see spec section 8.1.6) is used to get the information.
> >> >
> >> > This would involve:
> >> > * the Consumer sending an IOTPAuthentication Request message to the
> >> > merchant specifying in the Algorithm element that the Merchant should
> >> do,
> >> > for example, a SET merchant authentication, then
> >> > * the Merchant replying with a Authentication Response message
> >> > including the necessary certificate and acquirer message in the
> Packaged
> >> > Content.
> >> >
> >> > COMBINATION
> >> > An alternative might be to include some fingerprint of the
> >> > certificate/message in the PayProtocol element, so that the consumer
> SET
> >> > software can check if it already has a copy of it. If it hasn't then
> a
> >> > separate consumer initiated IOTP Athentication of the merchant could
> be
> >> used
> >> > to obtain it.
> >> >
> >> > Does this make sense?
> >> >
> >> > David
> >> >
> >> >
> >> >
> >> > > ----------
> >> > > From: Lewis, Tony[SMTP:[email-masked]]
> >> > > Sent: 29 April 1999 17:36
> >> > > To: Yoshiaki KAWATSURA
> >> > > Cc: Ietf Trade WG
> >> > > Subject: RE: Question for IOTP Authentication
> >> > >
> >> > > David,
> >> > >
> >> > > I believe this proposal originates from requirements that SETCo has
> >> > > defined
> >> > > for SET 2.0 although when we discussed the approach outlined by
> >> Yoshiaki
> >> > > at
> >> > > our meeting last week, we recommended some changes.
> >> > >
> >> > > I believe what we will need is the ability for the merchant to push
> >> some
> >> > > data (certificates and a signed message from the acquirer) to the
> >> > > cardholder
> >> > > wallet who will use that data to authenticate the merchant. If that
> >> can be
> >> > > accomplished with the existing authentication transaction then I
> >> believe
> >> > > your change will satisfy our needs.
> >> > >
> >> > > However, there may be other issues behind the input from Hitachi so
> >> > > Yoshiaki
> >> > > should also respond.
> >> > >
> >> > > Tony
> >> > > > ----------
> >> > > > From: David Burdett[SMTP:[email-masked]]
> >> > > > Sent: Thursday, April 29, 1999 4:00 PM
> >> > > > To: Yoshiaki KAWATSURA
> >> > > > Cc: Ietf Trade WG
> >> > > > Subject: RE: Question for IOTP Authentication
> >> > > >
> >> > > > Yoshiaki
> >> > > >
> >> > > > As you can see I'm catching up on all the Trade WG emails and
> have
> >> > > thought
> >> > > > about your suggestion. In principle I can see why allowing a
> >> Consumer to
> >> > > > authenticate a Merchant is reasonable as, in the current version
> of
> >> the
> >> > > > specification, it states that a Conumer can authenticate a
> Payment
> >> > > Handler
> >> > > > or a Delivery Handler (see section 8.1.13 second bullet point)
> and
> >> > > > therefore
> >> > > > it is logical that a Consumer should also be able to authenticate
> a
> >> > > > Merchant.
> >> > > >
> >> > > > However the method you suggest below for authenticating a
> Merchant
> >> is
> >> > > > different from the way the Consumer authenticates a Payment
> Handler
> >> or
> >> > > > Delivery Handler in that it is integrated into the transaction
> (e.g
> >> a
> >> > > > purchase) which implies a further variation on the message flow.
> So,
> >> I
> >> > > > suggest that we meet your requirement by simply changing the
> first
> >> > > bullet
> >> > > > point in section 8.1.13 to read the authentication transaction
> can
> >> be
> >> > > used
> >> > > > ... " by a Consumer to authenticate a *Merchant*, Payment Handler
> or
> >> a
> >> > > > Delivery Handler ..."
> >> > > >
> >> > > > Is this OK?
> >> > > >
> >> > > > David
> >> > > >
> >> > > >
> >> > > > > ----------
> >> > > > > From: Yoshiaki KAWATSURA[SMTP:[email-masked]]
> >> > > > > Sent: 29 March 1999 22:45
> >> > > > > To: [email-masked]
> >> > > > > Cc: [email-masked]; [email-masked];
> >> > > > [email-masked];
> >> > > > > [email-masked]
> >> > > > > Subject: RE: Question for IOTP Authentication
> >> > > > >
> >> > > > > David,
> >> > > > > I agree with your suggestion.
> >> > > > > But I also want to add the Merchant Authenticaton by Consumer
> >> > > > > prior to IOTP Purchase Transaction.
> >> > > > >
> >> > > > > These are the same flow as follows,
> >> > > > >
> >> > > > > Consumer             Merchant
> >> > > > >    <-------------------
> >> > > > >          TPO
> >> > > > >
> >> > > > >    ------------------->
> >> > > > >       Auth Req
> >> > > > >
> >> > > > >    <------------------
> >> > > > >       Auth Res
> >> > > > >
> >> > > > > and Status Block is not sent to the Merchant.
> >> > > > >
> >> > > > > After Consumer receives the Auth Response,
> >> > > > > 1. If prior to IOTP purchase transaction
> >> > > > > Success: Consumer sends the message to the Success NetLocation.
> >> > > > > Fail: Stop
> >> > > > >
> >> > > > > 2. If in the IOTP Purchase Transaction
> >> > > > > Success: Continue the transaction
> >> > > > > Fail: Stop.
> >> > > > >
> >> > > > > Make sense?
> >> > > > >
> >> > > > > This is minor change and I think there is no affect in the IOTP
> >> > > > protocol.
> >> > > > > Regards,
> >> > > > > ----
> >> > > > > Yoshiaki Kawatsura : E-mail [email-masked]
> >> > > > >  Business & Information Systems Development Devision,
> Hitachi,Ltd.
> >> > > > > Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
> >> > > > >
> >> > > > >
> >> > > > >  >>>>> Fri, 26 Mar 1999 18:20:48 -0000,
> >> > > > > David Burdett <[email-masked]> said:
> >> > > > >
> >> > > > >  >Yoshiaki
> >> > > > >  >
> >> > > > >  >The current version of IOTP does not support authentication
> of
> >> the
> >> > > > > Merchant
> >> > > > >  >by the Consumer. Part of the reasoning behind this is that
> the
> >> > > > Merchant
> >> > > > > will
> >> > > > >  >include a signature in the offer which can be used for this
> >> purpose.
> >> > > > >  >HOwever, as you say, the consumer might not want to give
> address
> >> > > > > information
> >> > > > >  >until they have authenticated the Merchant.
> >> > > > >  >
> >> > > > >  >You could actually do this although section 8.1.13 does not
> >> > > > specifically
> >> > > > >  >state this. What would be requried is that, after the
> Consumer
> >> has
> >> > > > > received
> >> > > > >  >the TPO, he authenticates the merchant with a separate
> >> > > Authentication
> >> > > > >  >transaction and then if its  OK continues with the original
> >> > > > transaction.
> >> > > > >  >
> >> > > > >  >Would this make sense? If you think it does then please post
> the
> >> > > idea
> >> > > > to
> >> > > > > the
> >> > > > >  >list. I don't know though if we want to include this in v1.0
> >> > > although
> >> > > > it
> >> > > > >  >could easily go into v 2.0
> >> > > > >  >
> >> > > > >  >David
> >> > > > >  >
> >> > > > >  >> ----------
> >> > > > >  >> From: Yoshiaki KAWATSURA[SMTP:[email-masked]]
> >> > > > >  >> Sent: 25 March 1999 22:46
> >> > > > >  >> To: [email-masked]; [email-masked];
> >> > > > > [email-masked]
> >> > > > >  >> Cc: [email-masked]
> >> > > > >  >> Subject: Question for IOTP Authentication
> >> > > > >  >>
> >> > > > >  >> Don and David,
> >> > > > >  >> I have a couple of question for IOTP Authentication.
> >> > > > >  >>
> >> > > > >  >> Consumer wants to send private information such as home
> >> address to
> >> > > > >  >> authenticated merchants only for Offer. In fact, SET is
> >> attempting
> >> > > > to
> >> > > > >  >> support simliar functionality. I believe that IOTP should
> >> support
> >> > > > > this.
> >> > > > >  >>
> >> > > > >  >> IOTP version 1.0 cannot do this function in Offer Exchange,
> >> since
> >> > > > the
> >> > > > >  >> Offer Exchange is simplified. The idea would be that
> initially
> >> > > IOTP
> >> > > > >  >> processes an Authentication, then a Web browser sends a
> >> private
> >> > > > >  >> information for Offer, and finally IOTP does Purchase
> >> Transaction.
> >> > > > In
> >> > > > >  >> IOTP version 1.0, IOTP supports a Consumer Authentication
> by
> >> > > > Merchant,
> >> > > > >  >> however, IOTP does not support a Merchant Authentication by
> >> > > > >  >> Consumer. Is this correct?
> >> > > > >  >>
> >> > > > >  >> If this is correct, will IOTP version 2.0 support the
> Merchant
> >> > > > >  >> Authentication by Consumer?
> >> > > > >  >>
> >> > > > >  >> Regards,
> >> > > > >  >>
> >> > > > >  >> --
> >> > > > >  >> Yoshiaki Kawatsura
> >> > > > >  >> Hitachi, Ltd.
> >> > > > >  >>
> >> > > > >  >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> > >
> >>
> **************************************************************************
> >> > > > ********************
> >> > > >
> >> > > > This Email and any attached files are confidential and may also
> be
> >> > > > privileged.
> >> > > > If you are not the intended recipient, please notify the
> postmaster
> >> > > using
> >> > > > email
> >> > > > address [email-masked] or call +44 171 557 5000 and ask
> for
> >> the
> >> > > > IT Helpdesk.  You should not copy this email and any attached
> files,
> >> use
> >> > > > them
> >> > > > for any purpose or disclose the contents to any other person; all
> >> copies
> >> > > > of the
> >> > > > Email and associated files in your possession should be
> destroyed.
> >> > > >
> >> > > > Mondex International Limited
> >> > > > 47-53 Cannon Street
> >> > > > London EC4M 5SQ
> >> > > > United Kingdom
> >> > > > Registered No: 3122085, England
> >> > > >
> >> > > > Phone:          +44 171 557 5000
> >> > > > Fax:            +44 171 557 5200
> >> > > > Email:          [email-masked]
> >> > > > WebSite:        http://www.mondexinternational.com
> >> > > >
> >> > > >
> >> > >
> >>
> **************************************************************************
> >> > > > *******************
> >> > > >
> >> -----------------------------------------------------------------------
> >> > > > Message addressed to: [email-masked]
> >> > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> >> > > > To (un)subscribe send a message with "subscribe" or "unsubscribe"
> in
> >> the
> >> > > > body to: [email-masked]
> >> > > >
> >> > >
> >> -----------------------------------------------------------------------
> >> > > Message addressed to: [email-masked]
> >> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> >> > > To (un)subscribe send a message with "subscribe" or "unsubscribe"
> in
> >> the
> >> > > body to: [email-masked]
> >> > >
> >> >
> >> >
> >>
> **************************************************************************
> >> ********************
> >> >
> >> > This Email and any attached files are confidential and may also be
> >> privileged.
> >> > If you are not the intended recipient, please notify the postmaster
> >> using email
> >> > address [email-masked] or call +44 171 557 5000 and ask for
> the
> >> > IT Helpdesk.  You should not copy this email and any attached files,
> use
> >> them
> >> > for any purpose or disclose the contents to any other person; all
> copies
> >> of the
> >> > Email and associated files in your possession should be destroyed.
> >> >
> >> > Mondex International Limited
> >> > 47-53 Cannon Street
> >> > London EC4M 5SQ
> >> > United Kingdom
> >> > Registered No: 3122085, England
> >> >
> >> > Phone:          +44 171 557 5000
> >> > Fax:            +44 171 557 5200
> >> > Email:          [email-masked]
> >> > WebSite:        http://www.mondexinternational.com
> >> >
> >> >
> >>
> **************************************************************************
> >> *******************
> >> >
> >>
> >-----------------------------------------------------------------------
> >Message addressed to: [email-masked]
> >Archive available at: http://www.elistx.com/archives/ietf-trade/
> >To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> >body to: [email-masked]
> >
> 
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Lewis, Tony" <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: Brand IDs & their registration. Was: RE: Comments on draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
Date: Tue, 4 May 1999 17:09:25 -0700 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

In fact, Europay, MasterCard, and Visa have established EMVCo. (EMVCo does
not currently have a web site so I can't point you there. I'm told the site
won't be up until July.)

EMV does not have brands in the same way that SET or IOTP do. EMV deals with
application identifiers or AIDs. An AID consists of two parts: a Registered
ID (RID) obtained from ISO and a Proprietary Extension (PIX). The RID is
roughly analogous to a brand. For example, Visa has an RID with a value of
0xA000000003. Visa then assigns PIX values for various applications, e.g.,
Credit/Debit, VisaCash, etc.

Typically, an RID will be obtained by a payment brand, but there is no
guarantee that there is a one to one correspondence between a brand and a
RID.

As we look at a way to integrate EMV cards with SET, we expect to add AIDs
to the SET Initiation message, which will ultimately be replaced by IOTP.

Tony
> ----------
> From: 	Steve Fabes[SMTP:[email-masked]]
> Sent: 	Tuesday, May 04, 1999 10:33 AM
> To: 	[email-masked]; Ietf Trade WG
> Subject: 	Re: Brand IDs & their registration. Was: RE: Comments on
> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> 
> Donald, I do not have much to add but when looking at the actions of SETCo
> we should also anticipate that the EMV world will establish EMVCo and its
> rules will need to be considered along side those of SETCo's. The
> membership
> of the two Co's will overlap but be different and to assume the same brand
> and operating rules may be optimistic.
> -----Original Message-----
> From: [email-masked] <[email-masked]>
> To: Ietf Trade WG <[email-masked]>
> Date: Tuesday, May 04, 1999 09:33
> Subject: RE: Brand IDs & their registration. Was: RE: Comments on
> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> 
> 
> >Regardless of EMV or whatever, it seems to me that we have a "brand"
> registry
> >problem to solve.  Credit/Debit cards are sort of odd creatures because
> they can
> >be used in payments via multiple different protocols.  Most stored value
> cards
> >can be used via only a single protocol.
> >
> >SETco clearly operates a card brand regisgration operations, however
> limited and
> >even if it's only expressed in the brand level certificates that SETco
> allows to
> >be created under its root.  I think the hope was that the SET
> registration
> could
> >be used in IOTP for all credit/debit cards.  This would at least avoid
> the
> >problem where some brand was registered under different names at
> different
> >registries (where "different" could just be things like whether there is
> really
> >a space between American and Express or whether the C is capitalized in
> >Mastercard or whether Visa is all caps, ...).  Is there a list of bands
> >officially supported by SETco and their official names?
> >
> >However, if SETco is inappropriate for this, because they won't
> "register"
> >brands that haven't joined", then we need a separate solution.  It
> certainly
> >isn't very difficult to set up regsitration via IANA, probably using the
> same
> >Designated Expert criteria being used for other things.  The only
> difficulty I
> >can see is that some brand might get registered there for IOTP use and
> then
> >later join SETco or otherwise get registered in some other system under
> some
> >other name.  Various messyness with Discover/Novus, AT&T Universal Card
> changing
> >to CitiBank Universal Card and the like occur to me.  I'm not sure those
> cases
> >are actually name change problems but one can image such.
> >
> >All this seems to imply that we need to be prepared to register
> credit/debit
> >card brands under "IOTP:".  I'm a bit reluctant to drop the "SET:" branch
> of the
> >brand tree in IOTP.  If some brand exists under SETco but hasn't yet been
> >registered under IOTP, it seems like it should be usable.  Of course,
> this
> means
> >that some brand registered under IOTP could later join SETco and could
> exist as
> >both IOTP:BrandX and SET:BrandX or SET:Brand-ex.  So you might get into
> >equivalence tables but these are really just an artifact of the real
> world
> being
> >messy and not particularly worse than brands splitting or merging.
> >
> >I don't see a major problem with us using
> brand:[product]:[promotional-name] if
> >we want, even after "SET:", although we should make it clear in that case
> that
> >these values differ from those permitted in the SET protocol.  The other
> >possibility that occurs to me would be to use brand[:product] and have a
> >separate [promotional=xxx] optional attribute.
> >
> >What do people think?
> >
> >Thanks,
> >Donald
> >
> >Donald E. Eastlake, 3rd
> >17 Skyline Drive, Hawthorne, NY 10532 USA
> >[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
> >
> >home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
> >[email-masked]   tel: 1-914-276-2668
> >
> >
> >
> >David Burdett <[email-masked]> on 04/29/99 12:17:01 PM
> >
> >To:   Ietf Trade WG <[email-masked]>
> >cc:   "Lewis, Tony" <[email-masked]> (bcc: Donald
> Eastlake/Hawthorne/IBM)
> >Subject:  RE: Brand IDs & their registration. Was: RE: Comments on
> draft-ie
> >      tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> >
> >
> >
> >
> >
> >I agree with Tony. Smart card based EMV transactions will be the dominant
> >payment model within a decade, probably even earlier especially in the
> >non-US part of the world. The main reasons being, in my view:
> >*    it will reduce fraud as it's much much harder to copy a smart card
> >than a mag stripe card
> >*    it makes internet credit card payments "card present" transactions
> >which should result in lower merchant fees. This also means that it will
> be
> >much harder for customers to claim they never made an internet purchase
> >*    using a multi-application smart card you will be able to use just
> >one smart card for debit, credit, electronic cash, a loyalty scheme as
> well
> >as hold electronic tickets for anything from local cinema to your next
> >flight.
> >
> >To rephrase a MasterCard ad line, "smart cards are the future of money".
> >
> >David
> >
> >> ----------
> >> From:   Lewis, Tony[SMTP:[email-masked]]
> >> Sent:   28 April 1999 20:30
> >> To:     Ietf Trade WG
> >> Subject:     RE: Brand IDs & their registration. Was: RE: Comments on
> >> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> >>
> >> My point is that the brand is "Visa" no matter whether using IOTP, SET
> or
> >> any other protocol.
> >>
> >> As for EMV, the very first live SET 1.0 transaction was made using an
> EMV
> >> card with the EMV data carried inside a SET message extension. EMV
> credit
> >> and debit products are a significant part of the future of electronic
> >> commerce. I expect they will be the dominant model for payment in a
> >> decade.
> >>
> >> Tony
> >> > ----------
> >> > From:      Steve Fabes[SMTP:[email-masked]]
> >> > Sent:      Wednesday, April 28, 1999 3:43 PM
> >> > To:   Lewis, Tony; Ietf Trade WG
> >> > Subject:   Re: Brand IDs & their registration. Was: RE: Comments on
> >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> >> >
> >> > Tony - do your comments infer that SET.Visa will be the only
> e-Commerce
> >> > product that an IOTP product supplier can expect to see. Can you see
> a
> >> day
> >> > when a Visa EMV 3.1.1 (or 3.x.x) based credit product could also be
> used
> >> > inside an IOTP product?
> >> > -----Original Message-----
> >> > From: Lewis, Tony <[email-masked]>
> >> > To: Ietf Trade WG <[email-masked]>
> >> > Date: Wednesday, April 28, 1999 13:21
> >> > Subject: RE: Brand IDs & their registration. Was: RE: Comments on
> >> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> >> >
> >> >
> >> > >David,
> >> > >
> >> > >I am new to this group and do not know what lead to the current
> >> approach.
> >> > >There are undoubtedly some issues that I don't know about. However,
> it
> >> > seems
> >> > >to me that a brand is a brand no matter what payment protocol is
> being
> >> > used.
> >> > >The only difference I see between "IOTP:Visa" and "SET:Visa" is that
> >> the
> >> > >latter indicates that the brand is supported by a specific payment
> >> > protocol.
> >> > >Since you need to support brands other than those supported by SET,
> >> there
> >> > >will need to be a registry. It seems to me that there should only be
> >> one
> >> > >such registry rather than the two being proposed. I recommend having
> a
> >> > >single domain for these brands. It seems reasonable to initially
> >> populate
> >> > it
> >> > >using the brands registered with SET and those non-SET brands you
> >> listed
> >> > in
> >> > >your note.
> >> > >
> >> > >Tony
> >> > >> ----------
> >> > >> From: David Burdett[SMTP:[email-masked]]
> >> > >> Sent: Wednesday, April 28, 1999 11:36 AM
> >> > >> To: Ietf Trade WG; Lewis, Tony
> >> > >> Subject: Brand IDs & their registration. Was: RE: Comments on
> >> > >> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> >> > >>
> >> > >> In the current specification the basic idea for identifying brands
> is
> >> > that
> >> > >> they should be of the form "xxx:brandid" where "xxx" can be "SET"
> >> which
> >> > >> indicates that the brandid is any valid brandid that is accepted
> by
> >> > SET,
> >> > >> or
> >> > >> alternatively "IOTP" which can be used to define any brand not
> >> defined
> >> > by
> >> > >> SET. The idea was that we should not need to define "Visa",
> >> > "MasterCard",
> >> > >> "American Express", etc more than once since they are already
> defined
> >> > and
> >> > >> registered by SET.
> >> > >>
> >> > >> However a couple of problems may arise ...
> >> > >>
> >> > >> USING THE SET BRAND ID FOR NON-SET PAYMENTS
> >> > >> Although IOTP can support SET as a payment protocol, it can also
> >> > support
> >> > >> credit card payments (using Secure Channel Credit Debit - SCCD)
> where
> >> > the
> >> > >> credit card information (no, name, expiration date, etc) is coded
> >> > >> effectively in the clear but with privacy protection provided by
> >> using
> >> > a
> >> > >> secure channel such as SSL. In this way it provides a similar
> level
> >> of
> >> > >> privacy/security as for credit card payments that occur now where
> a
> >> web
> >> > >> page
> >> > >> form is completed by the user.
> >> > >>
> >> > >> My question is, will it be reasonable to use the SET brandid in
> this
> >> > way
> >> > >> to
> >> > >> cover non-SET credit card payments. I *think* the answer is "yes"
> as
> >> > you
> >> > >> can
> >> > >> quite imagine a situation where a consumer is offered a choice of
> >> using
> >> > >> their VISA credit card to pay using either SET or SCCD.
> >> > >>
> >> > >> WHAT BRAND ID SHOULD BE USED FOR CO BRANDS
> >> > >> If a payment brand, such as a local brand or co-brand, chooses,
> >> > initiall
> >> > >> to
> >> > >> use just SCCD rather than SET then they would not (I think) need
> to
> >> > >> register
> >> > >> their brand with SET. In this case, they might register their
> brand
> >> as
> >> > an
> >> > >> "IOTP" brand. However if they later adopted SET, they would end up
> >> with
> >> > >> potentially two equivalent Brand IDs. Do you think we might be
> better
> >> > off
> >> > >> with a straight IOTP brand and keep all the names under the
> >> procedures
> >> > >> defined by IANA? I'm not sure?
> >> > >>
> >> > >> REGISTERING NEW BRAND IDs
> >> > >> To help assist in answering the last point, the following is what
> I'm
> >> > >> currently writing as the proposed IANA procedure for registering
> new
> >> > brand
> >> > >> ids. Any comments:
> >> > >>
> >> > >> >>>Clip>>>
> >> > >> The format of the Brand ID is either:
> >> > >> * SET:setbrand where setbrand is a brand which is accepted by the
> >> > >> [SET] payment protocol
> >> > >> * IOTP:iotpbrand where iotpbrand may be:
> >> > >> - GeldKarte
> >> > >> - Mondex
> >> > >>
> >> > >> New values of the high level prefix (SET or IOTP) should be
> allocated
> >> > >> following review on the IETF Trade Working Group mailing list and
> by
> >> > the
> >> > >> Designated Expert.
> >> > >>
> >> > >> Values of "setbrand" are allocated as defined in the [SET]
> >> > specifications.
> >> > >>
> >> > >> New values of "iotpbrand" must be announced to the IETF Trade WG
> >> > mailing
> >> > >> list and, if there are no objections within three weeks, be
> allocated
> >> > on
> >> > a
> >> > >> "first come first served" basis.
> >> > >> <<<End Clip<<<
> >> > >>
> >> > >> Regards
> >> > >>
> >> > >> David
> >> > >> > ----------
> >> > >> > From: Lewis, Tony[SMTP:[email-masked]]
> >> > >> > Sent: 28 April 1999 08:14
> >> > >> > To: Ietf Trade WG
> >> > >> > Subject: RE: Comments on
> >> draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> >> > >> > part  1
> >> > >> >
> >> > >> > In SET, the BrandID is either "brand" or "brand:product".
> >> > >> >
> >> > >> > In Japan, there are products that are co-branded. Essentially
> these
> >> > >> > products
> >> > >> > are private label cards for domestic transactions with an
> >> > international
> >> > >> > brand for non-domestic transactions. The private label can be
> >> > reflected
> >> > >> in
> >> > >> > a
> >> > >> > SET cardholder certificate as the "promotional card name" under
> the
> >> > >> > international brand's hierarchy and/or the cardholder can have a
> >> > >> > certificate
> >> > >> > issued under the private label hierarchy.
> >> > >> >
> >> > >> > There is no provision to carry both the private label (of the
> >> > Japanese
> >> > >> > credit card company) and the international brand as part of the
> SET
> >> > >> > BrandID.
> >> > >> >
> >> > >> > Tony
> >
> >
> >-----------------------------------------------------------------------
> >Message addressed to: [email-masked]
> >Archive available at: http://www.elistx.com/archives/ietf-trade/
> >To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> >body to: [email-masked]
> >
> 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: Steve Fabes <[email-masked]>
To: "Lewis, Tony" <[email-masked]>
Cc: Ietf Trade WG <[email-masked]>
Subject: Re: Question for IOTP Authentication
Date: Tue, 4 May 1999 15:27:54 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

What would this do to the txn time and number of messages going across?
-----Original Message-----
From: Lewis, Tony <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, May 03, 1999 12:20
Subject: RE: Question for IOTP Authentication

>Yes, this authentication is performed prior to the shopping phase, but
can't
>it be processed as a null payment and use both IOTP and SET authentication
>mechanisms?
>
>Tony
>> ----------
>> From: Yoshiaki KAWATSURA[SMTP:[email-masked]]
>> Sent: Sunday, May 02, 1999 8:19 AM
>> To: [email-masked]
>> Cc: Lewis, Tony; [email-masked]; [email-masked]
>> Subject: RE: Question for IOTP Authentication
>>
>> Tony mentioned to me the Mercahnt authentication has to do prior to
>> shopping phase, this is out of IOTP. So we can use separete
>> authentication only.
>>
>> We need to define the SET Specific authentication, which
>> satisfy the requirement to the BAG Requirement, in SETCo.  because
>> consumer have to confirm whether Merchant is authorized by the
>> Acquirer and this requirement is payment dependent(IOTP is the payment
>> scheme independent messaging protocol).
>>
>> I believe that the merit of using IOTP authentication is that we
>> can be concerned IOTP Authentication transaction with IOTP
>> Purchase transaction.
>>
>> --
>> Yoshiaki Kawatsura Hitachi, Ltd.
>>
>>
>>
>> >>>>> Fri, 30 Apr 1999 20:04:11 +0100,
>> David Burdett <[email-masked]> said:
>>
>> > Tony
>> >
>> > I can think of three ways that IOTP might be able to meet the
>> requirement
>> > you describe:
>> > * using the Packaged Content element in the Pay Protocol element (see
>> > section 6.6.4),
>> > * the Consumer authenticates the Merchant separately using an
>> > authentication transaction, or
>> > * a combination of the two.
>> >
>> > Each is discussed in a bit more detail below.
>> >
>> > PAY PROTOCOL ELEMENT
>> > This involves the merchant including the relevent certificate and
>> message
>> > from the acquirer in the PackagedContent element in the Pay Protocol
>> element
>> > for SET of the Brand List (see spec section  6.6.4), then if the
>> Consumer
>> > wants to use SET for a payment they just pass the data to the SET
>> payment
>> > software working within IOTP which then checks the credentials.
>> >
>> > The advantage of this approach is that the certificate will always be
>> there
>> > and no extra messages will be required to retrieve it. The disadvantage
>> is
>> > that it increases the size of the messages.
>> >
>> > SEPARATE CONSUMER AUTHENTICATION OF THE MERCHANT
>> > In this case, the SET software recognises that there a certificate and
>> > message from the acquirer is needed and makes a request to the IOTP
>> software
>> > to obtain it. When this need occurs, a separate IOTP Authentication
>> > Transaction (see spec section 8.1.6) is used to get the information.
>> >
>> > This would involve:
>> > * the Consumer sending an IOTPAuthentication Request message to the
>> > merchant specifying in the Algorithm element that the Merchant should
>> do,
>> > for example, a SET merchant authentication, then
>> > * the Merchant replying with a Authentication Response message
>> > including the necessary certificate and acquirer message in the
Packaged
>> > Content.
>> >
>> > COMBINATION
>> > An alternative might be to include some fingerprint of the
>> > certificate/message in the PayProtocol element, so that the consumer
SET
>> > software can check if it already has a copy of it. If it hasn't then a
>> > separate consumer initiated IOTP Athentication of the merchant could be
>> used
>> > to obtain it.
>> >
>> > Does this make sense?
>> >
>> > David
>> >
>> >
>> >
>> > > ----------
>> > > From: Lewis, Tony[SMTP:[email-masked]]
>> > > Sent: 29 April 1999 17:36
>> > > To: Yoshiaki KAWATSURA
>> > > Cc: Ietf Trade WG
>> > > Subject: RE: Question for IOTP Authentication
>> > >
>> > > David,
>> > >
>> > > I believe this proposal originates from requirements that SETCo has
>> > > defined
>> > > for SET 2.0 although when we discussed the approach outlined by
>> Yoshiaki
>> > > at
>> > > our meeting last week, we recommended some changes.
>> > >
>> > > I believe what we will need is the ability for the merchant to push
>> some
>> > > data (certificates and a signed message from the acquirer) to the
>> > > cardholder
>> > > wallet who will use that data to authenticate the merchant. If that
>> can be
>> > > accomplished with the existing authentication transaction then I
>> believe
>> > > your change will satisfy our needs.
>> > >
>> > > However, there may be other issues behind the input from Hitachi so
>> > > Yoshiaki
>> > > should also respond.
>> > >
>> > > Tony
>> > > > ----------
>> > > > From: David Burdett[SMTP:[email-masked]]
>> > > > Sent: Thursday, April 29, 1999 4:00 PM
>> > > > To: Yoshiaki KAWATSURA
>> > > > Cc: Ietf Trade WG
>> > > > Subject: RE: Question for IOTP Authentication
>> > > >
>> > > > Yoshiaki
>> > > >
>> > > > As you can see I'm catching up on all the Trade WG emails and have
>> > > thought
>> > > > about your suggestion. In principle I can see why allowing a
>> Consumer to
>> > > > authenticate a Merchant is reasonable as, in the current version of
>> the
>> > > > specification, it states that a Conumer can authenticate a Payment
>> > > Handler
>> > > > or a Delivery Handler (see section 8.1.13 second bullet point) and
>> > > > therefore
>> > > > it is logical that a Consumer should also be able to authenticate a
>> > > > Merchant.
>> > > >
>> > > > However the method you suggest below for authenticating a Merchant
>> is
>> > > > different from the way the Consumer authenticates a Payment Handler
>> or
>> > > > Delivery Handler in that it is integrated into the transaction (e.g
>> a
>> > > > purchase) which implies a further variation on the message flow.
So,
>> I
>> > > > suggest that we meet your requirement by simply changing the first
>> > > bullet
>> > > > point in section 8.1.13 to read the authentication transaction can
>> be
>> > > used
>> > > > ... " by a Consumer to authenticate a *Merchant*, Payment Handler
or
>> a
>> > > > Delivery Handler ..."
>> > > >
>> > > > Is this OK?
>> > > >
>> > > > David
>> > > >
>> > > >
>> > > > > ----------
>> > > > > From: Yoshiaki KAWATSURA[SMTP:[email-masked]]
>> > > > > Sent: 29 March 1999 22:45
>> > > > > To: [email-masked]
>> > > > > Cc: [email-masked]; [email-masked];
>> > > > [email-masked];
>> > > > > [email-masked]
>> > > > > Subject: RE: Question for IOTP Authentication
>> > > > >
>> > > > > David,
>> > > > > I agree with your suggestion.
>> > > > > But I also want to add the Merchant Authenticaton by Consumer
>> > > > > prior to IOTP Purchase Transaction.
>> > > > >
>> > > > > These are the same flow as follows,
>> > > > >
>> > > > > Consumer             Merchant
>> > > > >    <-------------------
>> > > > >          TPO
>> > > > >
>> > > > >    ------------------->
>> > > > >       Auth Req
>> > > > >
>> > > > >    <------------------
>> > > > >       Auth Res
>> > > > >
>> > > > > and Status Block is not sent to the Merchant.
>> > > > >
>> > > > > After Consumer receives the Auth Response,
>> > > > > 1. If prior to IOTP purchase transaction
>> > > > > Success: Consumer sends the message to the Success NetLocation.
>> > > > > Fail: Stop
>> > > > >
>> > > > > 2. If in the IOTP Purchase Transaction
>> > > > > Success: Continue the transaction
>> > > > > Fail: Stop.
>> > > > >
>> > > > > Make sense?
>> > > > >
>> > > > > This is minor change and I think there is no affect in the IOTP
>> > > > protocol.
>> > > > > Regards,
>> > > > > ----
>> > > > > Yoshiaki Kawatsura : E-mail [email-masked]
>> > > > >  Business & Information Systems Development Devision,
Hitachi,Ltd.
>> > > > > Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
>> > > > >
>> > > > >
>> > > > >  >>>>> Fri, 26 Mar 1999 18:20:48 -0000,
>> > > > > David Burdett <[email-masked]> said:
>> > > > >
>> > > > >  >Yoshiaki
>> > > > >  >
>> > > > >  >The current version of IOTP does not support authentication of
>> the
>> > > > > Merchant
>> > > > >  >by the Consumer. Part of the reasoning behind this is that the
>> > > > Merchant
>> > > > > will
>> > > > >  >include a signature in the offer which can be used for this
>> purpose.
>> > > > >  >HOwever, as you say, the consumer might not want to give
address
>> > > > > information
>> > > > >  >until they have authenticated the Merchant.
>> > > > >  >
>> > > > >  >You could actually do this although section 8.1.13 does not
>> > > > specifically
>> > > > >  >state this. What would be requried is that, after the Consumer
>> has
>> > > > > received
>> > > > >  >the TPO, he authenticates the merchant with a separate
>> > > Authentication
>> > > > >  >transaction and then if its  OK continues with the original
>> > > > transaction.
>> > > > >  >
>> > > > >  >Would this make sense? If you think it does then please post
the
>> > > idea
>> > > > to
>> > > > > the
>> > > > >  >list. I don't know though if we want to include this in v1.0
>> > > although
>> > > > it
>> > > > >  >could easily go into v 2.0
>> > > > >  >
>> > > > >  >David
>> > > > >  >
>> > > > >  >> ----------
>> > > > >  >> From: Yoshiaki KAWATSURA[SMTP:[email-masked]]
>> > > > >  >> Sent: 25 March 1999 22:46
>> > > > >  >> To: [email-masked]; [email-masked];
>> > > > > [email-masked]
>> > > > >  >> Cc: [email-masked]
>> > > > >  >> Subject: Question for IOTP Authentication
>> > > > >  >>
>> > > > >  >> Don and David,
>> > > > >  >> I have a couple of question for IOTP Authentication.
>> > > > >  >>
>> > > > >  >> Consumer wants to send private information such as home
>> address to
>> > > > >  >> authenticated merchants only for Offer. In fact, SET is
>> attempting
>> > > > to
>> > > > >  >> support simliar functionality. I believe that IOTP should
>> support
>> > > > > this.
>> > > > >  >>
>> > > > >  >> IOTP version 1.0 cannot do this function in Offer Exchange,
>> since
>> > > > the
>> > > > >  >> Offer Exchange is simplified. The idea would be that
initially
>> > > IOTP
>> > > > >  >> processes an Authentication, then a Web browser sends a
>> private
>> > > > >  >> information for Offer, and finally IOTP does Purchase
>> Transaction.
>> > > > In
>> > > > >  >> IOTP version 1.0, IOTP supports a Consumer Authentication by
>> > > > Merchant,
>> > > > >  >> however, IOTP does not support a Merchant Authentication by
>> > > > >  >> Consumer. Is this correct?
>> > > > >  >>
>> > > > >  >> If this is correct, will IOTP version 2.0 support the
Merchant
>> > > > >  >> Authentication by Consumer?
>> > > > >  >>
>> > > > >  >> Regards,
>> > > > >  >>
>> > > > >  >> --
>> > > > >  >> Yoshiaki Kawatsura
>> > > > >  >> Hitachi, Ltd.
>> > > > >  >>
>> > > > >  >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>>
**************************************************************************
>> > > > ********************
>> > > >
>> > > > This Email and any attached files are confidential and may also be
>> > > > privileged.
>> > > > If you are not the intended recipient, please notify the postmaster
>> > > using
>> > > > email
>> > > > address [email-masked] or call +44 171 557 5000 and ask for
>> the
>> > > > IT Helpdesk.  You should not copy this email and any attached
files,
>> use
>> > > > them
>> > > > for any purpose or disclose the contents to any other person; all
>> copies
>> > > > of the
>> > > > Email and associated files in your possession should be destroyed.
>> > > >
>> > > > Mondex International Limited
>> > > > 47-53 Cannon Street
>> > > > London EC4M 5SQ
>> > > > United Kingdom
>> > > > Registered No: 3122085, England
>> > > >
>> > > > Phone:          +44 171 557 5000
>> > > > Fax:            +44 171 557 5200
>> > > > Email:          [email-masked]
>> > > > WebSite:        http://www.mondexinternational.com
>> > > >
>> > > >
>> > >
>>
**************************************************************************
>> > > > *******************
>> > > >
>> -----------------------------------------------------------------------
>> > > > Message addressed to: [email-masked]
>> > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
>> > > > To (un)subscribe send a message with "subscribe" or "unsubscribe"
in
>> the
>> > > > body to: [email-masked]
>> > > >
>> > >
>> -----------------------------------------------------------------------
>> > > Message addressed to: [email-masked]
>> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
>> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
>> the
>> > > body to: [email-masked]
>> > >
>> >
>> >
>>
**************************************************************************
>> ********************
>> >
>> > This Email and any attached files are confidential and may also be
>> privileged.
>> > If you are not the intended recipient, please notify the postmaster
>> using email
>> > address [email-masked] or call +44 171 557 5000 and ask for the
>> > IT Helpdesk.  You should not copy this email and any attached files,
use
>> them
>> > for any purpose or disclose the contents to any other person; all
copies
>> of the
>> > Email and associated files in your possession should be destroyed.
>> >
>> > Mondex International Limited
>> > 47-53 Cannon Street
>> > London EC4M 5SQ
>> > United Kingdom
>> > Registered No: 3122085, England
>> >
>> > Phone:          +44 171 557 5000
>> > Fax:            +44 171 557 5200
>> > Email:          [email-masked]
>> > WebSite:        http://www.mondexinternational.com
>> >
>> >
>>
**************************************************************************
>> *******************
>> >
>>
>-----------------------------------------------------------------------
>Message addressed to: [email-masked]
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: [email-masked]
>

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: Steve Fabes <[email-masked]>
To: [email-masked], Ietf Trade WG <[email-masked]>
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Subject: Re: Brand IDs & their registration. Was: RE: Comments on draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
Date: Tue, 4 May 1999 10:33:51 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Donald, I do not have much to add but when looking at the actions of SETCo
we should also anticipate that the EMV world will establish EMVCo and its
rules will need to be considered along side those of SETCo's. The membership
of the two Co's will overlap but be different and to assume the same brand
and operating rules may be optimistic.
-----Original Message-----
From: [email-masked] <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Date: Tuesday, May 04, 1999 09:33
Subject: RE: Brand IDs & their registration. Was: RE: Comments on
draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1

>Regardless of EMV or whatever, it seems to me that we have a "brand"
registry
>problem to solve.  Credit/Debit cards are sort of odd creatures because
they can
>be used in payments via multiple different protocols.  Most stored value
cards
>can be used via only a single protocol.
>
>SETco clearly operates a card brand regisgration operations, however
limited and
>even if it's only expressed in the brand level certificates that SETco
allows to
>be created under its root.  I think the hope was that the SET registration
could
>be used in IOTP for all credit/debit cards.  This would at least avoid the
>problem where some brand was registered under different names at different
>registries (where "different" could just be things like whether there is
really
>a space between American and Express or whether the C is capitalized in
>Mastercard or whether Visa is all caps, ...).  Is there a list of bands
>officially supported by SETco and their official names?
>
>However, if SETco is inappropriate for this, because they won't "register"
>brands that haven't joined", then we need a separate solution.  It
certainly
>isn't very difficult to set up regsitration via IANA, probably using the
same
>Designated Expert criteria being used for other things.  The only
difficulty I
>can see is that some brand might get registered there for IOTP use and then
>later join SETco or otherwise get registered in some other system under
some
>other name.  Various messyness with Discover/Novus, AT&T Universal Card
changing
>to CitiBank Universal Card and the like occur to me.  I'm not sure those
cases
>are actually name change problems but one can image such.
>
>All this seems to imply that we need to be prepared to register
credit/debit
>card brands under "IOTP:".  I'm a bit reluctant to drop the "SET:" branch
of the
>brand tree in IOTP.  If some brand exists under SETco but hasn't yet been
>registered under IOTP, it seems like it should be usable.  Of course, this
means
>that some brand registered under IOTP could later join SETco and could
exist as
>both IOTP:BrandX and SET:BrandX or SET:Brand-ex.  So you might get into
>equivalence tables but these are really just an artifact of the real world
being
>messy and not particularly worse than brands splitting or merging.
>
>I don't see a major problem with us using
brand:[product]:[promotional-name] if
>we want, even after "SET:", although we should make it clear in that case
that
>these values differ from those permitted in the SET protocol.  The other
>possibility that occurs to me would be to use brand[:product] and have a
>separate [promotional=xxx] optional attribute.
>
>What do people think?
>
>Thanks,
>Donald
>
>Donald E. Eastlake, 3rd
>17 Skyline Drive, Hawthorne, NY 10532 USA
>[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
>
>home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
>[email-masked]   tel: 1-914-276-2668
>
>
>
>David Burdett <[email-masked]> on 04/29/99 12:17:01 PM
>
>To:   Ietf Trade WG <[email-masked]>
>cc:   "Lewis, Tony" <[email-masked]> (bcc: Donald Eastlake/Hawthorne/IBM)
>Subject:  RE: Brand IDs & their registration. Was: RE: Comments on draft-ie
>      tf-t rade-iotp-v1.0-protocol-03.txt, part  1
>
>
>
>
>
>I agree with Tony. Smart card based EMV transactions will be the dominant
>payment model within a decade, probably even earlier especially in the
>non-US part of the world. The main reasons being, in my view:
>*    it will reduce fraud as it's much much harder to copy a smart card
>than a mag stripe card
>*    it makes internet credit card payments "card present" transactions
>which should result in lower merchant fees. This also means that it will be
>much harder for customers to claim they never made an internet purchase
>*    using a multi-application smart card you will be able to use just
>one smart card for debit, credit, electronic cash, a loyalty scheme as well
>as hold electronic tickets for anything from local cinema to your next
>flight.
>
>To rephrase a MasterCard ad line, "smart cards are the future of money".
>
>David
>
>> ----------
>> From:   Lewis, Tony[SMTP:[email-masked]]
>> Sent:   28 April 1999 20:30
>> To:     Ietf Trade WG
>> Subject:     RE: Brand IDs & their registration. Was: RE: Comments on
>> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part  1
>>
>> My point is that the brand is "Visa" no matter whether using IOTP, SET or
>> any other protocol.
>>
>> As for EMV, the very first live SET 1.0 transaction was made using an EMV
>> card with the EMV data carried inside a SET message extension. EMV credit
>> and debit products are a significant part of the future of electronic
>> commerce. I expect they will be the dominant model for payment in a
>> decade.
>>
>> Tony
>> > ----------
>> > From:      Steve Fabes[SMTP:[email-masked]]
>> > Sent:      Wednesday, April 28, 1999 3:43 PM
>> > To:   Lewis, Tony; Ietf Trade WG
>> > Subject:   Re: Brand IDs & their registration. Was: RE: Comments on
>> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
>> >
>> > Tony - do your comments infer that SET.Visa will be the only e-Commerce
>> > product that an IOTP product supplier can expect to see. Can you see a
>> day
>> > when a Visa EMV 3.1.1 (or 3.x.x) based credit product could also be
used
>> > inside an IOTP product?
>> > -----Original Message-----
>> > From: Lewis, Tony <[email-masked]>
>> > To: Ietf Trade WG <[email-masked]>
>> > Date: Wednesday, April 28, 1999 13:21
>> > Subject: RE: Brand IDs & their registration. Was: RE: Comments on
>> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
>> >
>> >
>> > >David,
>> > >
>> > >I am new to this group and do not know what lead to the current
>> approach.
>> > >There are undoubtedly some issues that I don't know about. However, it
>> > seems
>> > >to me that a brand is a brand no matter what payment protocol is being
>> > used.
>> > >The only difference I see between "IOTP:Visa" and "SET:Visa" is that
>> the
>> > >latter indicates that the brand is supported by a specific payment
>> > protocol.
>> > >Since you need to support brands other than those supported by SET,
>> there
>> > >will need to be a registry. It seems to me that there should only be
>> one
>> > >such registry rather than the two being proposed. I recommend having a
>> > >single domain for these brands. It seems reasonable to initially
>> populate
>> > it
>> > >using the brands registered with SET and those non-SET brands you
>> listed
>> > in
>> > >your note.
>> > >
>> > >Tony
>> > >> ----------
>> > >> From: David Burdett[SMTP:[email-masked]]
>> > >> Sent: Wednesday, April 28, 1999 11:36 AM
>> > >> To: Ietf Trade WG; Lewis, Tony
>> > >> Subject: Brand IDs & their registration. Was: RE: Comments on
>> > >> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
>> > >>
>> > >> In the current specification the basic idea for identifying brands
is
>> > that
>> > >> they should be of the form "xxx:brandid" where "xxx" can be "SET"
>> which
>> > >> indicates that the brandid is any valid brandid that is accepted by
>> > SET,
>> > >> or
>> > >> alternatively "IOTP" which can be used to define any brand not
>> defined
>> > by
>> > >> SET. The idea was that we should not need to define "Visa",
>> > "MasterCard",
>> > >> "American Express", etc more than once since they are already
defined
>> > and
>> > >> registered by SET.
>> > >>
>> > >> However a couple of problems may arise ...
>> > >>
>> > >> USING THE SET BRAND ID FOR NON-SET PAYMENTS
>> > >> Although IOTP can support SET as a payment protocol, it can also
>> > support
>> > >> credit card payments (using Secure Channel Credit Debit - SCCD)
where
>> > the
>> > >> credit card information (no, name, expiration date, etc) is coded
>> > >> effectively in the clear but with privacy protection provided by
>> using
>> > a
>> > >> secure channel such as SSL. In this way it provides a similar level
>> of
>> > >> privacy/security as for credit card payments that occur now where a
>> web
>> > >> page
>> > >> form is completed by the user.
>> > >>
>> > >> My question is, will it be reasonable to use the SET brandid in this
>> > way
>> > >> to
>> > >> cover non-SET credit card payments. I *think* the answer is "yes" as
>> > you
>> > >> can
>> > >> quite imagine a situation where a consumer is offered a choice of
>> using
>> > >> their VISA credit card to pay using either SET or SCCD.
>> > >>
>> > >> WHAT BRAND ID SHOULD BE USED FOR CO BRANDS
>> > >> If a payment brand, such as a local brand or co-brand, chooses,
>> > initiall
>> > >> to
>> > >> use just SCCD rather than SET then they would not (I think) need to
>> > >> register
>> > >> their brand with SET. In this case, they might register their brand
>> as
>> > an
>> > >> "IOTP" brand. However if they later adopted SET, they would end up
>> with
>> > >> potentially two equivalent Brand IDs. Do you think we might be
better
>> > off
>> > >> with a straight IOTP brand and keep all the names under the
>> procedures
>> > >> defined by IANA? I'm not sure?
>> > >>
>> > >> REGISTERING NEW BRAND IDs
>> > >> To help assist in answering the last point, the following is what
I'm
>> > >> currently writing as the proposed IANA procedure for registering new
>> > brand
>> > >> ids. Any comments:
>> > >>
>> > >> >>>Clip>>>
>> > >> The format of the Brand ID is either:
>> > >> * SET:setbrand where setbrand is a brand which is accepted by the
>> > >> [SET] payment protocol
>> > >> * IOTP:iotpbrand where iotpbrand may be:
>> > >> - GeldKarte
>> > >> - Mondex
>> > >>
>> > >> New values of the high level prefix (SET or IOTP) should be
allocated
>> > >> following review on the IETF Trade Working Group mailing list and by
>> > the
>> > >> Designated Expert.
>> > >>
>> > >> Values of "setbrand" are allocated as defined in the [SET]
>> > specifications.
>> > >>
>> > >> New values of "iotpbrand" must be announced to the IETF Trade WG
>> > mailing
>> > >> list and, if there are no objections within three weeks, be
allocated
>> > on
>> > a
>> > >> "first come first served" basis.
>> > >> <<<End Clip<<<
>> > >>
>> > >> Regards
>> > >>
>> > >> David
>> > >> > ----------
>> > >> > From: Lewis, Tony[SMTP:[email-masked]]
>> > >> > Sent: 28 April 1999 08:14
>> > >> > To: Ietf Trade WG
>> > >> > Subject: RE: Comments on
>> draft-ietf-trade-iotp-v1.0-protocol-03.txt,
>> > >> > part  1
>> > >> >
>> > >> > In SET, the BrandID is either "brand" or "brand:product".
>> > >> >
>> > >> > In Japan, there are products that are co-branded. Essentially
these
>> > >> > products
>> > >> > are private label cards for domestic transactions with an
>> > international
>> > >> > brand for non-domestic transactions. The private label can be
>> > reflected
>> > >> in
>> > >> > a
>> > >> > SET cardholder certificate as the "promotional card name" under
the
>> > >> > international brand's hierarchy and/or the cardholder can have a
>> > >> > certificate
>> > >> > issued under the private label hierarchy.
>> > >> >
>> > >> > There is no provision to carry both the private label (of the
>> > Japanese
>> > >> > credit card company) and the international brand as part of the
SET
>> > >> > BrandID.
>> > >> >
>> > >> > Tony
>
>
>-----------------------------------------------------------------------
>Message addressed to: [email-masked]
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: [email-masked]
>

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: Ietf Trade WG <[email-masked]>
Date: Tue, 4 May 1999 12:04:01 -0400
Subject: RE: Brand IDs & their registration. Was: RE: Comments on draft -ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Regardless of EMV or whatever, it seems to me that we have a "brand" registry
problem to solve.  Credit/Debit cards are sort of odd creatures because they can
be used in payments via multiple different protocols.  Most stored value cards
can be used via only a single protocol.

SETco clearly operates a card brand regisgration operations, however limited and
even if it's only expressed in the brand level certificates that SETco allows to
be created under its root.  I think the hope was that the SET registration could
be used in IOTP for all credit/debit cards.  This would at least avoid the
problem where some brand was registered under different names at different
registries (where "different" could just be things like whether there is really
a space between American and Express or whether the C is capitalized in
Mastercard or whether Visa is all caps, ...).  Is there a list of bands
officially supported by SETco and their official names?

However, if SETco is inappropriate for this, because they won't "register"
brands that haven't joined", then we need a separate solution.  It certainly
isn't very difficult to set up regsitration via IANA, probably using the same
Designated Expert criteria being used for other things.  The only difficulty I
can see is that some brand might get registered there for IOTP use and then
later join SETco or otherwise get registered in some other system under some
other name.  Various messyness with Discover/Novus, AT&T Universal Card changing
to CitiBank Universal Card and the like occur to me.  I'm not sure those cases
are actually name change problems but one can image such.

All this seems to imply that we need to be prepared to register credit/debit
card brands under "IOTP:".  I'm a bit reluctant to drop the "SET:" branch of the
brand tree in IOTP.  If some brand exists under SETco but hasn't yet been
registered under IOTP, it seems like it should be usable.  Of course, this means
that some brand registered under IOTP could later join SETco and could exist as
both IOTP:BrandX and SET:BrandX or SET:Brand-ex.  So you might get into
equivalence tables but these are really just an artifact of the real world being
messy and not particularly worse than brands splitting or merging.

I don't see a major problem with us using brand:[product]:[promotional-name] if
we want, even after "SET:", although we should make it clear in that case that
these values differ from those permitted in the SET protocol.  The other
possibility that occurs to me would be to use brand[:product] and have a
separate [promotional=xxx] optional attribute.

What do people think?

Thanks,
Donald

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
[email-masked]   tel: 1-914-276-2668

David Burdett <[email-masked]> on 04/29/99 12:17:01 PM

To:   Ietf Trade WG <[email-masked]>
cc:   "Lewis, Tony" <[email-masked]> (bcc: Donald Eastlake/Hawthorne/IBM)
Subject:  RE: Brand IDs & their registration. Was: RE: Comments on draft-ie
      tf-t rade-iotp-v1.0-protocol-03.txt, part  1

I agree with Tony. Smart card based EMV transactions will be the dominant
payment model within a decade, probably even earlier especially in the
non-US part of the world. The main reasons being, in my view:
*    it will reduce fraud as it's much much harder to copy a smart card
than a mag stripe card
*    it makes internet credit card payments "card present" transactions
which should result in lower merchant fees. This also means that it will be
much harder for customers to claim they never made an internet purchase
*    using a multi-application smart card you will be able to use just
one smart card for debit, credit, electronic cash, a loyalty scheme as well
as hold electronic tickets for anything from local cinema to your next
flight.

To rephrase a MasterCard ad line, "smart cards are the future of money".

David

> ----------
> From:   Lewis, Tony[SMTP:[email-masked]]
> Sent:   28 April 1999 20:30
> To:     Ietf Trade WG
> Subject:     RE: Brand IDs & their registration. Was: RE: Comments on
> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part  1
>
> My point is that the brand is "Visa" no matter whether using IOTP, SET or
> any other protocol.
>
> As for EMV, the very first live SET 1.0 transaction was made using an EMV
> card with the EMV data carried inside a SET message extension. EMV credit
> and debit products are a significant part of the future of electronic
> commerce. I expect they will be the dominant model for payment in a
> decade.
>
> Tony
> > ----------
> > From:      Steve Fabes[SMTP:[email-masked]]
> > Sent:      Wednesday, April 28, 1999 3:43 PM
> > To:   Lewis, Tony; Ietf Trade WG
> > Subject:   Re: Brand IDs & their registration. Was: RE: Comments on
> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> >
> > Tony - do your comments infer that SET.Visa will be the only e-Commerce
> > product that an IOTP product supplier can expect to see. Can you see a
> day
> > when a Visa EMV 3.1.1 (or 3.x.x) based credit product could also be used
> > inside an IOTP product?
> > -----Original Message-----
> > From: Lewis, Tony <[email-masked]>
> > To: Ietf Trade WG <[email-masked]>
> > Date: Wednesday, April 28, 1999 13:21
> > Subject: RE: Brand IDs & their registration. Was: RE: Comments on
> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> >
> >
> > >David,
> > >
> > >I am new to this group and do not know what lead to the current
> approach.
> > >There are undoubtedly some issues that I don't know about. However, it
> > seems
> > >to me that a brand is a brand no matter what payment protocol is being
> > used.
> > >The only difference I see between "IOTP:Visa" and "SET:Visa" is that
> the
> > >latter indicates that the brand is supported by a specific payment
> > protocol.
> > >Since you need to support brands other than those supported by SET,
> there
> > >will need to be a registry. It seems to me that there should only be
> one
> > >such registry rather than the two being proposed. I recommend having a
> > >single domain for these brands. It seems reasonable to initially
> populate
> > it
> > >using the brands registered with SET and those non-SET brands you
> listed
> > in
> > >your note.
> > >
> > >Tony
> > >> ----------
> > >> From: David Burdett[SMTP:[email-masked]]
> > >> Sent: Wednesday, April 28, 1999 11:36 AM
> > >> To: Ietf Trade WG; Lewis, Tony
> > >> Subject: Brand IDs & their registration. Was: RE: Comments on
> > >> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > >>
> > >> In the current specification the basic idea for identifying brands is
> > that
> > >> they should be of the form "xxx:brandid" where "xxx" can be "SET"
> which
> > >> indicates that the brandid is any valid brandid that is accepted by
> > SET,
> > >> or
> > >> alternatively "IOTP" which can be used to define any brand not
> defined
> > by
> > >> SET. The idea was that we should not need to define "Visa",
> > "MasterCard",
> > >> "American Express", etc more than once since they are already defined
> > and
> > >> registered by SET.
> > >>
> > >> However a couple of problems may arise ...
> > >>
> > >> USING THE SET BRAND ID FOR NON-SET PAYMENTS
> > >> Although IOTP can support SET as a payment protocol, it can also
> > support
> > >> credit card payments (using Secure Channel Credit Debit - SCCD) where
> > the
> > >> credit card information (no, name, expiration date, etc) is coded
> > >> effectively in the clear but with privacy protection provided by
> using
> > a
> > >> secure channel such as SSL. In this way it provides a similar level
> of
> > >> privacy/security as for credit card payments that occur now where a
> web
> > >> page
> > >> form is completed by the user.
> > >>
> > >> My question is, will it be reasonable to use the SET brandid in this
> > way
> > >> to
> > >> cover non-SET credit card payments. I *think* the answer is "yes" as
> > you
> > >> can
> > >> quite imagine a situation where a consumer is offered a choice of
> using
> > >> their VISA credit card to pay using either SET or SCCD.
> > >>
> > >> WHAT BRAND ID SHOULD BE USED FOR CO BRANDS
> > >> If a payment brand, such as a local brand or co-brand, chooses,
> > initiall
> > >> to
> > >> use just SCCD rather than SET then they would not (I think) need to
> > >> register
> > >> their brand with SET. In this case, they might register their brand
> as
> > an
> > >> "IOTP" brand. However if they later adopted SET, they would end up
> with
> > >> potentially two equivalent Brand IDs. Do you think we might be better
> > off
> > >> with a straight IOTP brand and keep all the names under the
> procedures
> > >> defined by IANA? I'm not sure?
> > >>
> > >> REGISTERING NEW BRAND IDs
> > >> To help assist in answering the last point, the following is what I'm
> > >> currently writing as the proposed IANA procedure for registering new
> > brand
> > >> ids. Any comments:
> > >>
> > >> >>>Clip>>>
> > >> The format of the Brand ID is either:
> > >> * SET:setbrand where setbrand is a brand which is accepted by the
> > >> [SET] payment protocol
> > >> * IOTP:iotpbrand where iotpbrand may be:
> > >> - GeldKarte
> > >> - Mondex
> > >>
> > >> New values of the high level prefix (SET or IOTP) should be allocated
> > >> following review on the IETF Trade Working Group mailing list and by
> > the
> > >> Designated Expert.
> > >>
> > >> Values of "setbrand" are allocated as defined in the [SET]
> > specifications.
> > >>
> > >> New values of "iotpbrand" must be announced to the IETF Trade WG
> > mailing
> > >> list and, if there are no objections within three weeks, be allocated
> > on
> > a
> > >> "first come first served" basis.
> > >> <<<End Clip<<<
> > >>
> > >> Regards
> > >>
> > >> David
> > >> > ----------
> > >> > From: Lewis, Tony[SMTP:[email-masked]]
> > >> > Sent: 28 April 1999 08:14
> > >> > To: Ietf Trade WG
> > >> > Subject: RE: Comments on
> draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> > >> > part  1
> > >> >
> > >> > In SET, the BrandID is either "brand" or "brand:product".
> > >> >
> > >> > In Japan, there are products that are co-branded. Essentially these
> > >> > products
> > >> > are private label cards for domestic transactions with an
> > international
> > >> > brand for non-domestic transactions. The private label can be
> > reflected
> > >> in
> > >> > a
> > >> > SET cardholder certificate as the "promotional card name" under the
> > >> > international brand's hierarchy and/or the cardholder can have a
> > >> > certificate
> > >> > issued under the private label hierarchy.
> > >> >
> > >> > There is no provision to carry both the private label (of the
> > Japanese
> > >> > credit card company) and the international brand as part of the SET
> > >> > BrandID.
> > >> >
> > >> > Tony

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: Ietf Trade WG <[email-masked]>
Date: Tue, 4 May 1999 10:37:32 -0400
Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, part  1
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Only a few rejoinders.  See @@@...

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
[email-masked]   tel: 1-914-276-2668

David Burdett <[email-masked]> on 04/29/99 07:00:50 PM

To:   Ietf Trade WG <[email-masked]>, Donald Eastlake/Hawthorne/IBM@IBMUS
cc:
Subject:  RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, part  1

I have responded to Don's comments with comments marked with ###. I have
also recently sent out separate emails on a number of topics which perhaps
warrant more discussion.

David

> ----------
> From:   [email-masked][SMTP:[email-masked]]
> Sent:   22 April 1999 15:25
> To:     [email-masked]
> Subject:     Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, part
> 1
>
> I've done a careful review of the document through section 6 and section
> 13
> and greater and came up with the following somewhat length list of
> suggestions.  I don't think they substantially change the intended meaning
> of the document but those on the list should judge that.
>
>
> IMPORTANT:
>
> "IANA Considerations" needs to be a top level section, perhaps #11.
> Gathering this stuff together into 3.7.3 is good but its still
> unreasonable
> to expect IANA to comb the document to find it.
### Agreed. Move section 3.7.3 to a new section 11 IANA Considerations.###
>      I'm not sure about the criteria for registration.  "IETF Consensus"
> is
> pretty stiff and requires a vote of the IESG.  I should think someone
> could
> register an IOTP Brand or CurrCode by publishing an RFC.  Perhaps that is
> what you mean for ProtocolId but it is not clear.
### Agreed. See separate email.###
>      Toward end so 3.7.3, change "with" to "without".
### Agreed

> MISCELLANEOUS:
>
> I don't understand the difference between "Objectives" and "Purpose".  I
> suggest that 1.4 and 1.5 be merged
###Agreed
> and that the reference to "IOTP Business
> Description" which, as far as I know, is not intended to ever become an
> IETF document, be dropped.
###Agreed

> Section 1.7 still refers to an XML Overview section 11.
###Change to refer to IANA considerations

> Page spanning figures, like Figure 3, are really pretty messy.  It would
> be
> better if the text could be made much more terse and this and similar
> figures started high on a page so they aren't split by a page boundary.
### Not sure. See separate email ###

> Section 2.2: suggest "The Open Trading Protocols identify" be changed to
> "IOTP identifies".
### Agreed. Also suggest changing Open Trading Protocol to Internet Open
Trading Protocol in sections: 1.4,1.6, 8, 12 (heading & DTD)###

> Section 2.2: says "IOTP Transactions are composed of these exchanges" but
> does not list Inquiry or Ping exchange.
###This is deliberate. The Inquiry and Ping exchange are not "trading
exchanges" as they are used primarily to to ensure that messages are
exchanged correctly or to determine the current status of a transaction.###

> Starting in section 2.3 and many other places in the document, words or
> phrases are prefixed and suffixed by an underscore character ("_").  This
> is not any normal IETF style.  I suspect it means that the original text
> is
> italic.  These should be suppressed or if that is impossible, a separate
> pass should be done to delete them.
###These seem to be caused by either a non-breakable dash or "smart quotes"
in MS Word being miss-translated when the document is converted to text.
Will fix in next version.###

> In Figure 9, the things which are supposed to be identical or match aren't
> and don't.  Is that deliberate?
### No. Its a mistake. They should be the same. Will be fixed.###

> I don't think that section 3.6 Brands and Brand Selection fits very well
> where it and suggest it be moved into section 10 which could be renamed
> "Brands".
###Agreed. A good idea.###
>      Continuing on Brands, I looked around a bit in SET literature and
> couldn't find anything about Dual or Promotional brands or anything about
> a
> three component SET Brand.  Two components, "brand" and "product" I see in
> the SET literature, such a "MasterCard" or "Visa:Gold".  But not A:B:C and
> no case where a colon is included if there isn't anything after it.  In
> other words, it's "Visa", not "Visa:", and certainly not "Visa::" as a SET
> brand (re also examples in 6.6.1). Can anyone give me any references to
> shed light on this?
### I think this arose as a result of a japanes requirement. See separate
email###

> Section 3.8.1: I don't understand why sub-pages of an HTML main page
> couldn't have links back to the main page.
### Disagree. See separate email.###

@@@ I'll reply to the separate mail.

> Section 4.1: first section reference says "0"?
###Agreed. Will fix.###

> Figures 10 and 11: These flow diagrams each *almost* fit on a page. If the
> initial "Input IOTP Message" box could be to the side with a horizontal
> arrow and the text were edited down to something a bit more terse, I think
> they would, which would be quite helpful.
### See response to comments about figure 3, and separate email###

> Section 5: Suggest this section be called "Digital Signature" or
> something.
> Usually an IETF Security Considerations section is brief and talks about
> really high level issues.  Material in 5.4 is appropriate for Security
> Considerations.  A separate Security Considerations section would need to
> also say something about deciding when to require signatures, even if it
> is
> just by referring to section 5.1.4, and about depending on payment scheme
> security for the safety of funds, which I didn't see anywhere.
>      Section 5 seems pretty heavy on certificates and public key crypto,
> especially given the originally IOTP v1.0 was going to be secret key only
> and, as I recall, it was with some reluctance that public key hooks were
> added.  The stuff on checking a signature, for example, talks about
> checking the certificate as if there always has to be one.
>      Section 5.1.4: another reason you might not need signatures is the
> that the sender and receiver were on the same machine so it can check
> integrity just by comparing with a saved copy.
### I suggest quite a few changes here specifically:
*    renumber section 5 (and all later sections) as section 6 and rename
as "Digital Signatures and IOTP"
*    insert a new section 5 called "Security Considerations" which is
focussed on the types of IETF security considerations Don describes above.
Specifically including: why you might want (or not want) to use signatures;
use of asymmetric and symmetric cryptography; privacy, and payment protocol
security###

@@@ OK.

> Section 6.4.2: Need to eliminate reference to "Open Trading Protocol
> Consortium" and suggest dropping whole note.
### Agreed ###
> I don't see any difference at all between OkTo/OkFrom and amount.  Both
> could appear in human readable
> form in the Order Description and in machine readable form in their
> element.  Recommending that the UI display the machine readable version is
> reasonable (as in 6.4.1).
### I think the note should remain but include suggestion that the OkFrom
and OkTo dates are displayed to the consumer.###

@@@ Sure.  That would be a good way to handle it.

> ContentSoftwareId: the standard text given for this is quite length and
> repeated dozens of time.  If it could be moved to the glossary or
> something
> and a simple "see glossary" put in, it would save many pages.
### Agreed ###

> As previously discussed, change ISO4217 to ISO4217A or the like.
### Suggest change to ISO4217-A. See other email.###

> Just before section 6.7, it says that examples exist in 6.6 when they are
> in 10.
### Agreed. Will fix ###

> Section 6.17: references to the Richard Brown draft and probably not
> appropriate.  RFCs are not supposed to refer to drafts.  About the future,
> I'm not sure you need to say anything but if you do, I think it should
> just
> say the future versions of IOTP will use industry standard XML signature
> technology if it meets IOTP requirements.
### Agreed will change to refer to IOTP Dsig paper and use of standard XML
signature technology in the future###

>      Shouldn't 6.17.1 refer to the IOTP DSIG document?  It's OK to refer
> to
> that draft because the idea is that it and the main protocol document will
> be issued as RFCs simultaneously.  Maybe the XMLDSIG reference should just
> be changed to refer to the IOTP DSIG document.
### ALL references to XMLDSIG shall be changed to reflect IOTPDSIG
instead.###

>      There is a reference in  6.17.1 to payment scheme specific
> algorithms.
> Wouldn't their use be encapsulated inside the packaged contents and be in
> the payment scheme modules, not an IOTP implementation itself?
### Not necessarily. For example a Mondex purse application on a smart card
can be used to authenticate an individual using cryptography on the smart
card chip. This means that the "Algorithm" used for authenticatiojn purposes
could potentially be: SHA1, a digital signature, or a payment protocol
specific algorithm. Therefore suggest no change.###

@@@ Ahhh, OK.

>      Section 6.18: similarly for certificate reference.  Should point out
> that certs not needed for symmetric keying or for cases where public key
> has been registered at recipient.
### Agreed ###

> Section 6.19.2: For ElContIllegal, ValueTooSmall, and ValueTooLarge, I
> believe it should say "content" rather than "PackagedContent".
### Agreed ###

> TRIVIAL NITS:
>
> In the Abstract and section 1, Delivery Handler is capitalized but payment
> handler isn't.
### Agreed ###

> It is not usual to have a section like 1.7, History, in an IETF document.
> If the evolution of a protocol sheds light on its technical content,
> that's
> one thing.  But it is not usual to have what is mostly a list of editing
> versions.  Suggest it be dropped to shorten the document.
### Agreed ###

> I'm not sure why there is a skip to new page before section 3.1 or 3.1.2.
> Suggest dropping these to make the document more compact.  RFC style is to
> have no skips to the start of a new page anywhere in the body text.
### This was caused by keeping figure 6 together with the immediately
preceeding lines. ###

> Section 3.8 example packaged content:  I don't like the "Name"s FirstMsg
> and SecondMsg.  Using Msg => Message seems confusing.  Suggest FirstPiece
> and SecondPiece.
### Changed ###

> Section 3.10 says "Where both types of net location are present, the
> following rules apply:" and then gives three rules only the third of which
> applies in the described circumstances.  Suggest moving the first two up
> and combining the quoted phrase with the third.
### Agreed ###

> Section 3.11.1 "treated by the recipient is an error": is -> as
### Fixed ###

> Section 4: "There are a several ..." delete "a"
### Fixed ###

> Section 4.4.1.2: in first sentence has -> have.
### Agreed ###

> Section 4.4.2.9: in first sentence, insert "server" between "the" and
> "unless".
> ### Agreed ###
>
> Not sure why skip to new page before section 5.3.1 shortly before Figure
> 14
> which overflows onto next page by just one line...
### Fixed ###

> Section 5.3.1.1: numbered subsections, lettered subsubsections:  The text
> at the ends of these 12 subsubsections is substantially the same.
> Starting
> with 3)b) sometimes the final period is omitted.  Suggest moving this text
> up to the numbered section level or to before the whole two level list.
### Tidied up ###

> Section 5.3.1.2: ditto 5.3.1.1 except list is one level.
### Ditto ###

> Section 6.1: towards the end, delete "the" from "that the should".
### Fixed ###

> Section 6.2: Insert "may be" after "there" in "there only one".
### Fixed ###

> Section 6.5.5: PostalCode missing from detailed attributes list.
### Fixed ###

> Just before 6.6.3 and 6.7.1: "in10" -> "in section 10".
### Fixed ###

> Suggest replacing occurrences of "SSL" with "SSL/TLS" and adding the TLS
> RFC to the References.
### Agreed ###

> Section 6.11:  has "Plain/Text" where other similar sentences use "Plain
> Text" which is probably better.  The "/" makes it look like a MIME type
> and
> the MIME type is actually text/plain.  But I would suggest not using the
> MIME type as there isn't a unique one for HTML.
### Agreed ###

> Section 6.12.1: DelivReqNetLocn & SecDelivReqNotLocn: "Mechanism must" ->
> "Mechanism and must".
### Agreed ###

> Section 6.13: Content, should be "PackagedContent" not "Delivery Note".
### Agreed ###

> REFERENCES (section 14)
>
> For DOM-HASH, can't refer to any Internet-Drafts by URL or filename.  For
> HMAC, suggest refereing to RFC 2104 HMAC: Keyed-Hashing for Message
> Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997.
>
> It looks pretty odd to the IETF spelled out in the RFC references.  I've
> never seen that in an IETF document references section.
>
> For SET, suggest referencing the SETco.org site, not Mastercard.  Can't
> reference the Brown XMLDSIG draft in an RFC (although you can talk about
> it
> without a URL or file name reference if necessary).
>
>
> Donald E. Eastlake, 3rd
> 17 Skyline Drive, Hawthorne, NY 10532 USA
> [email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
>
> home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
> [email-masked]   tel: 1-914-276-2668

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Lewis, Tony" <[email-masked]>
To: ietf-trade <[email-masked]>
Subject: RE: Question for IOTP Authentication
Date: Tue, 4 May 1999 08:20:38 -0700 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,

I'm replying to the list since the answer to your off-list question to me is
likely to be of general interest.

We are looking for a way to support an "Authenticate Me" button on a
merchant web site. When this button is clicked, it will invoke the SET
wallet, which will validate the merchant certificate, the payment gateway
certificate and a special signed message. If the validation is successful,
the wallet will then display a message indicating that this is a valid SET
merchant.

The flow would be something like this:

Click: "Authenticate Me"

<--- Authentication Wake up
---> PInitReq
<--- PInitRes

Wallet: "This is a valid SET merchant."

I'm suggesting that IOTP can be used for the wake up if we treat this as a
"null" payment (one where the payment phase is elided).

By the way, "BAG" is the "SETCo Business Advisors Group", which will hold
its first meeting next week.

Tony
> ----------
> From: 	David Burdett[SMTP:[email-masked]]
> Sent: 	Monday, May 03, 1999 3:00 PM
> To: 	Lewis, Tony
> Subject: 	RE: Question for IOTP Authentication
> 
> Tony
> 
> I don't quite understand what Yoshiaki is talking about in his email. When
> he refers to the BAG requirement, what does he mean? I also don't quite
> understand how a "null" payment could be used as part of the solution as
> you
> describe.
> 
> It's just that I'm trying to understand the requirement so that I can see
> how IOTP could meet the need.
> 
> Clarification will be greatly appreciated.
> 
> David
> 
> 
> 
> > ----------
> > From: 	Lewis, Tony[SMTP:[email-masked]]
> > Sent: 	03 May 1999 11:50
> > To: 	[email-masked]
> > Subject: 	RE: Question for IOTP Authentication
> > 
> > Yes, this authentication is performed prior to the shopping phase, but
> > can't
> > it be processed as a null payment and use both IOTP and SET
> authentication
> > mechanisms?
> > 
> > Tony
> > > ----------
> > > From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> > > Sent: 	Sunday, May 02, 1999 8:19 AM
> > > To: 	[email-masked]
> > > Cc: 	Lewis, Tony; [email-masked];
> > [email-masked]
> > > Subject: 	RE: Question for IOTP Authentication
> > > 
> > > Tony mentioned to me the Mercahnt authentication has to do prior to
> > > shopping phase, this is out of IOTP. So we can use separete
> > > authentication only.
> > > 
> > > We need to define the SET Specific authentication, which
> > > satisfy the requirement to the BAG Requirement, in SETCo.  because
> > > consumer have to confirm whether Merchant is authorized by the
> > > Acquirer and this requirement is payment dependent(IOTP is the payment
> > > scheme independent messaging protocol).
> > > 
> > > I believe that the merit of using IOTP authentication is that we
> > > can be concerned IOTP Authentication transaction with IOTP
> > > Purchase transaction.
> > > 
> > > --
> > > Yoshiaki Kawatsura Hitachi, Ltd.
> > > 
> > > 
> > > 
> > > >>>>> Fri, 30 Apr 1999 20:04:11 +0100,
> > > 	David Burdett <[email-masked]> said:
> > > 
> > > > Tony
> > > > 
> > > > I can think of three ways that IOTP might be able to meet the
> > > requirement
> > > > you describe:
> > > > *	using the Packaged Content element in the Pay Protocol
> element (see
> > > > section 6.6.4),
> > > > *	the Consumer authenticates the Merchant separately using an
> > > > authentication transaction, or 
> > > > *	a combination of the two.
> > > > 
> > > > Each is discussed in a bit more detail below.
> > > > 
> > > > PAY PROTOCOL ELEMENT
> > > > This involves the merchant including the relevent certificate and
> > > message
> > > > from the acquirer in the PackagedContent element in the Pay Protocol
> > > element
> > > > for SET of the Brand List (see spec section  6.6.4), then if the
> > > Consumer
> > > > wants to use SET for a payment they just pass the data to the SET
> > > payment
> > > > software working within IOTP which then checks the credentials.
> > > > 
> > > > The advantage of this approach is that the certificate will always
> be
> > > there
> > > > and no extra messages will be required to retrieve it. The
> > disadvantage
> > > is
> > > > that it increases the size of the messages.
> > > > 
> > > > SEPARATE CONSUMER AUTHENTICATION OF THE MERCHANT
> > > > In this case, the SET software recognises that there a certificate
> and
> > > > message from the acquirer is needed and makes a request to the IOTP
> > > software
> > > > to obtain it. When this need occurs, a separate IOTP Authentication
> > > > Transaction (see spec section 8.1.6) is used to get the information.
> 
> > > > 
> > > > This would involve:
> > > > *	the Consumer sending an IOTPAuthentication Request message
> to the
> > > > merchant specifying in the Algorithm element that the Merchant
> should
> > > do,
> > > > for example, a SET merchant authentication, then
> > > > *	the Merchant replying with a Authentication Response message
> > > > including the necessary certificate and acquirer message in the
> > Packaged
> > > > Content.
> > > > 
> > > > COMBINATION
> > > > An alternative might be to include some fingerprint of the
> > > > certificate/message in the PayProtocol element, so that the consumer
> > SET
> > > > software can check if it already has a copy of it. If it hasn't then
> a
> > > > separate consumer initiated IOTP Athentication of the merchant could
> > be
> > > used
> > > > to obtain it.
> > > > 
> > > > Does this make sense?
> > > > 
> > > > David
> > > > 
> > > > 
> > > > 
> > > > > ----------
> > > > > From: 	Lewis, Tony[SMTP:[email-masked]]
> > > > > Sent: 	29 April 1999 17:36
> > > > > To: 	Yoshiaki KAWATSURA
> > > > > Cc: 	Ietf Trade WG
> > > > > Subject: 	RE: Question for IOTP Authentication
> > > > > 
> > > > > David,
> > > > > 
> > > > > I believe this proposal originates from requirements that SETCo
> has
> > > > > defined
> > > > > for SET 2.0 although when we discussed the approach outlined by
> > > Yoshiaki
> > > > > at
> > > > > our meeting last week, we recommended some changes.
> > > > > 
> > > > > I believe what we will need is the ability for the merchant to
> push
> > > some
> > > > > data (certificates and a signed message from the acquirer) to the
> > > > > cardholder
> > > > > wallet who will use that data to authenticate the merchant. If
> that
> > > can be
> > > > > accomplished with the existing authentication transaction then I
> > > believe
> > > > > your change will satisfy our needs.
> > > > > 
> > > > > However, there may be other issues behind the input from Hitachi
> so
> > > > > Yoshiaki
> > > > > should also respond.
> > > > > 
> > > > > Tony
> > > > > > ----------
> > > > > > From: 	David Burdett[SMTP:[email-masked]]
> > > > > > Sent: 	Thursday, April 29, 1999 4:00 PM
> > > > > > To: 	Yoshiaki KAWATSURA
> > > > > > Cc: 	Ietf Trade WG
> > > > > > Subject: 	RE: Question for IOTP Authentication
> > > > > > 
> > > > > > Yoshiaki
> > > > > > 
> > > > > > As you can see I'm catching up on all the Trade WG emails and
> have
> > > > > thought
> > > > > > about your suggestion. In principle I can see why allowing a
> > > Consumer to
> > > > > > authenticate a Merchant is reasonable as, in the current version
> > of
> > > the
> > > > > > specification, it states that a Conumer can authenticate a
> Payment
> > > > > Handler
> > > > > > or a Delivery Handler (see section 8.1.13 second bullet point)
> and
> > > > > > therefore
> > > > > > it is logical that a Consumer should also be able to
> authenticate
> > a
> > > > > > Merchant.
> > > > > > 
> > > > > > However the method you suggest below for authenticating a
> Merchant
> > > is
> > > > > > different from the way the Consumer authenticates a Payment
> > Handler
> > > or
> > > > > > Delivery Handler in that it is integrated into the transaction
> > (e.g
> > > a
> > > > > > purchase) which implies a further variation on the message flow.
> > So,
> > > I
> > > > > > suggest that we meet your requirement by simply changing the
> first
> > > > > bullet
> > > > > > point in section 8.1.13 to read the authentication transaction
> can
> > > be
> > > > > used
> > > > > > ... " by a Consumer to authenticate a *Merchant*, Payment
> Handler
> > or
> > > a
> > > > > > Delivery Handler ..."
> > > > > > 
> > > > > > Is this OK?
> > > > > > 
> > > > > > David
> > > > > > 		
> > > > > > 
> > > > > > > ----------
> > > > > > > From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> > > > > > > Sent: 	29 March 1999 22:45
> > > > > > > To: 	[email-masked]
> > > > > > > Cc: 	[email-masked]; [email-masked];
> > > > > > [email-masked];
> > > > > > > [email-masked]
> > > > > > > Subject: 	RE: Question for IOTP Authentication
> > > > > > > 
> > > > > > > David,
> > > > > > > I agree with your suggestion.
> > > > > > > But I also want to add the Merchant Authenticaton by Consumer 
> > > > > > > prior to IOTP Purchase Transaction.
> > > > > > > 
> > > > > > > These are the same flow as follows,
> > > > > > > 
> > > > > > > Consumer             Merchant
> > > > > > >    <-------------------
> > > > > > >          TPO
> > > > > > > 
> > > > > > >    ------------------->
> > > > > > >       Auth Req
> > > > > > > 
> > > > > > >    <------------------
> > > > > > >       Auth Res
> > > > > > > 
> > > > > > > and Status Block is not sent to the Merchant.
> > > > > > > 
> > > > > > > After Consumer receives the Auth Response,
> > > > > > > 1. If prior to IOTP purchase transaction
> > > > > > > Success: Consumer sends the message to the Success
> NetLocation.
> > > > > > > Fail: Stop
> > > > > > > 
> > > > > > > 2. If in the IOTP Purchase Transaction
> > > > > > > Success: Continue the transaction
> > > > > > > Fail: Stop.
> > > > > > > 
> > > > > > > Make sense?
> > > > > > > 
> > > > > > > This is minor change and I think there is no affect in the
> IOTP
> > > > > > protocol.
> > > > > > > Regards,
> > > > > > > ----
> > > > > > > Yoshiaki Kawatsura : E-mail [email-masked]
> > > > > > >  Business & Information Systems Development Devision,
> > Hitachi,Ltd.
> > > > > > > Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
> > > > > > > 
> > > > > > > 
> > > > > > >  >>>>> Fri, 26 Mar 1999 18:20:48 -0000,
> > > > > > > 	 David Burdett <[email-masked]> said:
> > > > > > > 
> > > > > > >  >Yoshiaki
> > > > > > >  >
> > > > > > >  >The current version of IOTP does not support authentication
> of
> > > the
> > > > > > > Merchant
> > > > > > >  >by the Consumer. Part of the reasoning behind this is that
> the
> > > > > > Merchant
> > > > > > > will
> > > > > > >  >include a signature in the offer which can be used for this
> > > purpose.
> > > > > > >  >HOwever, as you say, the consumer might not want to give
> > address
> > > > > > > information
> > > > > > >  >until they have authenticated the Merchant.
> > > > > > >  >
> > > > > > >  >You could actually do this although section 8.1.13 does not
> > > > > > specifically
> > > > > > >  >state this. What would be requried is that, after the
> Consumer
> > > has
> > > > > > > received
> > > > > > >  >the TPO, he authenticates the merchant with a separate
> > > > > Authentication
> > > > > > >  >transaction and then if its  OK continues with the original
> > > > > > transaction.
> > > > > > >  >
> > > > > > >  >Would this make sense? If you think it does then please post
> > the
> > > > > idea
> > > > > > to
> > > > > > > the
> > > > > > >  >list. I don't know though if we want to include this in v1.0
> > > > > although
> > > > > > it
> > > > > > >  >could easily go into v 2.0
> > > > > > >  >
> > > > > > >  >David
> > > > > > >  >
> > > > > > >  >> ----------
> > > > > > >  >> From: 	Yoshiaki
> KAWATSURA[SMTP:[email-masked]]
> > > > > > >  >> Sent: 	25 March 1999 22:46
> > > > > > >  >> To: 	[email-masked]; [email-masked];
> > > > > > > [email-masked]
> > > > > > >  >> Cc: 	[email-masked]
> > > > > > >  >> Subject: 	Question for IOTP Authentication
> > > > > > >  >> 
> > > > > > >  >> Don and David,
> > > > > > >  >> I have a couple of question for IOTP Authentication.
> > > > > > >  >> 
> > > > > > >  >> Consumer wants to send private information such as home
> > > address to
> > > > > > >  >> authenticated merchants only for Offer. In fact, SET is
> > > attempting
> > > > > > to
> > > > > > >  >> support simliar functionality. I believe that IOTP should
> > > support
> > > > > > > this.
> > > > > > >  >> 
> > > > > > >  >> IOTP version 1.0 cannot do this function in Offer
> Exchange,
> > > since
> > > > > > the
> > > > > > >  >> Offer Exchange is simplified. The idea would be that
> > initially
> > > > > IOTP
> > > > > > >  >> processes an Authentication, then a Web browser sends a
> > > private
> > > > > > >  >> information for Offer, and finally IOTP does Purchase
> > > Transaction.
> > > > > > In
> > > > > > >  >> IOTP version 1.0, IOTP supports a Consumer Authentication
> by
> > > > > > Merchant,
> > > > > > >  >> however, IOTP does not support a Merchant Authentication
> by
> > > > > > >  >> Consumer. Is this correct?
> > > > > > >  >> 
> > > > > > >  >> If this is correct, will IOTP version 2.0 support the
> > Merchant
> > > > > > >  >> Authentication by Consumer?
> > > > > > >  >> 
> > > > > > >  >> Regards,
> > > > > > >  >> 
> > > > > > >  >> --
> > > > > > >  >> Yoshiaki Kawatsura
> > > > > > >  >> Hitachi, Ltd.
> > > > > > >  >> 
> > > > > > >  >
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > >
> > > > >
> > >
> >
> **************************************************************************
> > > > > > ********************
> > > > > > 
> > > > > > This Email and any attached files are confidential and may also
> be
> > > > > > privileged. 
> > > > > > If you are not the intended recipient, please notify the
> > postmaster
> > > > > using
> > > > > > email 
> > > > > > address [email-masked] or call +44 171 557 5000 and ask
> for
> > > the 
> > > > > > IT Helpdesk.  You should not copy this email and any attached
> > files,
> > > use
> > > > > > them 
> > > > > > for any purpose or disclose the contents to any other person;
> all
> > > copies
> > > > > > of the 
> > > > > > Email and associated files in your possession should be
> destroyed.
> > > > > > 
> > > > > > Mondex International Limited
> > > > > > 47-53 Cannon Street
> > > > > > London EC4M 5SQ
> > > > > > United Kingdom
> > > > > > Registered No: 3122085, England
> > > > > > 
> > > > > > Phone:          +44 171 557 5000
> > > > > > Fax:            +44 171 557 5200
> > > > > > Email:          [email-masked]
> > > > > > WebSite:        http://www.mondexinternational.com
> > > > > > 
> > > > > >
> > > > >
> > >
> >
> **************************************************************************
> > > > > > *******************
> > > > > >
> > >
> -----------------------------------------------------------------------
> > > > > > Message addressed to: [email-masked]
> > > > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > > > To (un)subscribe send a message with "subscribe" or
> "unsubscribe"
> > in
> > > the
> > > > > > body to: [email-masked]
> > > > > > 
> > > > >
> > >
> -----------------------------------------------------------------------
> > > > > Message addressed to: [email-masked]
> > > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > > To (un)subscribe send a message with "subscribe" or "unsubscribe"
> in
> > > the
> > > > > body to: [email-masked]
> > > > > 
> > > > 
> > > >
> > >
> >
> **************************************************************************
> > > ********************
> > > > 
> > > > This Email and any attached files are confidential and may also be
> > > privileged. 
> > > > If you are not the intended recipient, please notify the postmaster
> > > using email 
> > > > address [email-masked] or call +44 171 557 5000 and ask for
> the
> > 
> > > > IT Helpdesk.  You should not copy this email and any attached files,
> > use
> > > them 
> > > > for any purpose or disclose the contents to any other person; all
> > copies
> > > of the 
> > > > Email and associated files in your possession should be destroyed.
> > > > 
> > > > Mondex International Limited
> > > > 47-53 Cannon Street
> > > > London EC4M 5SQ
> > > > United Kingdom
> > > > Registered No: 3122085, England
> > > > 
> > > > Phone:          +44 171 557 5000
> > > > Fax:            +44 171 557 5200
> > > > Email:          [email-masked]
> > > > WebSite:        http://www.mondexinternational.com
> > > > 
> > > >
> > >
> >
> **************************************************************************
> > > *******************
> > > > 
> > > 
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> > 
> 
> **************************************************************************
> ********************
> 
> This Email and any attached files are confidential and may also be
> privileged. 
> If you are not the intended recipient, please notify the postmaster using
> email 
> address [email-masked] or call +44 171 557 5000 and ask for the 
> IT Helpdesk.  You should not copy this email and any attached files, use
> them 
> for any purpose or disclose the contents to any other person; all copies
> of the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> **************************************************************************
> *******************
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: Country Codes
Date: Mon, 3 May 1999 23:00:06 +0100 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Tony/Tom

By my reckoning, IOTP doesn't need ANY country codes at least not in the
DTD, although it's quite possible that a payment protocol might need one
(e.g. SET).

If you try searching for "country" in the IOTP spec it occurs in two places:
*	in the "Order Component" section 6.4, where it is used in the
description of the "Applicable Law". This is defined as "A phrase in the
language defined by xml:lang which describes the state or country of
jurisdiction which will apply in resolving problems or disputes", and
*	in the "Postal Address Element" where it is defined as "The country
for the address. e.g. 'UK' ". As this is an attribute of an address which
could be printed, we shouldn't use country codes. For example to put the
country as "FR" (or a number) instead of "France" really would confuse the
postman.

Therefore choosing a preferred format for country codes in IOTP is purely
academic and actually can't be specified since we have nowhere in the
specification to put it !!  

Does anyone disagree?

David
PS However *if* we did find a need for one, I'd agree with Tony ;-)

> ----------
> From: 	Lewis, Tony[SMTP:[email-masked]]
> Sent: 	30 April 1999 13:44
> To: 	Ietf Trade WG
> Subject: 	RE: Country Codes
> 
> I recommend settling on one representation. Otherwise, implementers who
> want
> to interoperate with everyone have to implement every possible way of
> encoding the information.
> 
> Tony
> > ----------
> > From: 	Tom Arnold[SMTP:[email-masked]]
> > Sent: 	Friday, April 30, 1999 11:35 AM
> > To: 	Ietf Trade WG
> > Subject: 	Re: Country Codes
> > 
> > I think it would be appropriate to specify ISO 3166 for the country code
> > and leave the specification of whether to use alpha 2 or alpha 3
> character
> > codes to the implementers.  
> > 
> > At 12:00 AM 4/30/99 +0100, David Burdett wrote: 
> > >A while back there was discussion about country codes (see emails from
> > Tom 
> > >Arnold on 14 March and Don Eastlake on 17 March) that suggested  
> > >	In the same manner that ISO4217 is specified for currency codes, 
> > >should country codes be specified to ISO3166? Also, does it matter if
> two
> > or 
> > >three character codes are used? 
> > > 
> > >In IOTP country is only used as part of an address (see Postal Address 
> > >Element). Therefore mandating use of country codes doesn't seem to be 
> > >necessary in my view as I can't think how it would be used although I'm
> > open 
> > >to counter arguments. 
> > > 
> > > [snip] 
> > 
> > 
> > Tom Arnold 
> > Vice President of Engineering 
> > Chief Technical Officer 
> > CyberSource Corporation 
> > [email-masked] 
> > 
> > ------------------------------------------------------------------------
> 
> > This Email and any attached files are confidential and may also be
> > privileged.  It is intended only for the individual or entity to whom it
> > is addressed.  If you are not the recipient or an authorized agent of
> the
> > recipient, you are hereby notified that any use, dissemination,
> > distribution or copying of this communication is strictly prohibited.
> If
> > you have received this message in error, please contact CyberSource
> > Corporation immediately at (408) 556-9100.  Thank you. 
> > 
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked] Archive available at:
> > http://www.elistx.com/archives/ietf-trade/ To (un)subscribe send a
> message
> > with "subscribe" or "unsubscribe" in the body to:
> > [email-masked]
> > 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: Ietf Trade WG <[email-masked]>
Date: Mon, 3 May 1999 15:52:44 -0400
Subject: Re: IANA Considerations
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This is good but I believe some minor wording change is still needed.  In
particular:

On the mailing list: RFCs can not assume the perpertual existence of a working
group.  It can say the IETF Trade Mailing List, but it can't say the Trade WG
Mailing List.  The actual mailing list address should be given
<[email-masked]>.

On the Designated Expert, it should probably explicitly say they are appointed
by the IESG.  While the TRADE WG exists, the IESG is likely to defer to the WG
on whom to appoint but there needs to be a mechaism that would survive the
termination of the working group.

Thanks,
Donald

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
[email-masked]   tel: 1-914-276-2668

David Burdett <[email-masked]> on 04/28/99 05:45:37 PM

To:   Ietf Trade WG <[email-masked]>
cc:    (bcc: Donald Eastlake/Hawthorne/IBM)
Subject:  IANA Considerations

Below is the revised text for IANA considerations for the IOTP
specification. Essentially it consists of a re-worked section 3.7.3 from the
last draft as a new section 11.

If anyone has any comments please let me know.

David
========================
11. IANA Considerations

11.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.

  Element Type/                      Attribute Values
 Attribute Name

Algorithm/        "sha1" - indicates that authentication consists of
Name              [SHA1] has of the challenge data
(When Algorithm
is a child of an  "signature" - indicates that authentication consists
AuthData          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 Authentication Methods that
                  begin with "pay:", new values are allocated
                  following review on the IETF Trade Working Group
                  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.
                  [Note End]

Brand/BrandId     "SET:setbrand" where setbrand is a brand which is
                  accepted by the [SET] payment protocol

                  "IOTP:iotpbrand" where iotpbrand may be:
                  o "GeldKarte"
                  o "Mondex"

                  New values of the high level prefix (SET or IOTP)
                  are allocated following review on the IETF Trade
                  Working Group mailing list and by the Designated
                  Expert.

                  Values of "setbrand" are allocated as defined in the
                  [SET] specifications.

                  New values of "iotpbrand" must be announced to the
                  IETF Trade WG 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 code as defined by [ISO4217]

                  If CurrCodeType is "IOTP" then new values must be
                  announced to the IETF Trade WG 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.
                  [Note End]

CurrencyAmount/   "ISO4217-A"
CurrCodeType
                  "IOTP"

                  New values of CurrCodeType attribute are allocated
                  following review on the IETF Trade Working Group
                  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 Working
                  Group 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 Working
                  Group 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/        "OtpTransaction"
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 delivery method is
                  used.

Status/           Offer
StatusType
                  Payment

                  Delivery

                  Authentication

                  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 Working
                    Group 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).
                  [Note End]

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 Working
                    Group mailing list and by the Designated Expert.

                  [Note]   The document describing new values for the
                           Trading Role attribute may be combined with
                           documents that describe new Status Types
                           (see above) and types of signatures (see
                            below).
                  [Note End]

TransId/          "BaselineAuthentication"
OtpTransType
                  "BaselineDeposit"

                  "BaselinePurchase"

                  "BaselineRefund"

                  "BaselineWithdrawal"

                  "BaselineValueExchange"

                  "BaselineInquiry"

                  "BaselinePing"

                  New values of the OtpTransType attribute are
                  allocated following:
                  o publication to the IETF Trade Working Group, 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/        "OfferResponse"
Content
(see Signature    "PaymentResponse"
Component)
                  "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 Working
                    Group mailing list and by the Designated Expert.

                  [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).
                  [Note End]

11.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.
===================================================

THIS EMAIL IS FOR UNLIMITED DISTRIBUTION

> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973   Fax: +1 415 956 9370
>

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

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: Trade WG <[email-masked]>
Date: Mon, 3 May 1999 15:56:55 -0400
Subject: Re: New IOTP spec doiagram style. Comments please.
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I think that for the back-and-forth flow type diagrams, the revised form will
improve things by being more compact without loss of info.

Thanks,
Donald

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
[email-masked]   tel: 1-914-276-2668

David Burdett <[email-masked]> on 04/28/99 05:45:41 PM

To:   Ietf Trade WG <[email-masked]>
cc:    (bcc: Donald Eastlake/Hawthorne/IBM)
Subject:  New IOTP spec doiagram style. Comments please.

One of the comments that Don Eastlake makes about the latest version of the
IOTP spec is as follows ...

     "Page spanning figures, like Figure 3, are really pretty messy.  It
would be better if the text could be made much more terse and this and
similar figures started high on a page so they aren't split by a page
boundary."

I agree with Don that the diagrams are messy, but they contain the same text
as in an earlier version which used a drawing package to create them using
just "text". If the diagrams are made more terse, then some of the
explanation will have to be omitted.

An alternative is to adopt a different type of text diagram (see example
below which should be viewed in a fixed font).
Do people think this style is better. If there is a reasonable consensus
that it is then I will change the diagrams, otherwise I am inclined to leave
as is.

David
EXAMPLE of partially re-worked figure 3. See the current spec for the
original.

 CONSUMER               <<< IOTP MESSAGE >>>                    MERCHANT
  1. Consumer decides to trade and sends information about the
     transaction (requests an offer) to the Merchant, e.g.
     using HTML

        >>>Information on what is being paid for (outside scope of IOTP)>>>

                           2. Merchant decides which payment brand and
                              currencies/amounts to offer, places them in a
Brand
                              List Component and sends them to the Consumer

                           <<<< Brand List Component <<<<

  3. Consumer selects the payment brand, protocol and
     currency/amount, creates a Brand Selection Component and
     send it to the Merchant

                        >>>> Brand Selection Component >>>>

                           4. Merchant checks Brand Selection, creates
Payment
                              Amount information, optionally sings it to
                              authorise payment and sends it to the Consumer

               <<< Pay Amount; Organisations: Merchant  <<<
               <<< & Payment Handler; Signature (Offer) <<<

  5 Consumer checks the Payment Amount information and if OK
     reuqests that the payment starts by sending a Payment
     Request to the Payment Handler

       >>>      Brand List; Brand Selection; Pay Amount; Pay Scheme;
>>>
       >>> Organisations: Merchant and Payment Handler; Signature (Offer)
>>>

                                      etc ...

THIS EMAIL IS FOR UNLIMITED DISTRIBUTION
> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973   Fax: +1 415 956 9370
>

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: [email-masked]
Cc: Ietf Trade WG <[email-masked]>
Subject: Alternative to  the Common Markup for Web Micropayment Systems sp ecification
Date: Mon, 3 May 1999 20:49:26 +0100 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The XML based "Intenet Open Trading Protocol" (IOTP) is an alternative
approach to the "Common Markup for Web Micropayment Systems" specification
(available at http://www.w3.org/TR/WD-Micropayment-Markup).

IOTP is being developed under the auspices of the IETF Trade Working Group.
Copies of the specifications can be downloaded from:

*	http://internet-drafts/draft-ietf-trade-iotp-v1.0-protocol-03.txt -
Internet Open Trading Protocol - IOTP Version 1.0 (the main specification)
(567kb)
*	http://internet-drafts/draft-ietf-trade-iotp-http-01.txt -  Internet
Open Trading Protocol (IOTP) HTTP Supplement (13kb)
*	http://internet-drafts/draft-ietf-trade-iotp-v1.0-dsig-00.txt -
Digital Signatures for the Internet Open Trading Protocol (38kb)
*	ftp://ftp.pothole.com/pub/ietf-trade/iotp-v1.0-protocol-03.dtd -
IOTP v 1.0 XML Data Type Definition (19kb)
*	ftp://ftp.pothole.com/pub/ietf-trade/iotpar101current.zip - IOTP
architecture document (includes payment API) (863kb)

As can be seen from the above specification list, IOTP already includes a
fully defined XML DTD and a payment API which are planned future work
products of the W3C Electronic Commerce group. 

Moreover, IOTP was designed to be used in a simple way to support
micropayments. Specifically:
*	use of digital signatures, although fully specified, is entirely
optional. Therefore their cost can be avoided when they are not justified -
such as for micropayments. In this sense IOTP can provide a good "ratio of
security cost to protected value" 
*	IOTP can work in a way where no additional messages are sent over
the net above those required for the payment protocol. This is as minimal as
you can get and lends itself to the situations where micropayments are
likely to be used.

In addition development projects are underway for IOTP to be used for
several micropayment systems and pilots including: Mondex, GeldKarte
(Germany) and NTT Cash (Japan) as well as projects to support more complex
payment protocols such as SET.

I honestly believe that we, as developers of internet standards should not
develop two alternative standards for micropayments on the net without
looking, very closely to see if they can converge. In my personal view, I
think it would be a good idea if the IETF and W3C worked jointly on how
micropayments on the net should operate. There is already a precedence for
joint IETF/W3C working in the work that is being done on digital signatures
for XML.

I would appreciate that any reply to this email is also copied to the IETF
Trade WG at [email-masked]. Archives of this mailing list are
available at http://www.elistx.com/archives/ietf-trade/ and you can
subscribe to the list by sending an email with "subscribe" in the body to:
[email-masked].

Regards

David Burdett
PS Below are some more detailed comments on the w3C specification as it
currently stands.

DETAILED COMMENTS ON CURRENT SPECIFICATION
1. Some payment methods, e.g. Mondex, require multiple exchange of messages
between the consumer and merchant. It is not clear how this type of payment
method would be supported. Is it assumed that this would be managed by the
underlying payment wallet?

2. How is the security of the payment managed? You need to make sure that it
is hard for a payment to be made by a consumer unless it is authorized by
the consumer and that appropriate levels of privacy are considered. Security
and privacy of the payment does seem to be covered by the specification in
its current form.

3. How are errors handled?  Ideally any problems should be handled
gracefully, especially for the consumer, with the opportunity for real bugs
in the system to be properly recorded and identified and so more easily
fixed. What happens if, for example:
*	the same request is received twice
*	there is an error in the request, what should the client (or server)
do?
*	the consumer is expecting a payment request but none arrives?

4. Once a payment has been made, how does the merchant get informed that
payment is complete and therefore delivery of the digital (or other goods)
should occur? I could not see how this is covered.

5. There is a need to support multiple currencies (e.g. Deutschmarks and
Euros, or US and Canadian Dollars) otherwise a merchant's opportunity to
sell will be restricted.

6. There is a need to support multiple versions of payment protocols (be
they micropayment or not). I don't think the current specification supports
this without the consumer knowing which version of the payment protocol they
are using and selecting the correct one. This is not "user friendly".

7. As far as I can see, there is no facility to provide the consumer with a
list of payment brand logos which is the way consumers select the payment
method to use in the real world.

PLEASE NOTE THAT THIS EMAIL IS DESIGNED FOR UNLIMITED AND UNRESTRICTED
DISTRIBUTION.

> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> 

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

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Lewis, Tony" <[email-masked]>
To: [email-masked]
Subject: RE: Question for IOTP Authentication
Date: Mon, 3 May 1999 11:50:45 -0700 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Yes, this authentication is performed prior to the shopping phase, but can't
it be processed as a null payment and use both IOTP and SET authentication
mechanisms?

Tony
> ----------
> From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> Sent: 	Sunday, May 02, 1999 8:19 AM
> To: 	[email-masked]
> Cc: 	Lewis, Tony; [email-masked]; [email-masked]
> Subject: 	RE: Question for IOTP Authentication
> 
> Tony mentioned to me the Mercahnt authentication has to do prior to
> shopping phase, this is out of IOTP. So we can use separete
> authentication only.
> 
> We need to define the SET Specific authentication, which
> satisfy the requirement to the BAG Requirement, in SETCo.  because
> consumer have to confirm whether Merchant is authorized by the
> Acquirer and this requirement is payment dependent(IOTP is the payment
> scheme independent messaging protocol).
> 
> I believe that the merit of using IOTP authentication is that we
> can be concerned IOTP Authentication transaction with IOTP
> Purchase transaction.
> 
> --
> Yoshiaki Kawatsura Hitachi, Ltd.
> 
> 
> 
> >>>>> Fri, 30 Apr 1999 20:04:11 +0100,
> 	David Burdett <[email-masked]> said:
> 
> > Tony
> > 
> > I can think of three ways that IOTP might be able to meet the
> requirement
> > you describe:
> > *	using the Packaged Content element in the Pay Protocol element (see
> > section 6.6.4),
> > *	the Consumer authenticates the Merchant separately using an
> > authentication transaction, or 
> > *	a combination of the two.
> > 
> > Each is discussed in a bit more detail below.
> > 
> > PAY PROTOCOL ELEMENT
> > This involves the merchant including the relevent certificate and
> message
> > from the acquirer in the PackagedContent element in the Pay Protocol
> element
> > for SET of the Brand List (see spec section  6.6.4), then if the
> Consumer
> > wants to use SET for a payment they just pass the data to the SET
> payment
> > software working within IOTP which then checks the credentials.
> > 
> > The advantage of this approach is that the certificate will always be
> there
> > and no extra messages will be required to retrieve it. The disadvantage
> is
> > that it increases the size of the messages.
> > 
> > SEPARATE CONSUMER AUTHENTICATION OF THE MERCHANT
> > In this case, the SET software recognises that there a certificate and
> > message from the acquirer is needed and makes a request to the IOTP
> software
> > to obtain it. When this need occurs, a separate IOTP Authentication
> > Transaction (see spec section 8.1.6) is used to get the information. 
> > 
> > This would involve:
> > *	the Consumer sending an IOTPAuthentication Request message to the
> > merchant specifying in the Algorithm element that the Merchant should
> do,
> > for example, a SET merchant authentication, then
> > *	the Merchant replying with a Authentication Response message
> > including the necessary certificate and acquirer message in the Packaged
> > Content.
> > 
> > COMBINATION
> > An alternative might be to include some fingerprint of the
> > certificate/message in the PayProtocol element, so that the consumer SET
> > software can check if it already has a copy of it. If it hasn't then a
> > separate consumer initiated IOTP Athentication of the merchant could be
> used
> > to obtain it.
> > 
> > Does this make sense?
> > 
> > David
> > 
> > 
> > 
> > > ----------
> > > From: 	Lewis, Tony[SMTP:[email-masked]]
> > > Sent: 	29 April 1999 17:36
> > > To: 	Yoshiaki KAWATSURA
> > > Cc: 	Ietf Trade WG
> > > Subject: 	RE: Question for IOTP Authentication
> > > 
> > > David,
> > > 
> > > I believe this proposal originates from requirements that SETCo has
> > > defined
> > > for SET 2.0 although when we discussed the approach outlined by
> Yoshiaki
> > > at
> > > our meeting last week, we recommended some changes.
> > > 
> > > I believe what we will need is the ability for the merchant to push
> some
> > > data (certificates and a signed message from the acquirer) to the
> > > cardholder
> > > wallet who will use that data to authenticate the merchant. If that
> can be
> > > accomplished with the existing authentication transaction then I
> believe
> > > your change will satisfy our needs.
> > > 
> > > However, there may be other issues behind the input from Hitachi so
> > > Yoshiaki
> > > should also respond.
> > > 
> > > Tony
> > > > ----------
> > > > From: 	David Burdett[SMTP:[email-masked]]
> > > > Sent: 	Thursday, April 29, 1999 4:00 PM
> > > > To: 	Yoshiaki KAWATSURA
> > > > Cc: 	Ietf Trade WG
> > > > Subject: 	RE: Question for IOTP Authentication
> > > > 
> > > > Yoshiaki
> > > > 
> > > > As you can see I'm catching up on all the Trade WG emails and have
> > > thought
> > > > about your suggestion. In principle I can see why allowing a
> Consumer to
> > > > authenticate a Merchant is reasonable as, in the current version of
> the
> > > > specification, it states that a Conumer can authenticate a Payment
> > > Handler
> > > > or a Delivery Handler (see section 8.1.13 second bullet point) and
> > > > therefore
> > > > it is logical that a Consumer should also be able to authenticate a
> > > > Merchant.
> > > > 
> > > > However the method you suggest below for authenticating a Merchant
> is
> > > > different from the way the Consumer authenticates a Payment Handler
> or
> > > > Delivery Handler in that it is integrated into the transaction (e.g
> a
> > > > purchase) which implies a further variation on the message flow. So,
> I
> > > > suggest that we meet your requirement by simply changing the first
> > > bullet
> > > > point in section 8.1.13 to read the authentication transaction can
> be
> > > used
> > > > ... " by a Consumer to authenticate a *Merchant*, Payment Handler or
> a
> > > > Delivery Handler ..."
> > > > 
> > > > Is this OK?
> > > > 
> > > > David
> > > > 		
> > > > 
> > > > > ----------
> > > > > From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> > > > > Sent: 	29 March 1999 22:45
> > > > > To: 	[email-masked]
> > > > > Cc: 	[email-masked]; [email-masked];
> > > > [email-masked];
> > > > > [email-masked]
> > > > > Subject: 	RE: Question for IOTP Authentication
> > > > > 
> > > > > David,
> > > > > I agree with your suggestion.
> > > > > But I also want to add the Merchant Authenticaton by Consumer 
> > > > > prior to IOTP Purchase Transaction.
> > > > > 
> > > > > These are the same flow as follows,
> > > > > 
> > > > > Consumer             Merchant
> > > > >    <-------------------
> > > > >          TPO
> > > > > 
> > > > >    ------------------->
> > > > >       Auth Req
> > > > > 
> > > > >    <------------------
> > > > >       Auth Res
> > > > > 
> > > > > and Status Block is not sent to the Merchant.
> > > > > 
> > > > > After Consumer receives the Auth Response,
> > > > > 1. If prior to IOTP purchase transaction
> > > > > Success: Consumer sends the message to the Success NetLocation.
> > > > > Fail: Stop
> > > > > 
> > > > > 2. If in the IOTP Purchase Transaction
> > > > > Success: Continue the transaction
> > > > > Fail: Stop.
> > > > > 
> > > > > Make sense?
> > > > > 
> > > > > This is minor change and I think there is no affect in the IOTP
> > > > protocol.
> > > > > Regards,
> > > > > ----
> > > > > Yoshiaki Kawatsura : E-mail [email-masked]
> > > > >  Business & Information Systems Development Devision, Hitachi,Ltd.
> > > > > Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
> > > > > 
> > > > > 
> > > > >  >>>>> Fri, 26 Mar 1999 18:20:48 -0000,
> > > > > 	 David Burdett <[email-masked]> said:
> > > > > 
> > > > >  >Yoshiaki
> > > > >  >
> > > > >  >The current version of IOTP does not support authentication of
> the
> > > > > Merchant
> > > > >  >by the Consumer. Part of the reasoning behind this is that the
> > > > Merchant
> > > > > will
> > > > >  >include a signature in the offer which can be used for this
> purpose.
> > > > >  >HOwever, as you say, the consumer might not want to give address
> > > > > information
> > > > >  >until they have authenticated the Merchant.
> > > > >  >
> > > > >  >You could actually do this although section 8.1.13 does not
> > > > specifically
> > > > >  >state this. What would be requried is that, after the Consumer
> has
> > > > > received
> > > > >  >the TPO, he authenticates the merchant with a separate
> > > Authentication
> > > > >  >transaction and then if its  OK continues with the original
> > > > transaction.
> > > > >  >
> > > > >  >Would this make sense? If you think it does then please post the
> > > idea
> > > > to
> > > > > the
> > > > >  >list. I don't know though if we want to include this in v1.0
> > > although
> > > > it
> > > > >  >could easily go into v 2.0
> > > > >  >
> > > > >  >David
> > > > >  >
> > > > >  >> ----------
> > > > >  >> From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> > > > >  >> Sent: 	25 March 1999 22:46
> > > > >  >> To: 	[email-masked]; [email-masked];
> > > > > [email-masked]
> > > > >  >> Cc: 	[email-masked]
> > > > >  >> Subject: 	Question for IOTP Authentication
> > > > >  >> 
> > > > >  >> Don and David,
> > > > >  >> I have a couple of question for IOTP Authentication.
> > > > >  >> 
> > > > >  >> Consumer wants to send private information such as home
> address to
> > > > >  >> authenticated merchants only for Offer. In fact, SET is
> attempting
> > > > to
> > > > >  >> support simliar functionality. I believe that IOTP should
> support
> > > > > this.
> > > > >  >> 
> > > > >  >> IOTP version 1.0 cannot do this function in Offer Exchange,
> since
> > > > the
> > > > >  >> Offer Exchange is simplified. The idea would be that initially
> > > IOTP
> > > > >  >> processes an Authentication, then a Web browser sends a
> private
> > > > >  >> information for Offer, and finally IOTP does Purchase
> Transaction.
> > > > In
> > > > >  >> IOTP version 1.0, IOTP supports a Consumer Authentication by
> > > > Merchant,
> > > > >  >> however, IOTP does not support a Merchant Authentication by
> > > > >  >> Consumer. Is this correct?
> > > > >  >> 
> > > > >  >> If this is correct, will IOTP version 2.0 support the Merchant
> > > > >  >> Authentication by Consumer?
> > > > >  >> 
> > > > >  >> Regards,
> > > > >  >> 
> > > > >  >> --
> > > > >  >> Yoshiaki Kawatsura
> > > > >  >> Hitachi, Ltd.
> > > > >  >> 
> > > > >  >
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > >
> > >
> **************************************************************************
> > > > ********************
> > > > 
> > > > This Email and any attached files are confidential and may also be
> > > > privileged. 
> > > > If you are not the intended recipient, please notify the postmaster
> > > using
> > > > email 
> > > > address [email-masked] or call +44 171 557 5000 and ask for
> the 
> > > > IT Helpdesk.  You should not copy this email and any attached files,
> use
> > > > them 
> > > > for any purpose or disclose the contents to any other person; all
> copies
> > > > of the 
> > > > Email and associated files in your possession should be destroyed.
> > > > 
> > > > Mondex International Limited
> > > > 47-53 Cannon Street
> > > > London EC4M 5SQ
> > > > United Kingdom
> > > > Registered No: 3122085, England
> > > > 
> > > > Phone:          +44 171 557 5000
> > > > Fax:            +44 171 557 5200
> > > > Email:          [email-masked]
> > > > WebSite:        http://www.mondexinternational.com
> > > > 
> > > >
> > >
> **************************************************************************
> > > > *******************
> > > >
> -----------------------------------------------------------------------
> > > > Message addressed to: [email-masked]
> > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > > body to: [email-masked]
> > > > 
> > >
> -----------------------------------------------------------------------
> > > Message addressed to: [email-masked]
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > body to: [email-masked]
> > > 
> > 
> >
> **************************************************************************
> ********************
> > 
> > This Email and any attached files are confidential and may also be
> privileged. 
> > If you are not the intended recipient, please notify the postmaster
> using email 
> > address [email-masked] or call +44 171 557 5000 and ask for the 
> > IT Helpdesk.  You should not copy this email and any attached files, use
> them 
> > for any purpose or disclose the contents to any other person; all copies
> of the 
> > Email and associated files in your possession should be destroyed.
> > 
> > Mondex International Limited
> > 47-53 Cannon Street
> > London EC4M 5SQ
> > United Kingdom
> > Registered No: 3122085, England
> > 
> > Phone:          +44 171 557 5000
> > Fax:            +44 171 557 5200
> > Email:          [email-masked]
> > WebSite:        http://www.mondexinternational.com
> > 
> >
> **************************************************************************
> *******************
> > 
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: Steve Fabes <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Cc: "Lewis, Tony" <[email-masked]>
Subject: Re: Brand IDs & their registration. Was: RE: Comments on draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part  1
Date: Mon, 3 May 1999 09:39:02 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

EMV - decade or sooner - I understand that the extent of mag stripe fraud in
some territories is growing at such a fast rate that in order to survive the
banks will be forced into EMV or face the possibility of shutting down their
credit operations. What we in the US/Japanese markets must worry about is
that fraud activity remains constant and will shift from EMV enabled
territories to those that currently do not have such problems. So while the
US/Japanese banks may seem to not have a strong current need for chip they
must move there to defend their risk levels.
-----Original Message-----
From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Cc: Lewis, Tony <[email-masked]>
Date: Thursday, April 29, 1999 09:43
Subject: RE: Brand IDs & their registration. Was: RE: Comments on draft-ie
tf-t rade-iotp-v1.0-protocol-03.txt, part 1

>I agree with Tony. Smart card based EMV transactions will be the dominant
>payment model within a decade, probably even earlier especially in the
>non-US part of the world. The main reasons being, in my view:
>* it will reduce fraud as it's much much harder to copy a smart card
>than a mag stripe card
>* it makes internet credit card payments "card present" transactions
>which should result in lower merchant fees. This also means that it will be
>much harder for customers to claim they never made an internet purchase
>* using a multi-application smart card you will be able to use just
>one smart card for debit, credit, electronic cash, a loyalty scheme as well
>as hold electronic tickets for anything from local cinema to your next
>flight.
>
>To rephrase a MasterCard ad line, "smart cards are the future of money".
>
>David
>
>> ----------
>> From: Lewis, Tony[SMTP:[email-masked]]
>> Sent: 28 April 1999 20:30
>> To: Ietf Trade WG
>> Subject: RE: Brand IDs & their registration. Was: RE: Comments on
>> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part  1
>>
>> My point is that the brand is "Visa" no matter whether using IOTP, SET or
>> any other protocol.
>>
>> As for EMV, the very first live SET 1.0 transaction was made using an EMV
>> card with the EMV data carried inside a SET message extension. EMV credit
>> and debit products are a significant part of the future of electronic
>> commerce. I expect they will be the dominant model for payment in a
>> decade.
>>
>> Tony
>> > ----------
>> > From: Steve Fabes[SMTP:[email-masked]]
>> > Sent: Wednesday, April 28, 1999 3:43 PM
>> > To: Lewis, Tony; Ietf Trade WG
>> > Subject: Re: Brand IDs & their registration. Was: RE: Comments on
>> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
>> >
>> > Tony - do your comments infer that SET.Visa will be the only e-Commerce
>> > product that an IOTP product supplier can expect to see. Can you see a
>> day
>> > when a Visa EMV 3.1.1 (or 3.x.x) based credit product could also be
used
>> > inside an IOTP product?
>> > -----Original Message-----
>> > From: Lewis, Tony <[email-masked]>
>> > To: Ietf Trade WG <[email-masked]>
>> > Date: Wednesday, April 28, 1999 13:21
>> > Subject: RE: Brand IDs & their registration. Was: RE: Comments on
>> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
>> >
>> >
>> > >David,
>> > >
>> > >I am new to this group and do not know what lead to the current
>> approach.
>> > >There are undoubtedly some issues that I don't know about. However, it
>> > seems
>> > >to me that a brand is a brand no matter what payment protocol is being
>> > used.
>> > >The only difference I see between "IOTP:Visa" and "SET:Visa" is that
>> the
>> > >latter indicates that the brand is supported by a specific payment
>> > protocol.
>> > >Since you need to support brands other than those supported by SET,
>> there
>> > >will need to be a registry. It seems to me that there should only be
>> one
>> > >such registry rather than the two being proposed. I recommend having a
>> > >single domain for these brands. It seems reasonable to initially
>> populate
>> > it
>> > >using the brands registered with SET and those non-SET brands you
>> listed
>> > in
>> > >your note.
>> > >
>> > >Tony
>> > >> ----------
>> > >> From: David Burdett[SMTP:[email-masked]]
>> > >> Sent: Wednesday, April 28, 1999 11:36 AM
>> > >> To: Ietf Trade WG; Lewis, Tony
>> > >> Subject: Brand IDs & their registration. Was: RE: Comments on
>> > >> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
>> > >>
>> > >> In the current specification the basic idea for identifying brands
is
>> > that
>> > >> they should be of the form "xxx:brandid" where "xxx" can be "SET"
>> which
>> > >> indicates that the brandid is any valid brandid that is accepted by
>> > SET,
>> > >> or
>> > >> alternatively "IOTP" which can be used to define any brand not
>> defined
>> > by
>> > >> SET. The idea was that we should not need to define "Visa",
>> > "MasterCard",
>> > >> "American Express", etc more than once since they are already
defined
>> > and
>> > >> registered by SET.
>> > >>
>> > >> However a couple of problems may arise ...
>> > >>
>> > >> USING THE SET BRAND ID FOR NON-SET PAYMENTS
>> > >> Although IOTP can support SET as a payment protocol, it can also
>> > support
>> > >> credit card payments (using Secure Channel Credit Debit - SCCD)
where
>> > the
>> > >> credit card information (no, name, expiration date, etc) is coded
>> > >> effectively in the clear but with privacy protection provided by
>> using
>> > a
>> > >> secure channel such as SSL. In this way it provides a similar level
>> of
>> > >> privacy/security as for credit card payments that occur now where a
>> web
>> > >> page
>> > >> form is completed by the user.
>> > >>
>> > >> My question is, will it be reasonable to use the SET brandid in this
>> > way
>> > >> to
>> > >> cover non-SET credit card payments. I *think* the answer is "yes" as
>> > you
>> > >> can
>> > >> quite imagine a situation where a consumer is offered a choice of
>> using
>> > >> their VISA credit card to pay using either SET or SCCD.
>> > >>
>> > >> WHAT BRAND ID SHOULD BE USED FOR CO BRANDS
>> > >> If a payment brand, such as a local brand or co-brand, chooses,
>> > initiall
>> > >> to
>> > >> use just SCCD rather than SET then they would not (I think) need to
>> > >> register
>> > >> their brand with SET. In this case, they might register their brand
>> as
>> > an
>> > >> "IOTP" brand. However if they later adopted SET, they would end up
>> with
>> > >> potentially two equivalent Brand IDs. Do you think we might be
better
>> > off
>> > >> with a straight IOTP brand and keep all the names under the
>> procedures
>> > >> defined by IANA? I'm not sure?
>> > >>
>> > >> REGISTERING NEW BRAND IDs
>> > >> To help assist in answering the last point, the following is what
I'm
>> > >> currently writing as the proposed IANA procedure for registering new
>> > brand
>> > >> ids. Any comments:
>> > >>
>> > >> >>>Clip>>>
>> > >> The format of the Brand ID is either:
>> > >> * SET:setbrand where setbrand is a brand which is accepted by the
>> > >> [SET] payment protocol
>> > >> * IOTP:iotpbrand where iotpbrand may be:
>> > >> - GeldKarte
>> > >> - Mondex
>> > >>
>> > >> New values of the high level prefix (SET or IOTP) should be
allocated
>> > >> following review on the IETF Trade Working Group mailing list and by
>> > the
>> > >> Designated Expert.
>> > >>
>> > >> Values of "setbrand" are allocated as defined in the [SET]
>> > specifications.
>> > >>
>> > >> New values of "iotpbrand" must be announced to the IETF Trade WG
>> > mailing
>> > >> list and, if there are no objections within three weeks, be
allocated
>> > on
>> > a
>> > >> "first come first served" basis.
>> > >> <<<End Clip<<<
>> > >>
>> > >> Regards
>> > >>
>> > >> David
>> > >> > ----------
>> > >> > From: Lewis, Tony[SMTP:[email-masked]]
>> > >> > Sent: 28 April 1999 08:14
>> > >> > To: Ietf Trade WG
>> > >> > Subject: RE: Comments on
>> draft-ietf-trade-iotp-v1.0-protocol-03.txt,
>> > >> > part  1
>> > >> >
>> > >> > In SET, the BrandID is either "brand" or "brand:product".
>> > >> >
>> > >> > In Japan, there are products that are co-branded. Essentially
these
>> > >> > products
>> > >> > are private label cards for domestic transactions with an
>> > international
>> > >> > brand for non-domestic transactions. The private label can be
>> > reflected
>> > >> in
>> > >> > a
>> > >> > SET cardholder certificate as the "promotional card name" under
the
>> > >> > international brand's hierarchy and/or the cardholder can have a
>> > >> > certificate
>> > >> > issued under the private label hierarchy.
>> > >> >
>> > >> > There is no provision to carry both the private label (of the
>> > Japanese
>> > >> > credit card company) and the international brand as part of the
SET
>> > >> > BrandID.
>> > >> >
>> > >> > Tony
>> > >> > > ----------
>> > >> > > From: David Burdett[SMTP:[email-masked]]
>> > >> > > Sent: Tuesday, April 27, 1999 6:31 PM
>> > >> > > To: Ietf Trade WG; [email-masked]
>> > >> > > Subject: RE: Comments on
>> > draft-ietf-trade-iotp-v1.0-protocol-03.txt,
>> > >> > > part  1
>> > >> > >
>> > >> > > I'm working my way through Don's comments and came across this
>> one
>> > >> where
>> > >> > > our
>> > >> > > friends in Japan might be able to help ... I think ...
>> > >> > >
>> > >> > > Don says ...
>> > >> > >
>> > >> > > "I looked around a bit in SET literature and couldn't find
>> anything
>> > >> > > about Dual or Promotional brands or anything about a three
>> > component
>> > >> SET
>> > >> > > Brand.  Two components, "brand" and "product" I see in the SET
>> > >> > literature,
>> > >> > > such a "MasterCard" or "Visa:Gold".  But not A:B:C and no case
>> > where
>> > a
>> > >> > > colon
>> > >> > > is included if there isn't anything after it.  In other words,
>> it's
>> > >> > > "Visa",
>> > >> > > not "Visa:", and certainly not "Visa::" as a SET brand (re also
>> > >> examples
>> > >> > > in
>> > >> > > 6.6.1)."
>> > >> > >
>> > >> > > This requirement arose as a result of meeting the needs of the
>> > Japan
>> > >> > > market.
>> > >> > > Can some people who are more familiar with this, please have a
>> look
>> > at
>> > >> > > this
>> > >> > > part of the spec and check it is ok please?
>> > >> > >
>> > >> > > David
>> > >> > >
>> > >> > > > ----------
>> > >> > > > From: [email-masked][SMTP:[email-masked]]
>> > >> > > > Sent: 22 April 1999 15:25
>> > >> > > > To: [email-masked]
>> > >> > > > Subject: Comments on
>> > >> draft-ietf-trade-iotp-v1.0-protocol-03.txt, part
>> > >> > > > 1
>> > >> > > >
>> > >> > > > I've done a careful review of the document through section 6
>> and
>> > >> > section
>> > >> > > > 13
>> > >> > > > and greater and came up with the following somewhat length
list
>> > of
>> > >> > > > suggestions.  I don't think they substantially change the
>> > intended
>> > >> > > meaning
>> > >> > > > of the document but those on the list should judge that.
>> > >> > > >
>> > >> > > >
>> > >> > > > IMPORTANT:
>> > >> > > >
>> > >> > > > "IANA Considerations" needs to be a top level section, perhaps
>> > #11.
>> > >> > > > Gathering this stuff together into 3.7.3 is good but its still
>> > >> > > > unreasonable
>> > >> > > > to expect IANA to comb the document to find it.
>> > >> > > >      I'm not sure about the criteria for registration.  "IETF
>> > >> > Consensus"
>> > >> > > > is
>> > >> > > > pretty stiff and requires a vote of the IESG.  I should think
>> > >> someone
>> > >> > > > could
>> > >> > > > register an IOTP Band or CurrCode by publishing an RFC.
>> Perhaps
>> > >> that
>> > >> > is
>> > >> > > > what you mean for ProtocolId but it is not clear.
>> > >> > > >      Toward end so 3.7.3, change "with" to "without".
>> > >> > > >
>> > >> > > >
>> > >> > > > MISCELLANEOUS:
>> > >> > > >
>> > >> > > > I don't understand the difference between "Objectives" and
>> > >> "Purpose".
>> > >> > I
>> > >> > > > suggest that 1.4 and 1.5 be merged and that the reference to
>> > "IOTP
>> > >> > > > Business
>> > >> > > > Description" which, as far as I know, is not intended to ever
>> > become
>> > >> > an
>> > >> > > > IETF document, be dropped.
>> > >> > > >
>> > >> > > > Section 1.7 still refers to an XML Overview section 11.
>> > >> > > >
>> > >> > > > Page spanning figures, like Figure 3, are really pretty messy.
>> > It
>> > >> > would
>> > >> > > > be
>> > >> > > > better if the text could be made much more terse and this and
>> > >> similar
>> > >> > > > figures started high on a page so they aren't split by a page
>> > >> > boundary.
>> > >> > > >
>> > >> > > > Section 2.2: suggest "The Open Trading Protocols identify" be
>> > >> changed
>> > >> > to
>> > >> > > > "IOTP identifies".
>> > >> > > > Section 2.2: says "IOTP Transactions are composed of these
>> > >> exchanges"
>> > >> > > but
>> > >> > > > does not list Inquiry or Ping exchange.
>> > >> > > >
>> > >> > > > Starting in section 2.3 and many other places in the document,
>> > words
>> > >> > or
>> > >> > > > phrases are prefixed and suffixed by an underscore character
>> > ("_").
>> > >> > > This
>> > >> > > > is not any normal IETF style.  I suspect it means that the
>> > original
>> > >> > text
>> > >> > > > is
>> > >> > > > italic.  These should be suppressed or if that is impossible,
a
>> > >> > separate
>> > >> > > > pass should be done to delete them.
>> > >> > > >
>> > >> > > > In Figure 9, the things which are supposed to be identical or
>> > match
>> > >> > > aren't
>> > >> > > > and don't.  Is that deliberate?
>> > >> > > >
>> > >> > > > I don't think that section 3.6 Brands and Brand Selection fits
>> > very
>> > >> > well
>> > >> > > > where it and suggest it be moved into section 10 which could
be
>> > >> > renamed
>> > >> > > > "Brands".
>> > >> > > >      Continuing on Brands, I looked around a bit in SET
>> > literature
>> > >> and
>> > >> > > > couldn't find anything about Dual or Promotional brands or
>> > anything
>> > >> > > about
>> > >> > > > a
>> > >> > > > three component SET Brand.  Two components, "brand" and
>> "product"
>> > I
>> > >> > see
>> > >> > > in
>> > >> > > > the SET literature, such a "MasterCard" or "Visa:Gold".  But
>> not
>> > >> A:B:C
>> > >> > > and
>> > >> > > > no case where a colon is included if there isn't anything
after
>> > it.
>> > >> > In
>> > >> > > > other words, it's "Visa", not "Visa:", and certainly not
>> "Visa::"
>> > as
>> > >> a
>> > >> > > SET
>> > >> > > > brand (re also examples in 6.6.1). Can anyone give me any
>> > references
>> > >> > to
>> > >> > > > shed light on this?
>> > >> > > >
>> > >> > > > Section 3.8.1: I don't understand why sub-pages of an HTML
main
>> > page
>> > >> > > > couldn't have links back to the main page.
>> > >> > > >
>> > >> > > > Section 4.1: first section reference says "0"?
>> > >> > > >
>> > >> > > > Figures 10 and 11: These flow diagrams each *almost* fit on a
>> > page.
>> > >> If
>> > >> > > the
>> > >> > > > initial "Input IOTP Message" box could be to the side with a
>
>
>
>
>> > >> > horizontal
>> > >> > > > arrow and the text were edited down to something a bit more
>> > terse,
>> > I
>> > >> > > think
>> > >> > > > they would, which would be quite helpful.
>> > >> > > >
>> > >> > > > Section 5: Suggest this section be called "Digital Signature"
>> or
>> > >> > > > something.
>> > >> > > > Usually an IETF Security Considerations section is brief and
>> > talks
>> > >> > about
>> > >> > > > really high level issues.  Material in 5.4 is appropriate for
>> > >> Security
>> > >> > > > Considerations.  A separate Security Considerations section
>> would
>> > >> need
>> > >> > > to
>> > >> > > > also say something about deciding when to require signatures,
>> > even
>> > >> if
>> > >> > it
>> > >> > > > is
>> > >> > > > just by referring to section 5.1.4, and about depending on
>> > payment
>> > >> > > scheme
>> > >> > > > security for the safety of funds, which I didn't see anywhere.
>> > >> > > >      Section 5 seems pretty heavy on certificates and public
>> key
>> > >> > crypto,
>> > >> > > > especially given the originally IOTP v1.0 was going to be
>> secret
>> > key
>> > >> > > only
>> > >> > > > and, as I recall, it was with some reluctance that public key
>> > hooks
>> > >> > were
>> > >> > > > added.  The stuff on checking a signature, for example, talks
>> > about
>> > >> > > > checking the certificate as if there always has to be one.
>> > >> > > >      Section 5.1.4: another reason you might not need
>> signatures
>> > is
>> > >> > the
>> > >> > > > that the sender and receiver were on the same machine so it
can
>> > >> check
>> > >> > > > integrity just by comparing with a saved copy.
>> > >> > > >
>> > >> > > > Section 6.4.2: Need to eliminate reference to "Open Trading
>> > Protocol
>> > >> > > > Consortium" and suggest dropping whole note. I don't see any
>> > >> > difference
>> > >> > > at
>> > >> > > > all between OkTo/OkFrom and amount.  Both could appear in
human
>> > >> > readable
>> > >> > > > form in the Order Description and in machine readable form in
>> > their
>> > >> > > > element.  Recommending that the UI display the machine
readable
>> > >> > version
>> > >> > > is
>> > >> > > > reasonable (as in 6.4.1).
>> > >> > > >
>> > >> > > > ContentSoftwareId: the standard text given for this is quite
>> > length
>> > >> > and
>> > >> > > > repeated dozens of time.  If it could be moved to the glossary
>> or
>> > >> > > > something
>> > >> > > > and a simple "see glossary" put in, it would save many pages.
>> > >> > > >
>> > >> > > > As previously discussed, change ISO4217 to ISO4217A or the
>> like.
>> > >> > > >
>> > >> > > > Just before section 6.7, it says that examples exist in 6.6
>> when
>> > >> they
>> > >> > > are
>> > >> > > > in 10.
>> > >> > > >
>> > >> > > > Section 6.17: references to the Richard Brown draft and
>> probably
>> > not
>> > >> > > > appropriate.  RFCs are not supposed to refer to drafts.  About
>> > the
>> > >> > > future,
>> > >> > > > I'm not sure you need to say anything but if you do, I think
it
>> > >> should
>> > >> > > > just
>> > >> > > > say the future versions of IOTP will use industry standard XML
>> > >> > signature
>> > >> > > > technology if it meets IOTP requirements.
>> > >> > > >      Shouldn't 6.17.1 refer to the IOTP DSIG document?  It's
OK
>> > to
>> > >> > refer
>> > >> > > > to
>> > >> > > > that draft because the idea is that it and the main protocol
>> > >> document
>> > >> > > will
>> > >> > > > be issued as RFCs simultaneously.  Maybe the XMLDSIG reference
>> > >> should
>> > >> > > just
>> > >> > > > be changed to refer to the IOTP DSIG document.
>> > >> > > >      There is a reference in  6.17.1 to payment scheme
specific
>> > >> > > > algorithms.
>> > >> > > > Wouldn't their use be encapsulated inside the packaged
contents
>> > and
>> > >> be
>> > >> > > in
>> > >> > > > the payment scheme modules, not an IOTP implementation itself?
>> > >> > > >      Section 6.18: similarly for certificate reference.
Should
>> > >> point
>> > >> > > out
>> > >> > > > that certs not needed for symmetric keying or for cases where
>> > public
>> > >> > key
>> > >> > > > has been registered at recipient.
>> > >> > > >
>> > >> > > > Section 6.19.2: For ElContIllegal, ValueTooSmall, and
>> > ValueTooLarge,
>> > >> I
>> > >> > > > believe it should say "content" rather than "PackagedContent".
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > > TRIVIAL NITS:
>> > >> > > >
>> > >> > > > In the Abstract and section 1, Delivery Handler is capitalized
>> > but
>> > >> > > payment
>> > >> > > > handler isn't.
>> > >> > > >
>> > >> > > > It is not usual to have a section like 1.7, History, in an
IETF
>> > >> > > document.
>> > >> > > > If the evolution of a protocol sheds light on its technical
>> > content,
>> > >> > > > that's
>> > >> > > > one thing.  But it is not usual to have what is mostly a list
>> of
>> > >> > editing
>> > >> > > > versions.  Suggest it be dropped to shorten the document.
>> > >> > > >
>> > >> > > > I'm not sure why there is a skip to new page before section
3.1
>> > or
>> > >> > > 3.1.2.
>> > >> > > > Suggest dropping these to make the document more compact.  RFC
>> > style
>> > >> > is
>> > >> > > to
>> > >> > > > have no skips to the start of a new page anywhere in the body
>> > text.
>> > >> > > >
>> > >> > > > Section 3.8 example packaged content:  I don't like the
"Name"s
>> > >> > FirstMsg
>> > >> > > > and SecondMsg.  Using Msg => Message seems confusing.  Suggest
>> > >> > > FirstPiece
>> > >> > > > and SecondPiece.
>> > >> > > >
>> > >> > > > Section 3.10 says "Where both types of net location are
>> present,
>> > the
>> > >> > > > following rules apply:" and then gives three rules only the
>> third
>> > of
>> > >> > > which
>> > >> > > > applies in the described circumstances.  Suggest moving the
>> first
>> > >> two
>> > >> > up
>> > >> > > > and combining the quoted phrase with the third.
>> > >> > > >
>> > >> > > > Section 3.11.1 "treated by the recipient is an error": is ->
as
>> > >> > > >
>> > >> > > > Section 4: "There are a several ..." delete "a"
>> > >> > > >
>> > >> > > > Section 4.4.1.2: in first sentence has -> have.
>> > >> > > >
>> > >> > > > Section 4.4.2.9: in first sentence, insert "server" between
>> "the"
>> > >> and
>> > >> > > > "unless".
>> > >> > > >
>> > >> > > > Not sure why skip to new page before section 5.3.1 shortly
>> before
>> > >> > Figure
>> > >> > > > 14
>> > >> > > > which overflows onto next page by just one line...
>> > >> > > >
>> > >> > > > Section 5.3.1.1: numbered subsections, lettered
subsubsections:
>> > The
>> > >> > > text
>> > >> > > > at the ends of these 12 subsubsections is substantially the
>> same.
>> > >> > > > Starting
>> > >> > > > with 3)b) sometimes the final period is omitted.  Suggest
>> moving
>> > >> this
>> > >> > > text
>> > >> > > > up to the numbered section level or to before the whole two
>> level
>> > >> > list.
>> > >> > > >
>> > >> > > > Section 5.3.1.2: ditto 5.3.1.1 except list is one level.
>> > >> > > >
>> > >> > > > Section 6.1: towards the end, delete "the" from "that the
>> > should".
>> > >> > > >
>> > >> > > > Section 6.2: Insert "may be" after "there" in "there only
one".
>> > >> > > >
>> > >> > > > Section 6.5.5: PostalCode missing from detailed attributes
>> list.
>> > >> > > >
>> > >> > > > Just before 6.6.3 and 6.7.1: "in10" -> "in section 10".
>> > >> > > >
>> > >> > > > Suggest replacing occurrences of "SSL" with "SSL/TLS" and
>> adding
>> > the
>> > >> > TLS
>> > >> > > > RFC to the References.
>> > >> > > >
>> > >> > > > Section 6.11:  has "Plain/Text" where other similar sentences
>> use
>> > >> > "Plain
>> > >> > > > Text" which is probably better.  The "/" makes it look like a
>> > MIME
>> > >> > type
>> > >> > > > and
>> > >> > > > the MIME type is actually text/plain.  But I would suggest not
>> > using
>> > >> > the
>> > >> > > > MIME type as there isn't a unique one for HTML.
>> > >> > > >
>> > >> > > > Section 6.12.1: DelivReqNetLocn & SecDelivReqNotLocn:
>> "Mechanism
>> > >> must"
>> > >> > > ->
>> > >> > > > "Mechanism and must".
>> > >> > > >
>> > >> > > > Section 6.13: Content, should be "PackagedContent" not
>> "Delivery
>> > >> > Note".
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > > REFERENCES (section 14)
>> > >> > > >
>> > >> > > > For DOM-HASH, can't refer to any Internet-Drafts by URL or
>> > filename.
>> > >> > > For
>> > >> > > > HMAC, suggest refereing to RFC 2104 HMAC: Keyed-Hashing for
>> > Message
>> > >> > > > Authentication. H. Krawczyk, M. Bellare, R. Canetti. February
>> > 1997.
>> > >> > > >
>> > >> > > > It looks pretty odd to the IETF spelled out in the RFC
>> > references.
>> > >> > I've
>> > >> > > > never seen that in an IETF document references section.
>> > >> > > >
>> > >> > > > For SET, suggest referencing the SETco.org site, not
>> Mastercard.
>> > >> > Can't
>> > >> > > > reference the Brown XMLDSIG draft in an RFC (although you can
>> > talk
>> > >> > about
>> > >> > > > it
>> > >> > > > without a URL or file name reference if necessary).
>> > >> > > >
>> > >> > > >
>> > >> > > > Donald E. Eastlake, 3rd
>> > >> > > > 17 Skyline Drive, Hawthorne, NY 10532 USA
>> > >> > > > [email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
>> > >> > > >
>> > >> > > > home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
>> > >> > > > [email-masked]   tel: 1-914-276-2668
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> >
>> > -----------------------------------------------------------------------
>> > >> > > > Message addressed to: [email-masked]
>> > >> > > > Archive available at:
>> http://www.elistx.com/archives/ietf-trade/
>> > >> > > > To (un)subscribe send a message with "subscribe" or
>> "unsubscribe"
>> > in
>> > >> > the
>> > >> > > > body to: [email-masked]
>> > >> > > >
>> > >> > >
>> > >> > >
>> > >> >
>> > >>
>> >
>>
**************************************************************************
>> > >> > > ********************
>> > >> > >
>> > >> > > This Email and any attached files are confidential and may also
>> be
>> > >> > > privileged.
>> > >> > > If you are not the intended recipient, please notify the
>> postmaster
>> > >> > using
>> > >> > > email
>> > >> > > address [email-masked] or call +44 171 557 5000 and ask
>> for
>> > the
>> > >>
>> > >> > > IT Helpdesk.  You should not copy this email and any attached
>> > files,
>> > >> use
>> > >> > > them
>> > >> > > for any purpose or disclose the contents to any other person;
all
>> > >> copies
>> > >> > > of the
>> > >> > > Email and associated files in your possession should be
>> destroyed.
>> > >> > >
>> > >> > > Mondex International Limited
>> > >> > > 47-53 Cannon Street
>> > >> > > London EC4M 5SQ
>> > >> > > United Kingdom
>> > >> > > Registered No: 3122085, England
>> > >> > >
>> > >> > > Phone:          +44 171 557 5000
>> > >> > > Fax:            +44 171 557 5200
>> > >> > > Email:          [email-masked]
>> > >> > > WebSite:        http://www.mondexinternational.com
>> > >> > >
>> > >> > >
>> > >> >
>> > >>
>> >
>>
**************************************************************************
>> > >> > > *******************
>> > >> > >
>> > >>
>> -----------------------------------------------------------------------
>> > >> > > Message addressed to: [email-masked]
>> > >> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
>> > >> > > To (un)subscribe send a message with "subscribe" or
"unsubscribe"
>> > in
>> > >> the
>> > >> > > body to: [email-masked]
>> > >> > >
>> > >> >
>> > -----------------------------------------------------------------------
>> > >> > Message addressed to: [email-masked]
>> > >> > Archive available at: http://www.elistx.com/archives/ietf-trade/
>> > >> > To (un)subscribe send a message with "subscribe" or "unsubscribe"
>> in
>> > the
>> > >> > body to: [email-masked]
>> > >> >
>> > >>
>> > >>
>> >
>>
**************************************************************************
>> > >> ********************
>> > >>
>> > >> This Email and any attached files are confidential and may also be
>> > >> privileged.
>> > >> If you are not the intended recipient, please notify the postmaster
>> > using
>> > >> email
>> > >> address [email-masked] or call +44 171 557 5000 and ask for
>> the
>> > >> IT Helpdesk.  You should not copy this email and any attached files,
>> > use
>> > >> them
>> > >> for any purpose or disclose the contents to any other person; all
>> > copies
>> > >> of the
>> > >> Email and associated files in your possession should be destroyed.
>> > >>
>> > >> Mondex International Limited
>> > >> 47-53 Cannon Street
>> > >> London EC4M 5SQ
>> > >> United Kingdom
>> > >> Registered No: 3122085, England
>> > >>
>> > >> Phone:          +44 171 557 5000
>> > >> Fax:            +44 171 557 5200
>> > >> Email:          [email-masked]
>> > >> WebSite:        http://www.mondexinternational.com
>> > >>
>> > >>
>> >
>>
**************************************************************************
>> > >> *******************
>> > >>
>> -----------------------------------------------------------------------
>> > >> Message addressed to: [email-masked]
>> > >> Archive available at: http://www.elistx.com/archives/ietf-trade/
>> > >> To (un)subscribe send a message with "subscribe" or "unsubscribe" in
>> > the
>> > >> body to: [email-masked]
>> > >>
>> >
>-----------------------------------------------------------------------
>> > >Message addressed to: [email-masked]
>> > >Archive available at: http://www.elistx.com/archives/ietf-trade/
>> > >To (un)subscribe send a message with "subscribe" or "unsubscribe" in
>> the
>> > >body to: [email-masked]
>> > >
>> >
>> -----------------------------------------------------------------------
>> Message addressed to: [email-masked]
>> Archive available at: http://www.elistx.com/archives/ietf-trade/
>> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>> body to: [email-masked]
>>
>
>***************************************************************************
*******************
>
>This Email and any attached files are confidential and may also be
privileged.
>If you are not the intended recipient, please notify the postmaster using
email
>address [email-masked] or call +44 171 557 5000 and ask for the
>IT Helpdesk.  You should not copy this email and any attached files, use
them
>for any purpose or disclose the contents to any other person; all copies of
the
>Email and associated files in your possession should be destroyed.
>
>Mondex International Limited
>47-53 Cannon Street
>London EC4M 5SQ
>United Kingdom
>Registered No: 3122085, England
>
>Phone:          +44 171 557 5000
>Fax:            +44 171 557 5200
>Email:          [email-masked]
>WebSite:        http://www.mondexinternational.com
>
>***************************************************************************
******************
>-----------------------------------------------------------------------
>Message addressed to: [email-masked]
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: [email-masked]
>

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Cc: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: Question for IOTP Authentication
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Mon, 03 May 1999 00:19:45 +0900 (JST)
Lines: 327
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Tony mentioned to me the Mercahnt authentication has to do prior to
shopping phase, this is out of IOTP. So we can use separete
authentication only.

We need to define the SET Specific authentication, which
satisfy the requirement to the BAG Requirement, in SETCo.  because
consumer have to confirm whether Merchant is authorized by the
Acquirer and this requirement is payment dependent(IOTP is the payment
scheme independent messaging protocol).

I believe that the merit of using IOTP authentication is that we
can be concerned IOTP Authentication transaction with IOTP
Purchase transaction.

--
Yoshiaki Kawatsura Hitachi, Ltd.

>>>>> Fri, 30 Apr 1999 20:04:11 +0100,
	David Burdett <[email-masked]> said:

> Tony
> 
> I can think of three ways that IOTP might be able to meet the requirement
> you describe:
> *	using the Packaged Content element in the Pay Protocol element (see
> section 6.6.4),
> *	the Consumer authenticates the Merchant separately using an
> authentication transaction, or 
> *	a combination of the two.
> 
> Each is discussed in a bit more detail below.
> 
> PAY PROTOCOL ELEMENT
> This involves the merchant including the relevent certificate and message
> from the acquirer in the PackagedContent element in the Pay Protocol element
> for SET of the Brand List (see spec section  6.6.4), then if the Consumer
> wants to use SET for a payment they just pass the data to the SET payment
> software working within IOTP which then checks the credentials.
> 
> The advantage of this approach is that the certificate will always be there
> and no extra messages will be required to retrieve it. The disadvantage is
> that it increases the size of the messages.
> 
> SEPARATE CONSUMER AUTHENTICATION OF THE MERCHANT
> In this case, the SET software recognises that there a certificate and
> message from the acquirer is needed and makes a request to the IOTP software
> to obtain it. When this need occurs, a separate IOTP Authentication
> Transaction (see spec section 8.1.6) is used to get the information. 
> 
> This would involve:
> *	the Consumer sending an IOTPAuthentication Request message to the
> merchant specifying in the Algorithm element that the Merchant should do,
> for example, a SET merchant authentication, then
> *	the Merchant replying with a Authentication Response message
> including the necessary certificate and acquirer message in the Packaged
> Content.
> 
> COMBINATION
> An alternative might be to include some fingerprint of the
> certificate/message in the PayProtocol element, so that the consumer SET
> software can check if it already has a copy of it. If it hasn't then a
> separate consumer initiated IOTP Athentication of the merchant could be used
> to obtain it.
> 
> Does this make sense?
> 
> David
> 
> 
> 
> > ----------
> > From: 	Lewis, Tony[SMTP:[email-masked]]
> > Sent: 	29 April 1999 17:36
> > To: 	Yoshiaki KAWATSURA
> > Cc: 	Ietf Trade WG
> > Subject: 	RE: Question for IOTP Authentication
> > 
> > David,
> > 
> > I believe this proposal originates from requirements that SETCo has
> > defined
> > for SET 2.0 although when we discussed the approach outlined by Yoshiaki
> > at
> > our meeting last week, we recommended some changes.
> > 
> > I believe what we will need is the ability for the merchant to push some
> > data (certificates and a signed message from the acquirer) to the
> > cardholder
> > wallet who will use that data to authenticate the merchant. If that can be
> > accomplished with the existing authentication transaction then I believe
> > your change will satisfy our needs.
> > 
> > However, there may be other issues behind the input from Hitachi so
> > Yoshiaki
> > should also respond.
> > 
> > Tony
> > > ----------
> > > From: 	David Burdett[SMTP:[email-masked]]
> > > Sent: 	Thursday, April 29, 1999 4:00 PM
> > > To: 	Yoshiaki KAWATSURA
> > > Cc: 	Ietf Trade WG
> > > Subject: 	RE: Question for IOTP Authentication
> > > 
> > > Yoshiaki
> > > 
> > > As you can see I'm catching up on all the Trade WG emails and have
> > thought
> > > about your suggestion. In principle I can see why allowing a Consumer to
> > > authenticate a Merchant is reasonable as, in the current version of the
> > > specification, it states that a Conumer can authenticate a Payment
> > Handler
> > > or a Delivery Handler (see section 8.1.13 second bullet point) and
> > > therefore
> > > it is logical that a Consumer should also be able to authenticate a
> > > Merchant.
> > > 
> > > However the method you suggest below for authenticating a Merchant is
> > > different from the way the Consumer authenticates a Payment Handler or
> > > Delivery Handler in that it is integrated into the transaction (e.g a
> > > purchase) which implies a further variation on the message flow. So, I
> > > suggest that we meet your requirement by simply changing the first
> > bullet
> > > point in section 8.1.13 to read the authentication transaction can be
> > used
> > > ... " by a Consumer to authenticate a *Merchant*, Payment Handler or a
> > > Delivery Handler ..."
> > > 
> > > Is this OK?
> > > 
> > > David
> > > 		
> > > 
> > > > ----------
> > > > From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> > > > Sent: 	29 March 1999 22:45
> > > > To: 	[email-masked]
> > > > Cc: 	[email-masked]; [email-masked];
> > > [email-masked];
> > > > [email-masked]
> > > > Subject: 	RE: Question for IOTP Authentication
> > > > 
> > > > David,
> > > > I agree with your suggestion.
> > > > But I also want to add the Merchant Authenticaton by Consumer 
> > > > prior to IOTP Purchase Transaction.
> > > > 
> > > > These are the same flow as follows,
> > > > 
> > > > Consumer             Merchant
> > > >    <-------------------
> > > >          TPO
> > > > 
> > > >    ------------------->
> > > >       Auth Req
> > > > 
> > > >    <------------------
> > > >       Auth Res
> > > > 
> > > > and Status Block is not sent to the Merchant.
> > > > 
> > > > After Consumer receives the Auth Response,
> > > > 1. If prior to IOTP purchase transaction
> > > > Success: Consumer sends the message to the Success NetLocation.
> > > > Fail: Stop
> > > > 
> > > > 2. If in the IOTP Purchase Transaction
> > > > Success: Continue the transaction
> > > > Fail: Stop.
> > > > 
> > > > Make sense?
> > > > 
> > > > This is minor change and I think there is no affect in the IOTP
> > > protocol.
> > > > Regards,
> > > > ----
> > > > Yoshiaki Kawatsura : E-mail [email-masked]
> > > >  Business & Information Systems Development Devision, Hitachi,Ltd.
> > > > Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
> > > > 
> > > > 
> > > >  >>>>> Fri, 26 Mar 1999 18:20:48 -0000,
> > > > 	 David Burdett <[email-masked]> said:
> > > > 
> > > >  >Yoshiaki
> > > >  >
> > > >  >The current version of IOTP does not support authentication of the
> > > > Merchant
> > > >  >by the Consumer. Part of the reasoning behind this is that the
> > > Merchant
> > > > will
> > > >  >include a signature in the offer which can be used for this purpose.
> > > >  >HOwever, as you say, the consumer might not want to give address
> > > > information
> > > >  >until they have authenticated the Merchant.
> > > >  >
> > > >  >You could actually do this although section 8.1.13 does not
> > > specifically
> > > >  >state this. What would be requried is that, after the Consumer has
> > > > received
> > > >  >the TPO, he authenticates the merchant with a separate
> > Authentication
> > > >  >transaction and then if its  OK continues with the original
> > > transaction.
> > > >  >
> > > >  >Would this make sense? If you think it does then please post the
> > idea
> > > to
> > > > the
> > > >  >list. I don't know though if we want to include this in v1.0
> > although
> > > it
> > > >  >could easily go into v 2.0
> > > >  >
> > > >  >David
> > > >  >
> > > >  >> ----------
> > > >  >> From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> > > >  >> Sent: 	25 March 1999 22:46
> > > >  >> To: 	[email-masked]; [email-masked];
> > > > [email-masked]
> > > >  >> Cc: 	[email-masked]
> > > >  >> Subject: 	Question for IOTP Authentication
> > > >  >> 
> > > >  >> Don and David,
> > > >  >> I have a couple of question for IOTP Authentication.
> > > >  >> 
> > > >  >> Consumer wants to send private information such as home address to
> > > >  >> authenticated merchants only for Offer. In fact, SET is attempting
> > > to
> > > >  >> support simliar functionality. I believe that IOTP should support
> > > > this.
> > > >  >> 
> > > >  >> IOTP version 1.0 cannot do this function in Offer Exchange, since
> > > the
> > > >  >> Offer Exchange is simplified. The idea would be that initially
> > IOTP
> > > >  >> processes an Authentication, then a Web browser sends a private
> > > >  >> information for Offer, and finally IOTP does Purchase Transaction.
> > > In
> > > >  >> IOTP version 1.0, IOTP supports a Consumer Authentication by
> > > Merchant,
> > > >  >> however, IOTP does not support a Merchant Authentication by
> > > >  >> Consumer. Is this correct?
> > > >  >> 
> > > >  >> If this is correct, will IOTP version 2.0 support the Merchant
> > > >  >> Authentication by Consumer?
> > > >  >> 
> > > >  >> Regards,
> > > >  >> 
> > > >  >> --
> > > >  >> Yoshiaki Kawatsura
> > > >  >> Hitachi, Ltd.
> > > >  >> 
> > > >  >
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > >
> > **************************************************************************
> > > ********************
> > > 
> > > This Email and any attached files are confidential and may also be
> > > privileged. 
> > > If you are not the intended recipient, please notify the postmaster
> > using
> > > email 
> > > address [email-masked] or call +44 171 557 5000 and ask for the 
> > > IT Helpdesk.  You should not copy this email and any attached files, use
> > > them 
> > > for any purpose or disclose the contents to any other person; all copies
> > > of the 
> > > Email and associated files in your possession should be destroyed.
> > > 
> > > Mondex International Limited
> > > 47-53 Cannon Street
> > > London EC4M 5SQ
> > > United Kingdom
> > > Registered No: 3122085, England
> > > 
> > > Phone:          +44 171 557 5000
> > > Fax:            +44 171 557 5200
> > > Email:          [email-masked]
> > > WebSite:        http://www.mondexinternational.com
> > > 
> > >
> > **************************************************************************
> > > *******************
> > > -----------------------------------------------------------------------
> > > Message addressed to: [email-masked]
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > > body to: [email-masked]
> > > 
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> > 
> 
> **********************************************************************************************
> 
> This Email and any attached files are confidential and may also be privileged. 
> If you are not the intended recipient, please notify the postmaster using email 
> address [email-masked] or call +44 171 557 5000 and ask for the 
> IT Helpdesk.  You should not copy this email and any attached files, use them 
> for any purpose or disclose the contents to any other person; all copies of the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> *********************************************************************************************
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: PayReceiptRefs (Problem of IOTP Spec.)
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Mon, 03 May 1999 00:30:21 +0900 (JST)
Lines: 39
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

There is a problem for PayReceiptRefs in PayReceipt component in the
current IOTP specification.

Problem:
In the current specification, we can not use the PayReceiptRefs.  IOTP
Payment Bridge of the Payment Handler can not set the PayReceiptRefs
because the Bridge can not know IOTP Component ID.  IOTP Payment Bridge
of the Consumer can not also get the components correspond to IDs
which is included in the PayReceiptRefs.

So I suggest the following changes.
 
Change:
(a) Change PayReceiptRefs to PayReceiptRefNames element.
    (PayReceiptRefs is dropped)
(b) PayReceiptRefNames defines as the list of Name element in
    PackagedContent of PaySchemeData component.
(c) The Name element in PackagedContent must be unique in the transaction.
(d) The PaySchemeData Component, that Name element is the same ones 
in the token of PayReceiptRefNames, must be hashed and signed in the Payment
Response signature component.

Sequence of Process:
(1) The Payment Hander Payment Bridge set the PayReceiptRefNames.
(2) Payment Handler OAC hashes and signs to the corresponding PaySchemeData.
(3) Consumer OAC checks the signatures.
(4) OAC picks up the PackagedContents which include the same Name
    element in PayReceiptRefNames and passes them to the Payment Bridge as
    PayReceiptPackagedContent in the CheckPayReceipt.

What do you think this?

P.S. I can not response till 9th May because I will go to Thai Land in
vacation.
 
Thanks,
--
Yoshiaki Kawatsura

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]