Subject: IOTP and Tax Collection
From: David Burdett <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Tue, 1 Dec 1998 01:40:10 -0000

This e-mail describes a potential way in which IOTP could be used to
facilitate the recording and collection of tax information associated
with e-commerce.

It is has been produced after review, at the IOTP meeting in Tokyo on
9-11 November, of a discussion paper titled "Electronic Commerce: A
Discussion Paper on Taxation Issues". This paper was produced by the
OECD Committee on Fiscal Affairs and presented at the OECD Ministerial
level meeting, "A Borderless World - Realising the Potential of Global
Electronic Commerce", hosted by the Government of Canada and held in
Ottawa on 7-9 October 1998.

The full document is available from:

http://www.oecd.org/daf/fa/MATERIAL/50DIS-PA.pdf

The purpose of this e-mail is to stimulate discussion of the topic. The
ideas this document contains are NOT completely formed. Therefore input
from Revenue Authorities, representatives from the OECD or anyone else
with an interest in this area will be particularly welcome.

================================
OECD AND ELECTRONIC COMMERCE

The OECD discussion paper "Electronic Commerce: A Discussion Paper on
Taxation Issues" identifies a number of issues associated with taxation
on the Internet that need to be resolved. This paper also presents a
number of "Implementation Options" to resolve these issues in order to
"stimulate discussion with business".

Implementation Option 15 states that:

"Revenue authorities may consider expressing their views on information
requirements to appropriate bodies developing standards or protocols for
electronic commerce:
*	Revenue authorities have, wherever possible, used or adapted
commercial developments for taxation purposes so as to avoid the
creation of a separate and burdensome tax regime. However, modifying
systems after they have been finalised is costly and should be avoided
where possible. Revenue authorities could co-operate with business
initiatives to create protocols for trade that facilitate electronic
offers, delivery, payment and documentation and express their views in a
timely manner to the bodies developing such protocols or standards so
that they can be developed, taking into account the views of Revenue
authorities.
*	Further, private sector groups aiming at the introduction of new
technical standards or protocols for electronic commerce could
co-operate by contacting Revenue authorities, e.g. through the OECD, at
an early stage to enhance a constructive dialogue designed to find
mutually acceptable solutions."

This note is a response to the last point and covers:
*	Some background on Internet taxation
*	Identifying tax paying organisations
*	Tax records
*	Conclusion

BACKGROUND

Currently the vast majority of international cross-border transactions
involving services or electronic products give rise to income tax in
either the "source" or the "residence' country. The rules which apply
depend on the relevant tax treaty or domestic tax legislation between
the country(ies) concerned.

Similarly the vast majority of international cross-border transactions
in services or digital products are legally subject to consumption tax
(usually a "value added" tax or "goods and services" / "sales" tax). In
some cases the tax rate may be set to zero in order to encourage
"exports" resulting in no tax actually being collected.

For some individual countries (e.g. the USA) domestic consumption tax
rates may also be set to zero. For example if you buy goods from a state
different to your place of residence, then no consumption tax is
normally due at the time of the sale.

As electronic commerce makes it easier to do international (or
inter-state) trade it may start to displace more conventional forms of
commerce leading to a decrease in the tax revenues received by revenue
authorities.

Revenue authorities are unlikely to allow this to occur and may start
raising discriminatory new taxes unless a electronic commerce tax
collection process is available that is: practical to implement, cost
efficient and non-discriminatory.

Currently revenue authorities rely on companies to keep financial
accounts which are verified by independent auditors to ensure that tax
records are kept accurately. They also rely on these organisations to
provide tax returns which identify the tax which is due.

Tax calculations are based primarily on where the goods or services are
consumed and/or on the source and residence countries of the parties
involved. It is likely that this principle will continue to apply in
both international as well as domestic e-commerce. This means that it is
necessary for organisations (e.g. the buyer and the seller) to identify
themselves, their location and therefore the legal jurisdiction and tax
regime which will apply.

To sum up organisations will need to:
*	provide a means of identifying themselves,
*	keep tax records for the e-commerce business they carry out, and
*	allow those tax records to be independently audited.

The Internet Open Trading Protocol could help in these areas.

IDENTIFYING TAX PAYING ORGANISATIONS

The IOTP defines an "Organisation" element which can be used to identify
the different parties involved in an e-commerce transaction. This
element could easily contain the information necessary to identify a tax
payer by specifying, for example:
*	name
*	address/place of business
*	tax reference, etc

In addition the information can be digitally signed by an organisation
that is known and trusted by the consumer or other parties, such as
revenue authorities, that are involved in the trade.

If information is kept for both the buyer and the seller, then it should
be possible to use this information to help determine the tax which is
due.

TAX RECORDS

The IOTP defines an "offer" element which could be used to record
information about the tax which is included in the payment which is
being made. This could include information about:
*	the tax jurisdiction which applies
*	the parties (organisations) involved in the transaction
*	the rate(s) used to calculate the tax
*	the amount of tax due.

Several sets of tax information could be kept so that, for example,
local, state, national and international levels of tax could be
separately recorded if necessary.

Through working with revenue authorities, it should be possible to
define a format for the definition of a "tax record' so that it is
generally applicable to many if not all tax jurisdictions.

As with the organisation element, information in a tax record could be
digitally signed by a trusted organisation which means the information
could be relied upon.

If such a form of record were defined and used, then it would mean:
*	financial auditors could more easily check tax records for their
accuracy using automated software tools,
*	it could be used to substantiate tax returns which were made by
companies,
*	tax authorities could more easily rely on the information the tax
returns contained.

Financial auditors could also use the records on behalf of shareholders
for annual reports and other purposes.

CONCLUSION

IOTP could be used to help simplify tax collection on the Internet.
Views and opinions on this idea are actively sought.

>Mondex International Limited
mailto:<[email-masked]>
>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]

To: [email-masked]
cc: [email-masked]
Subject: Conference Call, IETF Meeting
Date: Thu, 26 Nov 1998 13:31:52 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I'd like to try some telephone conference calls in the TRADE WG.
These are sort of a continuation of conference calls that the OTP
Consortium used to have.  I've set up four of them, approximately
every other week except for a larger gap around the holidays.  They
are Thursday morning at 9am eastern US time as follows:
        December 3 and 17 at +1-212-547-0300 and
        January 7 and 21 at +1-212-547-0212
all with passcode 90216.  I'll try to send out a reminder the day
before.  Feel free to call in.

In addition, the full Agenda is now up on the www.ietf.org web site
and as expected, the TRADE WG meeting is Wednesday afternoon at 1pm in
the Boca Raton/Cocoa room.

Thanks
Donald

=====================================================================
 Donald E. Eastlake 3rd   +1 978-287-4877    [email-masked]
 318 Acton Street         +1 978-371-7148(fax)       [email-masked]
 Carlisle, MA 01741 USA   +1 914 784 7913
-----------------------------------------------------------------------
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: Tue, 24 Nov 1998 11:32:01 +0000
Subject: IOTP Architecture
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--Message-Boundary-11353
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

Hi,

the IOTP Architecture and Payment API document has
been updated. The current version 1.0.0 complies
with the recent draft 02 of the IOTP V1.0 protocol.
However, it does not address the recent change requests that
are currently under discussion. Once they are agreed,
I will add these changes to the document.

Donald, you are encouraged to replace the published
document with the updated version. Thanks.

Werner
------------------------------
Werner Hans - Systemanalytiker
IKOSS VAN
Pascalstrasse 19
D-52076 Aachen
Tel.: +49 -2408 148349
<www.ikossvan.de>

--Message-Boundary-11353
Content-type: text/plain; charset=US-ASCII
Content-description: Information about this message.

This message contains a file prepared for transmission using the
MIME BASE64 transfer encoding scheme. If you are using Pegasus
Mail or another MIME-compliant system, you should be able to extract
it from within your mailer. If you cannot, please ask your system
administrator for help.

   ---- File information -----------
     File:  iotpar10.zip
     Date:  24 Nov 1998, 11:28
     Size:  729491 bytes.
     Type:  ZIP-archive

--Message-Boundary-11353
Content-type: Application/ZIP; name=iotpar10.zip
Content-disposition: attachment; filename="iotpar10.zip"
Content-transfer-encoding: BASE64

--Message-Boundary-11353--
-----------------------------------------------------------------------
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, 24 Nov 1998 16:03:29 +0900
To: David Burdett <[email-masked]>
From: Masaaki Hiroya <[email-masked]>
Subject: RE: Sending a Cancel Message to the Server from the Client
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

If possible, I'd like you to put it in version 1.0, but if it delays
releasing version 1.0, I'll wait for version 2.0.

Masaaki

At 17:47 98/11/23 -0000, David Burdett wrote:
> Thanks for your comments.
> 
> Do you think this is a change needed for version 1.0 or should/could 
> it wait for version 2.0?
> 
> David
> 
> ----------
> From: 	Masaaki Hiroyo
> Sent: 	19 November 1998 17:44
> To: 	David Burdett
> Cc: 	[email-masked]'
> Subject: 	RE: Sending a Cancel Message to the Server from the Client
> 
> 
> David
> 
> I agree with your idea to send a cancel message back to the
> "xxxRequestLocn" with the Status Component in the Cancel Block.
> 
> Masaaki
> 
> 
> At 19:04 98/11/19 -0000, David Burdett wrote:
> > Masaaki
> >
> > I agree with the need for a cancel function so that the server is
> > informed if the user cancels a transaction.
> >
> > I am more inclined to your CancelLogNetLocn idea since this is 
> really a
> > business error rather than a technical error but couldn't we just 
> send a
> > message back to the "xxxRequestLocn" instead since the location is
> > probably expecting a reply anyway?
> >
> > As it is a business error, I think the Consumer should send message
> > containing a Status Component to the appropriate trading role with 
> the
> > "ProcessState" attribute set to "Failed" and the "CompletionCode"
> > attribute set to say "Cancelled". This could be included in a 
> simple
> > Cancel Block.
> >
> > Thoughts?
> >
> > David
> >
> > >----------
> > >From: 	Masaaki Hiroyo
> > >Sent: 	19 November 1998 02:02
> > >To: 	David Burdett
> > >Cc: 	[email-masked]
> > >Subject: 	Sending a Cancel Message to the Server from the Client
> > >
> > >
> > >David,
> > >
> > >As far as I read in the OTP specification, I couldn't find
> > >how to send to a server a message which indicates the transaction
> > >was cancelled by the consumer.
> > >
> > >There are some cases where the consumer wants to quit the
> > >transaction (at the time of selecting brands, confirming an 
> invoice,
> > >inserting an electronic cash card to its reader/writer, or 
> confirming
> > >payment information, because he/she changes his/her mind or finds
> > >some mistakes in his/her order.
> > >
> > >If there is no element which indicates "cancel" in OTP sent from
> > >the client to the server, the server has to wait for a message or
> > >until a "timeout" event occurs.
> > >
> > >Therefore, I think a message should be sent to the 
> CancelLogNetLocn.
> > >The CancelLogNetLocn would have a similar syntax and role as the
> > >ErrorLogNetLocn.  Besides we have to define a "cancel component".
> > >An alternative solution is to send a message to the ErrorNetLocn
> > >with an ErrorCode = "Cancel" or a Severity = "Cancel".
> > >
> > >Any comments?
> > >
> > >Regards
> > >Masaaki
> > >
> > >
> > >-----
> > >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]
> >
> >
> -----
> 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]
> 
> 
> 
> $BI|85$5$l$?E:IU%U%!%$%k!'(J"c:\program
 files\eudora\attach\RESendingaCancelMessageto1"
> 
-----
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: Masaaki Hiroyo <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Sending a Cancel Message to the Server from the Client
Date: Mon, 23 Nov 1998 17:47:24 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Thanks for your comments.

Do you think this is a change needed for version 1.0 or should/could it
wait for version 2.0?

David

>----------
>From: 	Masaaki Hiroyo
>Sent: 	19 November 1998 17:44
>To: 	David Burdett
>Cc: 	[email-masked]'
>Subject: 	RE: Sending a Cancel Message to the Server from the Client
>
>
>David
>
>I agree with your idea to send a cancel message back to the
>"xxxRequestLocn" with the Status Component in the Cancel Block.
>
>Masaaki
>
>
>At 19:04 98/11/19 -0000, David Burdett wrote:
>> Masaaki
>> 
>> I agree with the need for a cancel function so that the server is
>> informed if the user cancels a transaction. 
>> 
>> I am more inclined to your CancelLogNetLocn idea since this is really a
>> business error rather than a technical error but couldn't we just send a
>> message back to the "xxxRequestLocn" instead since the location is
>> probably expecting a reply anyway?
>> 
>> As it is a business error, I think the Consumer should send message
>> containing a Status Component to the appropriate trading role with the
>> "ProcessState" attribute set to "Failed" and the "CompletionCode"
>> attribute set to say "Cancelled". This could be included in a simple
>> Cancel Block.
>> 
>> Thoughts?
>> 
>> David
>> 
>> >----------
>> >From: 	Masaaki Hiroyo
>> >Sent: 	19 November 1998 02:02
>> >To: 	David Burdett
>> >Cc: 	[email-masked]
>> >Subject: 	Sending a Cancel Message to the Server from the Client
>> >
>> >
>> >David,
>> >
>> >As far as I read in the OTP specification, I couldn't find
>> >how to send to a server a message which indicates the transaction
>> >was cancelled by the consumer.
>> >
>> >There are some cases where the consumer wants to quit the 
>> >transaction (at the time of selecting brands, confirming an invoice,
>> >inserting an electronic cash card to its reader/writer, or confirming
>> >payment information, because he/she changes his/her mind or finds 
>> >some mistakes in his/her order.
>> >
>> >If there is no element which indicates "cancel" in OTP sent from 
>> >the client to the server, the server has to wait for a message or
>> >until a "timeout" event occurs.
>> >
>> >Therefore, I think a message should be sent to the CancelLogNetLocn.
>> >The CancelLogNetLocn would have a similar syntax and role as the 
>> >ErrorLogNetLocn.  Besides we have to define a "cancel component".
>> >An alternative solution is to send a message to the ErrorNetLocn
>> >with an ErrorCode = "Cancel" or a Severity = "Cancel".
>> >
>> >Any comments?
>> >
>> >Regards
>> >Masaaki
>> >
>> >
>> >-----
>> >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]
>> 
>> 
>-----
>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]
>
-----------------------------------------------------------------------
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: TADE WG scheduling @ IETF 43
Date: Mon, 23 Nov 1998 11:43:52 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

As far as our AD knows, we are scheduled for the first slot after
lunch on Wednesday.  Exactly when this will be posted on the IETF web
site is not known but should be very soon.

Thanks,
Donald

=====================================================================
 Donald E. Eastlake 3rd   +1 978-287-4877    [email-masked]
 318 Acton Street         +1 978-371-7148(fax)       [email-masked]
 Carlisle, MA 01741 USA   +1 914 784 7913
-----------------------------------------------------------------------
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, 23 Nov 1998 07:53:48 -0800
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: draft-rfced-info-blinov-00.txt
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

GAIA seems (without deep reading) perfectly reasonable, if actual
suppliers and customers want to use it.  I know of two efforts that
involve actual suppliers and customers (Rosetta Net and Commerce Net's
ECO Framework Working Group), neither of them open in the IETF
manner.  Without leaking information I shouldn't, it's fair to say
that Rosetta Net pretty much assumes that you know where to find
a supplier and the the ECO FW WG is pursuing a component-based
model in which GAIA Brokers would fit as components.

regards, Terry Allen

  Terry Allen    Electronic Commerce and Publishing Consultant    
			tallen[at]sonic.net
                   http://www.sonic.net/~tallen/
          DocBook:  http://www.ora.com/davenport/index.html
	 Common Business Library:  http://www.veosystems.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]
Subject: Re: Version 1.0 changes from Hitachi IOTP meeting 9-11 November, Tokyo 
Date: Mon, 23 Nov 1998 10:06:32 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Hi,

From:  Tom Arnold <[email-masked]>
Message-Id:  <[email-masked]>
Date:  Sun, 22 Nov 1998 16:54:18 -0800
To:  Dave Birch <[email-masked]>
Cc:  "[email-masked]'" <[email-masked]>
In-Reply-To:  <[email-masked]>

>At 07:12 PM 11/17/98 +0000, Dave Birch wrote:
>>David Burdett said
>>
>>>1)	Packaged Content. There is a need for Packaged Content to contain
>>>multiple items of data e.g. in the Pay Receipt Component, to support
>>>encapsulation of SET messages. To support this propose the following
>>>amendment to the Packaged Content element (see section 3.7.1):
>>
>>Wouldn't it greatly simplify IOTP and speed the time to market if we got 
>>rid of SET altogether? See for example

I don't know how many times I have to say it but IOTP does not depend
on SET or on any other particular payment protocol.  One way to view
SET is simply as a stress test for IOTP's payment system handling
facilities.  If a few relatively minor tweaks to IOTP such as the one
mentioned above enable IOTP to easily encapsulate a wider variety of
payment protocols, including SET, this seems like a good thing.

>If time to market (IE., doing anything over the next 5 years) is important,
>than moving ALL SET work to a later version is a must. Even VISA has backed
>off of SET in a VERY big way.  

I do not agree.  I expect the IOTP V1.0 specification to be ready for
WG last call within a few weeks.  I think the separate SET/IOTP
supplement is nearing completion, although it is not in IETF format
yet, but that is beside the point.  It is not on the critical path
for the specification document since IOTP does not depend on SET.

Hitcahi people indicated at the Tokyo meeting that it and Fujitsu and
NTT, along with a number of banks, cards, and merchants, will be
implementing a pilot system on the Internet with IOTP that includes
multiple payment systems one of which is SET.  It seems to me better
for this to be accomodated than for them to have to do something
proprietary.  And I would point out that it has been Hitachi personel
who have been doing the vast bulk of the work on the IOTP/SET
supplement.

>Millions of SSL protected transactions are being run each month with an
>estimated 30% monthly growth rate. In the US, not a single SET transaction
>has moved. SSL and SET are like VHS and Betamax. VHS won the day!

I could discuss the above statements, but it would be pointless since
IOTP does not depend on SET.

>> [snip]
>
>Tom Arnold
>Vice President of Engineering
>CyberSource Corporation
>[email-masked]

Since IOTP does not depend on SET, I suggest that arguements as to
exactly how alive or dead SET is in the US or other parts of the world
are not directly relevant to this working group.

The aim thus for for V1.0 has been a stand alone specification
document, a supplemental Architecture/API document, one or more
payment systems supplements (of which SET and SCCD (Secure Channel
Credit/Debit) have seen progress), and one or more transport
supplements (of which an HTTP draft exists).  If anyone wants to
suggest a different suite of documents, we can discuss that.  But as
long as there are volunteers within the working group to do a
supplement for a particular payment system or transport, it is not
clear to me why they shouldn't go ahead.

Thanks,
Donald
-----------------------------------------------------------------------
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: draft-rfced-info-blinov-00.txt
Date: Mon, 23 Nov 1998 09:39:40 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Hi,

About a month ago our Area Director asked this working group to look
at the
<ftp://ftp.ietf.org/internet-drafts/draft-rfced-info-blinov-00.txt>
draft and provide comments.  I have no seen any such comments and I
just got a query, reasonably enough, from the author of that draft
asking how it was going.

So, please, anyone who has the time should look at this draft.  You
can post comments to the WG list or send them to me.  (If you send
comments directly to our Area Director or to the draft author, please
tell me so I will know you have done so.)

Thanks,
Donald
=====================================================================
 Donald E. Eastlake 3rd   +1 978-287-4877    [email-masked]
 318 Acton Street         +1 978-371-7148(fax)       [email-masked]
 Carlisle, MA 01741 USA   +1 914 784 7913
-----------------------------------------------------------------------
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: Sun, 22 Nov 1998 16:54:18 -0800
To: Dave Birch <[email-masked]>
From: Tom Arnold <[email-masked]>
Subject: Re: Version 1.0 changes from Hitachi IOTP meeting 9-11 November, Tokyo
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

At 07:12 PM 11/17/98 +0000, Dave Birch wrote:
>David Burdett said
>
>>1)	Packaged Content. There is a need for Packaged Content to contain
>>multiple items of data e.g. in the Pay Receipt Component, to support
>>encapsulation of SET messages. To support this propose the following
>>amendment to the Packaged Content element (see section 3.7.1):
>
>Wouldn't it greatly simplify IOTP and speed the time to market if we got 
>rid of SET altogether? See for example
>

If time to market (IE., doing anything over the next 5 years) is important,
than moving ALL SET work to a later version is a must. Even VISA has backed
off of SET in a VERY big way.  

Millions of SSL protected transactions are being run each month with an
estimated 30% monthly growth rate. In the US, not a single SET transaction
has moved. SSL and SET are like VHS and Betamax. VHS won the day!

> [snip]

Tom Arnold
Vice President of Engineering
CyberSource Corporation
[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]

Date: Fri, 20 Nov 1998 10:44:27 +0900
To: David Burdett <[email-masked]>
From: Masaaki Hiroya <[email-masked]>
Subject: RE: Sending a Cancel Message to the Server from the Client
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David

I agree with your idea to send a cancel message back to the
"xxxRequestLocn" with the Status Component in the Cancel Block.

Masaaki

At 19:04 98/11/19 -0000, David Burdett wrote:
> Masaaki
> 
> I agree with the need for a cancel function so that the server is
> informed if the user cancels a transaction. 
> 
> I am more inclined to your CancelLogNetLocn idea since this is really a
> business error rather than a technical error but couldn't we just send a
> message back to the "xxxRequestLocn" instead since the location is
> probably expecting a reply anyway?
> 
> As it is a business error, I think the Consumer should send message
> containing a Status Component to the appropriate trading role with the
> "ProcessState" attribute set to "Failed" and the "CompletionCode"
> attribute set to say "Cancelled". This could be included in a simple
> Cancel Block.
> 
> Thoughts?
> 
> David
> 
> >----------
> >From: 	Masaaki Hiroyo
> >Sent: 	19 November 1998 02:02
> >To: 	David Burdett
> >Cc: 	[email-masked]
> >Subject: 	Sending a Cancel Message to the Server from the Client
> >
> >
> >David,
> >
> >As far as I read in the OTP specification, I couldn't find
> >how to send to a server a message which indicates the transaction
> >was cancelled by the consumer.
> >
> >There are some cases where the consumer wants to quit the 
> >transaction (at the time of selecting brands, confirming an invoice,
> >inserting an electronic cash card to its reader/writer, or confirming
> >payment information, because he/she changes his/her mind or finds 
> >some mistakes in his/her order.
> >
> >If there is no element which indicates "cancel" in OTP sent from 
> >the client to the server, the server has to wait for a message or
> >until a "timeout" event occurs.
> >
> >Therefore, I think a message should be sent to the CancelLogNetLocn.
> >The CancelLogNetLocn would have a similar syntax and role as the 
> >ErrorLogNetLocn.  Besides we have to define a "cancel component".
> >An alternative solution is to send a message to the ErrorNetLocn
> >with an ErrorCode = "Cancel" or a Severity = "Cancel".
> >
> >Any comments?
> >
> >Regards
> >Masaaki
> >
> >
> >-----
> >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]
> 
> 
-----
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: Masaaki Hiroyo <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Sending a Cancel Message to the Server from the Client
Date: Thu, 19 Nov 1998 19:04:39 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Masaaki

I agree with the need for a cancel function so that the server is
informed if the user cancels a transaction. 

I am more inclined to your CancelLogNetLocn idea since this is really a
business error rather than a technical error but couldn't we just send a
message back to the "xxxRequestLocn" instead since the location is
probably expecting a reply anyway?

As it is a business error, I think the Consumer should send message
containing a Status Component to the appropriate trading role with the
"ProcessState" attribute set to "Failed" and the "CompletionCode"
attribute set to say "Cancelled". This could be included in a simple
Cancel Block.

Thoughts?

David

>----------
>From: 	Masaaki Hiroyo
>Sent: 	19 November 1998 02:02
>To: 	David Burdett
>Cc: 	[email-masked]
>Subject: 	Sending a Cancel Message to the Server from the Client
>
>
>David,
>
>As far as I read in the OTP specification, I couldn't find
>how to send to a server a message which indicates the transaction
>was cancelled by the consumer.
>
>There are some cases where the consumer wants to quit the 
>transaction (at the time of selecting brands, confirming an invoice,
>inserting an electronic cash card to its reader/writer, or confirming
>payment information, because he/she changes his/her mind or finds 
>some mistakes in his/her order.
>
>If there is no element which indicates "cancel" in OTP sent from 
>the client to the server, the server has to wait for a message or
>until a "timeout" event occurs.
>
>Therefore, I think a message should be sent to the CancelLogNetLocn.
>The CancelLogNetLocn would have a similar syntax and role as the 
>ErrorLogNetLocn.  Besides we have to define a "cancel component".
>An alternative solution is to send a message to the ErrorNetLocn
>with an ErrorCode = "Cancel" or a Severity = "Cancel".
>
>Any comments?
>
>Regards
>Masaaki
>
>
>-----
>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: "[email-masked]'" <[email-masked]>
Subject: IOTP version 2.0 ideas
Date: Thu, 19 Nov 1998 16:02:52 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This note describes ideas for Version 2 of  IOTP. It contains
1)	Suggested enhancements which were identified before the IOTP meeting
in Tokyo. These have been documented previously but are included for
completeness
2)	Suggested enhancements identified during the IOTP meeting in Tokyo,
and
3)	A possible structure for the version 2.0 specification. The main
change is to split the existing specification into several smaller
separate specifications which address specific topics. This should make
the specification more reusable and accessible.

Comments are welcome

David

SUGGESTED ENHANCEMENTS PRIOR TO TOKYO MEETING
=============================================
1)	Change the Authentication Trading Exchange so that it now includes an
Authentication Exchange message to occur between the Authentication
Request and the Authentication Response (see Chris Smith e-mail).
2)	Add an optional Offer Request Block to be included in a message to
the Merchant that precedes the Offer Response message from the Merchant
to the Consumer. It could be used to contain, for example, purchase
order details
3)	Include Authentication Method Selection as an option for version 2.0
4)	Develop messages to support reconciliation between the trading roles
in IOTP. This would allow, for example, a Payment Handler to report the
results of a payment to a Merchant in a standard way.
5)	Develop messages/transactions to support Merchant Customer Care.
6)	Revise the Pay Amount Component to support multiple payment amounts
for recurring (e.g. subscription) payments.

ENHANCEMENTS SUGGESTED DURING TOKYO MEETING
===========================================
1)	Extending OTP. The current way of using a "Critical"attribute to
define elements which are extensions to OTP means that a validating XML
parser cannot be used to check messages. This means that if you come
across a message with extensions and a validating parser is used, then
the message cannot be examined at all since it will fail the message. An
alternative would be to define a separate element designed to hold
extensions with content type of ANY.
a)	Advantages of this approach would mean that the OTP messages with
extensions could checked using a validating XML parser
b)	The disadvantage is that extensions to IOTP messages could only occur
in specific places.
c)	Needs further discussion to resolve - Action: Chris Smith will post
separate message Trade WG
2)	Add an additional optional Order Payment Annotation element to the
Order Description Component. The purpose of the element is to enable
various amounts which relate to the Order to be recorded. This could be
used, for example to describe:
a)	the tax paid on the order
b)	loyalty points acquired
c)	the fee paid on a withdrawal or value exchange
d)	Action David Burdett provide write up and post to Trade WG list

POSSIBLE STRUCTURE FOR VERSION 2 SPECIFICATION(S)
=================================================
This section describes ideas for the structure of version 2. 

The following principles were thought good ones to follow:
1)	re-work the structure of version 1.0 into several separate documents
to make it more modular and accessible. This would mean that parts of
IOTP could be more easily referenced and used by other e-commerce
standards where appropriate.
2)	adopt an evolutionary approach, by re-structuring the existing
protocol and so aim to preserve current implementer's investment in
development wherever possible
3)	provide new functionality in separate documents - e.g. dynamic
sequencing of steps/services
4)	Aim for no radical re-working of the current architecture, design or
content of IOTP.

There would be several separate documents:
1)	IOTP Overview - a guide on how to use all the other documents.
2)	IOTP Messaging - how to exchange data reliably between trading roles
3)	IOTP Offer/Payment/Delivery/Authentication Trading Exchange (4
separate documents)
4)	IOTP Baseline Transactions
5)	IOTP Dynamic Transactions - how to sequence steps in a transaction
dynamically
6)	IOTP Customer Care Exchange
7)	IOTP Inter Trading Role Reporting Exchange
8)	IOTP Payment Supplements (as now)
9)	IOTP Transport Supplements (as now)

Where relevant, each part would have its own separate DTD.

In the outlines of each document which follow, the numbers in brackets,
indicate the number of the relevant section in the version 1-0
specification which would form the basis of the new document.

IOTP OVERVIEW

This document should be read first and provides an overview of the other
documents

It includes information from the Business Specification.

IOTP MESSAGING

Would explain how to exchange information between the Trading Roles in
e-commerce. It would be generic and not define or refer to any specific
trading role or transaction apart from some examples.

Contents:
1)	IOTP Overview
a)	Architecture
i)	Trading Role principles (2.1)
ii)	Trading Exchange principles (2.2)
b)	Messages and Transactions
i)	IOTP Message Structure (3.1.1)
ii)	IOTP Transactions (3.1.2)
iii)	IOTP Message (3.2)
c)	Guidelines for creating Transactions from blocks and components
2)	Common concepts
a)	Trans reference block (3.3)
b)	ID attributes (3.4)
c)	Element References (3.5)
d)	Packaged Content Element (3.8)
e)	Identifying Languages (3.9)
f)	Secure and Insecure Net Locations (3.10)
g)	Extending IOTP (3.7)
3)	IOTP Error handling (4)
4)	Security Considerations (5)
5)	Components:
a)	Organisation Component (6.5)
b)	Status Component (6.15)
c)	Trading Role Data Component (6.16)
d)	Inquiry Type Component (6.17)
e)	Signature Component (6.18) - refers to Dsig proposal
f)	Error Component (6.19)
6)	Trading Blocks
a)	TPO Block ? (7.1)
b)	TPO Selection Block ? (7.2)
c)	Signature Block (7.18)
d)	Error Block (7.19)
7)	Transactions
a)	Inquiry Transaction
i)	Transaction Message flow (8.8)
ii)	Inquiry Request Trading Block (7.14)
iii)	Inquiry Response Trading Block (7.15)
b)	Ping Transaction
i)	Transaction Message flow (8.9)
ii)	Ping Request Block (7.16)
iii)	Ping Response Block (7.17)
8)	IOTP Message DTD definition

IOTP PAYMENT TRADING EXCHANGE

Defines how to do a payment. 

The payment exchange would have its own version number. This means that
payment exchange could evolve independently of other parts of the IOTP
specification.

Contents:
1)	Introduction
2)	Payment Handler Trading Role (from 2.1)
3)	Payment Exchange (2.2.2 - part)
4)	Brand Selection Exchange (2.2.2 - part)
5)	Brands and Brand Selection (3.6)
6)	Components
a)	Brand List Component (6.6)
b)	Brand Selection Component (6.7)
c)	Payment Component (6.8)
d)	Payment Scheme Component (6.9)
e)	Payment Receipt Component (6.10)
f)	Payment Note Component (6.11)
7)	Blocks:
a)	Payment Request Block (7.6)
b)	Payment Exchange Block (7.7)
c)	Payment Response Block (7.8)
8)	Status Component
a)	valid codes for payment
9)	Error Component
a)	codes to apply for payments
10)	Retrieving Logos (9)
11)	Brand List Examples (10)
12)	Payment DTD definition

IOTP OFFER/DELIVERY/AUTHENTICATION EXCHANGE

These would be separate documents each similar in structure to Payment
Trading Exchange.

Enhancements would be included where agreed, for example "Offer
Request".

IOTP BASELINE TRANSACTIONS

Describes how to do existing baseline transactions by reference to
exchanges. Existing IOTP transaction types would be defined be under a
domain (e.g. the Baseline domain, e.g Baseline:Purchase). 

Also possible for organisations to declare new "fixed" transaction types
by registering domain and name with IANA. Examples of names would be:
1)	BizToBiz:Purchase - variation of purchase invented by "Biz to Biz"
group
2)	UsedMicro:Auction - an auction transaction invented by a particular
company.

Each declared Transaction type would have an implied sequence for
carrying out each step.

Refers to other specs, e.g. IOTP Messaging and relevant "Exchange"
specs.

Contents:
1)	Introduction
2)	Baseline Authentication (8.1)
3)	Baseline Deposit (8.2)
4)	Baseline Purchase (8.3
5)	Baseline Refund (8.4)
6)	Baseline Withdrawal (8.5)
7)	Baseline Value Exchange (8.6)

Each Transaction would have a DTD which defines how other elements in
other DTDs are re-used.

Sample messages would be provided.

IOTP DYNAMIC TRANSACTIONS

New document which describes how to do dynamic transactions. Dynamic
transactions allow trading exchanges to be grouped together as required
to do a particular trade. For example a purchase with two payments, e.g.
a credit card followed by loyalty points.

IOTP PAYMENT SUPPLEMENTS

Essentially these would be the current documents, e.g. the SET
supplement

IOTP TRANSPORT SUPPLEMENTS

Essentially the current documents e.g. HTTP supplement

>Mondex International Limited
mailto:<[email-masked]>
>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]'" <[email-masked]>
Subject: RE: Version 1.0 changes from Hitachi IOTP meeting 9-11 November, Tokyo 
Date: Wed, 18 Nov 1998 06:31:56 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

... in fact Mondex e-cash can make good use of this feature too ...
which proves the point.

Regards

David

>----------
>From: 	Donald E. Eastlake 3rd[SMTP:[email-masked]]
>Sent: 	17 November 1998 12:32
>To: 	David Birch
>Cc: 	David Burdett; [email-masked]'
>Subject: 	Re: Version 1.0 changes from Hitachi IOTP meeting 9-11 November,
>Tokyo 
>
>
>IOTP is not dependent on SET but SET is an interesting test case for a
>payment system to be carried within IOTP.  Whatever you think of SET,
>other payment systems might have similar requirements.  And some IOTP
>implementors specifically plan to include SET among the payment sytems
>they are going to be using with IOTP which is why we have a specific
>subgroup looking into that.
>
>I think the right way to look at this is that some uses of IOTP will
>need to send multiple items where there is currently a provision for a
>single Packaged Content.  People designing those uses can, of course,
>figure out their own way to include multiple items within a Packaged
>Content.  And if they need to include dozens or hundreds of items,
>they probably should figure out some technique that is suitable to the
>data they are packaging.  But it seeme likely that it will be common
>enough for their to be a few separate items to be packaged that a
>standard technique will save people the trouble of re-inventing
>combined packaging ever time such a requirement appears.  The fact
>that the first couple of times the requirement has come up were with
>regard to SET does not mean it won't come up elsewhere.
>
>Thanks,
>Donald
>
>From:  Dave Birch <[email-masked]>
>Date:  Tue, 17 Nov 1998 19:12:48 +0000
>To:  David Burdett <[email-masked]>,
>            "[email-masked]'" <[email-masked]>
>Message-ID:  <[email-masked]>
>
>>David Burdett said
>>
>>>1)	Packaged Content. There is a need for Packaged Content to contain
>>>multiple items of data e.g. in the Pay Receipt Component, to support
>>>encapsulation of SET messages. To support this propose the following
>>>amendment to the Packaged Content element (see section 3.7.1):
>>
>>Wouldn't it greatly simplify IOTP and speed the time to market if we got 
>>rid of SET altogether? See for example
>>
>>http://www.americanbanker.com/cgi-bin/print_tagstory?981117DIGI002
>>
>>Regards,
>>Dave Birch.
>>
>>=== mailto:[email-masked] ===== http://www.hyperion.co.uk/ ===
>
-----------------------------------------------------------------------
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: Dave Birch <[email-masked]>
cc: David Burdett <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: Re: Version 1.0 changes from Hitachi IOTP meeting 9-11 November, Tokyo 
Date: Tue, 17 Nov 1998 15:32:59 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

IOTP is not dependent on SET but SET is an interesting test case for a
payment system to be carried within IOTP.  Whatever you think of SET,
other payment systems might have similar requirements.  And some IOTP
implementors specifically plan to include SET among the payment sytems
they are going to be using with IOTP which is why we have a specific
subgroup looking into that.

I think the right way to look at this is that some uses of IOTP will
need to send multiple items where there is currently a provision for a
single Packaged Content.  People designing those uses can, of course,
figure out their own way to include multiple items within a Packaged
Content.  And if they need to include dozens or hundreds of items,
they probably should figure out some technique that is suitable to the
data they are packaging.  But it seeme likely that it will be common
enough for their to be a few separate items to be packaged that a
standard technique will save people the trouble of re-inventing
combined packaging ever time such a requirement appears.  The fact
that the first couple of times the requirement has come up were with
regard to SET does not mean it won't come up elsewhere.

Thanks,
Donald

From:  Dave Birch <[email-masked]>
Date:  Tue, 17 Nov 1998 19:12:48 +0000
To:  David Burdett <[email-masked]>,
            "[email-masked]'" <[email-masked]>
Message-ID:  <[email-masked]>

>David Burdett said
>
>>1)	Packaged Content. There is a need for Packaged Content to contain
>>multiple items of data e.g. in the Pay Receipt Component, to support
>>encapsulation of SET messages. To support this propose the following
>>amendment to the Packaged Content element (see section 3.7.1):
>
>Wouldn't it greatly simplify IOTP and speed the time to market if we got 
>rid of SET altogether? See for example
>
>http://www.americanbanker.com/cgi-bin/print_tagstory?981117DIGI002
>
>Regards,
>Dave Birch.
>
>=== mailto:[email-masked] ===== http://www.hyperion.co.uk/ ===
-----------------------------------------------------------------------
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: Version 1.0 changes from Hitachi IOTP meeting 9-11 November, Tokyo
Date: Tue, 17 Nov 1998 19:12:48 +0000
From: Dave Birch <[email-masked]>
To: David Burdett <[email-masked]>,  "[email-masked]'" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David Burdett said

>1)	Packaged Content. There is a need for Packaged Content to contain
>multiple items of data e.g. in the Pay Receipt Component, to support
>encapsulation of SET messages. To support this propose the following
>amendment to the Packaged Content element (see section 3.7.1):

Wouldn't it greatly simplify IOTP and speed the time to market if we got 
rid of SET altogether? See for example

http://www.americanbanker.com/cgi-bin/print_tagstory?981117DIGI002

Regards,
Dave Birch.

=== mailto:[email-masked] ===== http://www.hyperion.co.uk/ ===

-----------------------------------------------------------------------
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]'" <[email-masked]>
Subject: Version 1.0 changes from Hitachi IOTP meeting 9-11 November, Tokyo
Date: Tue, 17 Nov 1998 01:34:46 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The following is a list of the changes identified during the IOTP
meeting held at Hitachi premises in Tokyo on 9-11 November.

1)	Packaged Content. There is a need for Packaged Content to contain
multiple items of data e.g. in the Pay Receipt Component, to support
encapsulation of SET messages. To support this propose the following
amendment to the Packaged Content element (see section 3.7.1):
a)	allow multiple occurrences of PackagedContent wherever it occurs.
This makes it a general solution
b)	add an optional Name attribute to the definition of packaged content
which can be used to identify which PackagedContent is used for which
purpose
c)	also clarify description of the Trading Role Data component (see
section 6.16) to suggest that it can contain payment protocol specific
information as well
d)	this change is backwards compatible with Version 1.0
2)	The definition of the Packaged Content in the Payment Component
suggests that its use is the same as for the Packaged Content in the
Trading Role Data Component. (Raised by 'Yoshiaki Kawatsura'). Suggested
answer Trading Role Data component should be used instead of the
Packaged Content in the Payment Component since it is more general
approach to the problem which allows any two parties to exchange
information. This also means that the Packaged Content element within
the Payment Component should be removed.
3)	Brand ID. SET defines its own rules for identifying Brands with the
structure, "BrandId:Product:PromotionalBrand". Since this naming
convention for Brands already exists, suggest that it is adopted by IOTP
as follows
a)	add "SET" as a valid "BrandIdDomain" for credit cards (see section
6.6.1)
b)	It is also suggested that the SCCD protocol adopts SET conventions
for identifying brands
4)	Change definition of Brand ID domain to conform to IETF/IANA
conventions. The current convention for identifying Brand Id Domains
(see section 6.6.1) does not conform to IETF/IANA conventions. Suggest
that its definition is changed to comply. Also applies to other names in
IOTP
5)	Registration procedure for new names. Procedures need to be defined
for the registration of new names, for example Brand Id domain. ACTION:
Don Eastlake.
6)	Text version diagrams. The start and end of diagrams in the ASCII
text versions of the specification are hard to identify. Recommend that
it is made clearer. For example start each diagram with a line of "dash"
characters and end it with a line of "equals" characters.
7)	Correction. CancelNetLocn attribute definition needs to added to the
XML definition given in section 6.5.2.
8)	Digital Signatures. The section on Digital Signatures (section 5)
needs to be updated to reflect how OTP should use the XML signatures as
defined in Richard Brown's proposal. ACTION: Don Eastlake
9)	Net Locations. Change net locations in Protocol Options or Trading
Role Elements to reflect:
a)	SuccessNetLocn - per transaction - Where the Consumer goes if the
transaction is successful
b)	CancelNetLocn - per trading role - where the Consumer goes if the
Consumer cancels the transaction at some point
c)	xxxRequestLocn - where xxx is payment, delivery, etc the location to
which incoming messages with either no errors or technical errors of any
Severity are sent. This means that anybody who sends a message with
errors in it receives a message that indicates there was an error
d)	ErrorLogNetLocn - per trading role, optional -  where the Consumer
sends IOTP messages if they receive an incoming message in which they
detect a technical error with Severity of HardError or TransientError.
Could be used to send error messages to the software company or some
other organisation responsible for fixing problems in the software which
sent the incoming message.
e)	ErrorNetLocn - per trading role - where the consumer goes after
receiving or generating an Error Block with severity of HardError or
TransientError
f)	Also need to provide guidelines which indicate how the consumer
determines which redirect location to use based on where they are I the
location.
10)	Unknown Error. Add an additional error code  (see section 6.19.2)
called UnknownError to indicate that the transaction cannot complete for
some reason. This could be used to indicate an internal error of some
kind. The ErrorDesc attribute should be used to indicate the nature of
the problem.
11)	Authentication Transaction. 
a)	Standalone Authentication. Add an Auth Status message from the
authenticator to the authenticatee to indicate that success or failure
of the authenticator's validation of the Authentication Response
message.
b)	Pre authentication. Allow purchase, refund, withdrawal, deposit and
value exchange IOTP transactions to be preceded by an optional pre
authentication sequence which does an authentication request and
response and then segue's into the real transaction with a new TPO. A
failed authentication will result in an Auth Status as in the Standalone
Authentication
12)	Authentication Method and Authentication Response. In the
Authentication Data Component (section 6.2). Needs to be revised.
ACTION: Richard Brown to provide input.

>Mondex International Limited
mailto:<[email-masked]>
>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: Donald Eastlake <[email-masked]>
To: [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Subject: Tokyo Meeting SET/IOTP Agenda and Technical Issues
Date: Mon, 16 Nov 1998 15:15:39 -0500
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--Boundary=_0.0_=5010400028980947
Content-Type: text/plain

Attached are the Agenda are Technical Issues documents from Yoshiaki Kawatsura
of Hitachi going into the SET payment subgroup meeting at the Trade working
group meeting in Tokyo.  Technical results of that meeting will be posted
separately for mailing list review.

Donald E. Eastlake, 3rd
318 Acton Street, Carlisle, MA 01741 USA
Internet: [email-masked]
Notes: Donald Eastlake/Hawthorne/IBM@IBMUS
1-978-287-4877, fax 1-978-371-7148

--Boundary=_0.0_=5010400028980947
Content-Type: application/octet-stream; name=SETOTP_t.doc
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAANQAAAAAAAAAA
EAAANwAAAAEAAAD+////AAAAADQAAAB/AAAA////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

--Boundary=_0.0_=5010400028980947
Content-Type: application/octet-stream; name=TokyoAge.ppt
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJwAAAAAAAAAA
EAAAKgAAAAEAAAD+////AAAAACgAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

--Boundary=_0.0_=5010400028980947--
-----------------------------------------------------------------------
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: TRADE WG meeting in Orlando
Date: Fri, 13 Nov 1998 16:22:08 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I have requested a slot for a Working Group meeting at the upcoming
Orlando IETF meeting.  I'll pass on any information as I get it.
Right now it tentatively appears that the meeting will be sometime
Wednesday, December 9th.

Thanks,
Donald
=====================================================================
 Donald E. Eastlake 3rd   +1 978-287-4877    [email-masked]
 318 Acton Street         +1 978-371-7148(fax)       [email-masked]
 Carlisle, MA 01741 USA   +1 914 784 7913
-----------------------------------------------------------------------
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-iotp-http-00.txt
Date: Tue, 10 Nov 1998 11:37:37 -0500
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		: Internet Open Trading Protocol (IOTP) HTTP Supplement
	Author(s)	: D. Eastlake, C. Smith
	Filename	: draft-ietf-trade-iotp-http-00.txt
	Pages		: 7
	Date		: 09-Nov-98
	
   Internet Open Trading Protocol (IOTP) messages will be carried as XML
   documents. As such, the goal of mapping to the transport layer is to
   ensure that the underlying XML documents are carried successfully
   between the various parties.
 
   This documents describes that mapping for the Hyper Text Transport
   Protocol (HTTP), Versions 1.0 and 1.1.

Internet-Drafts are 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-iotp-http-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-trade-iotp-http-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-trade-iotp-http-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-iotp-http-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-trade-iotp-http-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: [email-masked]
Subject: draft-ietf-trade-iotp-http-00.txt
Date: Mon, 09 Nov 1998 11:31:15 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The draft mentioned in the subject line is available at
<ftp://ftp.pothole.com/pub/ietf-trade/draft-ietf-trade-iotp-http-00.txt>.
Since it is planned to be discussed at the meeting here in Tokyo, it
is also likely to be revised soon.

Thanks,
Donald

=====================================================================
 Donald E. Eastlake 3rd   +1 978-287-4877    [email-masked]
 318 Acton Street         +1 978-371-7148(fax)       [email-masked]
 Carlisle, MA 01741 USA   +1 914 784 7913
-----------------------------------------------------------------------
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]'" <[email-masked]>,  'Yoshiaki KAWATSURA' <[email-masked]>
Subject: RE: IOTP V1.0 and Signature docs
Date: Sun, 8 Nov 1998 09:43:12 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

You make a good point. The defintion of the Packaged Content in the
Payment Component suggests that its use is the same as for the Packaged
Content in the Trading Role Data Component.

I think that the Trading Role Data component should be used instead of
the Packaged Content in the Payment Component since it is more general
approach to the problem which allows any two parties to exchange
information. This also means that the Packaged Content element within
the Payment Component should be removed.

I also agree that CancelNetLocn attribute definition needs to added to
the XML defintion given in section 6.5.2.

David
PS Apologies for delay in my response, it was an oversight.

>----------
>From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
>Sent: 	28 October 1998 00:21
>To: 	[email-masked]
>Cc: 	[email-masked]
>Subject: 	Re: IOTP V1.0 and Signature docs
>
>  I have a question on IOTP Version 1.0.
>
>  Q:What's differences between the Packaged Content in Payment Component
>  and the TradingRoleData Component when they are used to pass the data
>  , which are required by the Payment Handler from the Merchant to the
>  Payment Handler via the Consumer?
>
>  In IOTP Version 0.99, the Packaged Content in Payment Component is used to
>  pass the data from the Merchant to the Payment Handler via the Consumer.
>  In IOTP Version 1.0, the above behavior can be implemented by 
>  TradingRoleData as well.
>  What should we explain the difference between the two components?
> 
>  The description of PackagedContent in Payment Component(6.8 in IOTP 1.0):
>  "The optional element contains "user" data defined by the Merchant
>  which is required by the Payment Handler."
>   
>  The description of TradingRoleData(See 7.9 Payment Response Block in 
>  IOTP 1.0 ):
>  "The Trading Roke Data Component Contains opaque data which is 
>  need to be communicated between the Trading Roles involved in an OTP 
>  Transaction."
>
> --
>  Additionally,that might be the detail point, there is no description 
>  on the xml data of ErrorNetLocn in the Trading Role Element(see 
>  6.5.2 in IOTP 1.0).
>  
>----
>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]
>
-----------------------------------------------------------------------
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-xml-sig-00.txt
Date: Thu, 05 Nov 1998 10:18:28 -0500
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		: Digital Signatures for XML
	Author(s)	: R. Brown
	Filename	: draft-ietf-trade-xml-sig-00.txt
	Pages		: 35
	Date		: 04-Nov-98
	
   A syntax and procedures for the computation and verification of XML
   digital signatures is specified.

Internet-Drafts are 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-xml-sig-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-trade-xml-sig-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-trade-xml-sig-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-xml-sig-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-trade-xml-sig-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: [email-masked]
Subject: XML SIG draft, SET OTP comments
Date: Wed, 04 Nov 1998 08:23:34 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The latest version of Richard Brown's XML SIG draft formatted as an
Internet Draft is at
<ftp://ftp.pothole.com/pub/ietf-trade/draft-ietf-trade-xml-sig-00.txt>
and should appear in the Intenet Draft directories in a few days.

I posted a brief message about IOTP protocol draft and the ITOP SET
Supplement draft on a couple of SET lists to see if the SET community
had any comments on them.

Thanks,
Donald
=====================================================================
 Donald E. Eastlake 3rd   +1 978-287-4877    [email-masked]
 318 Acton Street         +1 978-371-7148(fax)       [email-masked]
 Carlisle, MA 01741 USA   +1 914 784 7913
-----------------------------------------------------------------------
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]
Subject: IOTP v1.0 DTD and Architechture available
Date: Mon, 02 Nov 1998 01:23:38 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The DTD for v1.0 of the IOTP protocol as documented in
draft-ietf-trade-iotp-v1.0-protocol-02.txt is now available as a text
file from <ftp://ftp.pothole.com/pub/ietf-trade/Otp~~v~1-0.dtd.txt>.

The IOTP Architecture and Payment API Supplement is available as a
zipped MSWord document at
<ftp://ftp.pothole.com/pub/ietf-trade/otparc98.zip>.

Thanks,
Donald

=====================================================================
 Donald E. Eastlake 3rd   +1 978-287-4877    [email-masked]
 318 Acton Street         +1 978-371-7148(fax)       [email-masked]
 Carlisle, MA 01741 USA   +1 914 784 7913
-----------------------------------------------------------------------
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, 02 Nov 1998 14:27:04 +0900
To: David Burdett <[email-masked]>
From: Masaaki Hiroya <[email-masked]>
Subject: RE: Questions about Withdrawal and Deposit Transaction on IOTP
Cc: 'IETF Trade' <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,

Please see my comments below.

At 19:41 98/10/28 -0000, David Burdett wrote:
> In Otp v 1.0 there is no "offer request" message. If there were an Offer
> Request, then the consumer could say "I want to deposit $400 USD of
> Mondex value and the Mondex payment protocols I support are, version 1.0
> and 1.1" in a way which could be understood by the Merchant role. In
> this case, there would be no need for a brand or protocol selection to
> occur.
>
> The merchant (typically) a bank, could then respond with a combined TPO
> and Offer Response which offered to accept payment of the Mondex value
> using one of the payment protocols which the consumer role supports.
> 
> Would this meet your requirement?

Well, I think it might meet our requirement.

By the way, is the Offer Request message the first OTP message in this case?
If so, how is the OTP client waken up?

If the client sends the Offer Request message before receiving TPO message,
how does the client know where to send the Offer Request message?
(since TpoBlk has the SenderNetLocn)

Therefore, if we are going to use the Offer Request message, I think the
Offer Request message will be sent after receiving the TPO message
as follows:
           C         M        P
TPO         <-------
OfferReq    ------->
OfferResp   <-------
PayReq      ----------------->
  :                :
  :                :

What do you think?

Masaaki

> >----------
> >From: 	Masaaki Hiroyo
> >Sent: 	07 October 1998 23:04
> >To: 	David Burdett
> >Cc: 	'IETF Trade'
> >Subject: 	RE: Questions about Withdrawal and Deposit Transaction on IOTP
> >
> >
> >David,
> >
> >Re. Question 1
> >
> >At 01:31 98/10/08 +0100, David Burdett wrote:
> >> >>>There is an assumption that, when you are making a deposit, you 
> >> know what type of electronic cash you want to deposit. It doesn't 
> >> quite make sense to go to a bank web site and then to be asked which 
> >> Brand do you want to deposit. For example a Financial Institution 
> >> wouldn't ask "Do you want to deposit your electronic cash as Mondex, 
> >> as Visa Cash or as GeldKarte?".
> >
> >If a Financial Institution supports multiple brands of electronic
> >cash such as Mondex and VISA cash, I don't think it is strange to
> >ask which brand of electronic cash you want to deposit or withdraw.
> >
> >If it is necessary for a consumer to select a brand to deposit or
> >withdraw, I think that the tpo message and the tpo selection message 
> >should be used for brand selection in order to make the deposit and
> >withdrawal consistent with the purchase.
> >
> >Additionally, it may be an implementation issue, but if only one
> >brand is included in a brand list component, an OTP client software
> >can omit asking brand selection to the consumer.
> >
> >However, in order to finalize OTP spec V1.0 shortly, I think we can
> >discuss this issue in OTP V2.0.
> >
> >
> >Re. Question 2
> >
> >> In baseline it is assumed that the Authentication Method is known 
> >> since there is authentication method selection is not supported.
> >> *	include authentication method selection as a possible enhancement 
> >> for version 2.0
> >
> >I agree with adding authentication method selection in ver 2.0.
> >
> >I thought that if the TpoBlk and AuthReqBlk could be sent separately,
> >we could select authentication method depending on the selected brand.
> >(Tpo message -> TpoSelection message -> AuthReq Message -> AuthResp
> > message -> OfferResp message -> ...)
> >
> >But if authentication method selection is added to OTP as you mentioned,
> >I think that would be better.
> >
> >
> >Masaaki
> >
> >
> >
> >At 01:31 98/10/08 +0100, David Burdett wrote:
> >> Masaaki
> >> 
> >> See comments below.
> >> 
> >> David
> >> 
> >> ----------
> >> From: 	Masaaki Hiroyo
> >> Sent: 	07 October 1998 10:46
> >> To: 	David Burdett
> >> Subject: 	Questions about Withdrawal and Deposit Transaction on IOTP
> >> 
> >> 
> >> David,
> >> 
> >> I have two basic questions about baseline withdrawal and baseline 
> >> deposit.
> >> 
> >> 
> >> Question1
> >> 
> >> According to the IOTP specification (Figs 20 & 21), in baseline 
> >> deposit
> >> a brand to be used is selected on HTML page but not TPO selection 
> >> message.
> >> 
> >> I think it is inconsistent with baseline withdrawal and baseline 
> >> purchase
> >> because both of them use TPO selection message for brand selection but 
> >> baseline deposit doesn't.
> >> 
> >> Is there any reason why tpo selection is not used in baseline 
> >> deposit?
> >> >>>There is an assumption that, when you are making a deposit, you 
> >> know what type of electronic cash you want to deposit. It doesn't 
> >> quite make sense to go to a bank web site and then to be asked which 
> >> Brand do you want to deposit. For example a Financial Institution 
> >> wouldn't ask "Do you want to deposit your electronic cash as Mondex, 
> >> as Visa Cash or as GeldKarte?".
> >> 
> >> However the TPO selection message is used to select the *payment 
> >> protocol* to use since you may have several different ways of 
> >> depositing Visa Cash for example. So the TPO Selection is used for 
> >> this purpose only. If you read step 3 in figures 20 and 21 it says 
> >> this. So what I suggest is that:
> >> *	we add clarification to section 7.2.2 on the fact only the payment 
> >> protocol is selected, and
> >> *	we also need to remove payment method selection from Deposit with 
> >> Authentication (see the answer to the next question for the reasons 
> >> why).
> >> <<<
> >> 
> >> 
> >> Question 2
> >> 
> >> In baseline withdrawal, TpoBlk and AuthReqBlk are sent in the first 
> >> message.
> >> 
> >> If authentication methods depends on payment brand (payment 
> >> instrument),
> >> we cannot send TpoBlk and AuthReqBlk cannot send at the same time.
> >> 
> >> I think brand independent authentication and brand depend 
> >> authentication
> >> are necessary just like brand independent purchase and brand 
> >> dependent
> >> purchase.
> >> 
> >> What do you think about it?
> >> >>> I agree that authentication may depend upon payment brand. However 
> >> it is also possible that authentication is done using a method which 
> >> is independent of a payment brand using, for example, a pass phrase.
> >> 
> >> The point is that really the approach should be as illustrated in the 
> >> diagram below (view it in a fixed font).
> >> 
> >> CONSUMER			MERCHANT
> >>    ------------------Auth Method
> >>   |                      List
> >>   v
> >> Consumer selects
> >> Auth Method
> >>   |
> >>   v
> >> Auth Method
> >>   Selection---------------
> >>                           |
> >>                           v
> >>                      Merchant generates
> >>                     Auth Request for
> >>                     selected Auth Method
> >>                           |
> >>                           v
> >>                      Authentication
> >>    ---------------------Request
> >>   |
> >>   v
> >> Consumer generates
> >> Auth Response
> >>   |
> >>   v
> >> Authentication
> >> Response
> >>   |
> >>    -----------------------
> >>                           |
> >>                           v
> >>                          Merchant checks
> >>                          Auth. Response
> >> 
> >> 
> >> In baseline it is assumed that the Authentication Method is known 
> >> since there is authentication method selection is not supported.
> >> 
> >> On a withdrawal, it is likely that the Consumer knows which brand of 
> >> electronic cash she wants to withdraw, therefore there the Financial 
> >> Institution (aka the Merchant) will know which method of 
> >> authentication to apply.
> >> 
> >> Therefore suggest that:
> >> *	in Baseline we:
> >> *	change "withdrawal with authentication" to work like a deposit in 
> >> that the brand of electronic cash being withdrawn and the payment (and 
> >> hence authentication method) protocol is known in advance
> >> *	leave "withdrawal without authentication" unchanged
> >> *	include authentication method selection as a possible enhancement 
> >> for version 2.0
> >> 
> >> <<<
> >> Masaaki
> >> 
> >> -----
> >> Masaaki Hiroya
> >> Systems Development Laboratory
> >> Hitachi, Ltd.
> >> email: [email-masked]
> >> tel: +81-44-966-9111
> >> fax: +81-44-966-1796
> >> 
> >> 
> >> 
> >> 
> >> *??$B%&(J,$B%&(J,$Bs%9(J"Y*t?t?@?C???F"c:\program files\eudora\attach\RE Questions
> > about Withdrawal "
> >> 
> >-----
> >Masaaki Hiroya
> >Systems Development Laboratory
> >Hitachi, Ltd.
> >email: [email-masked]
> >tel: +81-44-966-9111
> >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]
> >
> -----------------------------------------------------------------------
> 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
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]