Subject: Dates for Tokyo meeting
From: "Donald E. Eastlake 3rd" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 29 Sep 1998 23:26:18 -0400

I have received one message indicating that moving the dates of the
scheduled Tokyo meeting one day earlier, from 10-12 Nov. to 9-11 Nov.,
could cause difficulties for some people.  Is that the case?

For the further information of those who happen to be in the US, I
talked to a travel agent today who indicated that inexpensive
excursion fares sometimes depend on including a Saturday night in your
trip and sometimes do not.  And where the fare basis does require
this, the requirement is not that you actually stay over a Saturday
night at your destination but merely that midnight Saturday night
fall between your departure time and your return arrival time. For
example, you could be airborne at midnight Saturday night and it
would still count.

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: Proposal of SET Specific Receipt
Date: Tue, 29 Sep 1998 23:14:23 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I am posting the following at the request of Yoshiaki Kawatsura.

--
Proposal of SET Specific Receipt 

Purpose of Payment Scheme Specific Receipt:
To prove that a payment has occurred independent the transaction. The
connection between the trade and the payment should be managed in the
PayReceipt Component.
 
The technical issue:
The SET Messages are too large (these messages are larger than OTP
messages).  So, it is undesirable to duplicate embed the SET PReq and
PRes messages in for the SET specific receipt in
PayReceiptPackagedContent.

Assumptions:
This proposal assumes the following point.
1. ConsumerPayId is unique in the Consumer System.
2. PaymentHandlerPayId is unique in the Payment Handler System.
3. ConsumerPayId, PaymentHandlerPayId, PReq and PRes are stored in the SET 
   Bridge.

Requirement of the SET Specific Receipt:
1. Can retrieve PReq and PRes from SET Bridge transparently.
2. Can link the SET Specific Receipt to the SET Messages (e.g. PReq, PRes).

The Message Format:
The message format of PayReceiptPackagedContent is as follows,

PayReceiptPackagedContent:
 Field                 Description                 Status
---------------------------------------------------------
ContentData            See Below                 Mandatory

Content                Fixed XML                 Mandatory

Transform              Fixed None                Mandatory
---------------------------------------------------------

ContentData:
 Field                 Description                 Status
---------------------------------------------------------
PreqPackagedContent   PackagedContent which      Mandatory
                      contains the hash of SET 
                      PReq Message.

PresPackagedContent   PackagedContent which      Mandatory
                      contains the hash of SET 
                      PRes Message.
---------------------------------------------------------

PReqPackagedContent:
 Field                 Description                 Status
---------------------------------------------------------
ContentData           Digest Data of PReq        Mandatory
                      using SHA1

Content               Fixed PCDATA               Mandatory

Transform             Fixed Base64               Mandatory
---------------------------------------------------------

PResPackagedContent:
 Field                 Description                 Status
---------------------------------------------------------
ContentData           Digest Data of PRes        Mandatory
                      using SHA1

Content               Fixed PCDATA               Mandatory

Transform             Fixed Base64               Mandatory
---------------------------------------------------------

The CunsumerPayId and the PaymentHandlerPayId are used as sorting keys
in order to locate the stored SET Messages in the SET Bridge.  (This
can be used to satisfy requirement no. 1.)  In the OTP Architecture
spec. in section 10.5.1 the CheckPaymentReceipt is defined to include
the ConsumerPayId and the PaymentHandlerPayId.  This message can be
sent to the Payment Bridge to generate, display, check, etc. the SET
specific receipt.

The hash (Digest Data) is used to link in a verifiable and signed way
to the PayReceiptPackagedContent and the SET messages (this satisfies
the requirement No.2.)

Examples of use:

1.  CheckPayReceipt API:
When the CheckPayReceipt API is used, the OAC passes the
PayReceiptPackagedContent, PaymentHandlerPayId and ConsumerPayId to
the SET Bridge. The SET Bridge retrieves the PReq and PRes using the
two Ids as keys, creates a hash of PReq and PRes, and then compares it
to the hashes contained in the PayReceiptPachagedContent.

2.  Customer Care Service:
The Consumer's OAC sends the StartPaymentInstrumentCustomerCare
message to the SET Bridge. The SET Bridge generates
PaySchemePackagedData which includeds PReq,PRes,PayReceipt, etc. and
returns it to the OAC.  The Consumer's OAC then sends it to Customer
Care Service.
-----------------------------------------------------------------------
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-v1.0-protocol-01.txt
Date: Tue, 29 Sep 1998 10:15:22 -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		: Internet Open Trading Protocol - IOTP Version 1.0
	Author(s)	: D. Eastlake
	Filename	: draft-ietf-trade-iotp-v1.0-protocol-01.txt
	Pages		: 4
	Date		: 28-Sep-98
	
   The Internet Open Trading Protocol (IOTP) provides an interoperable
   framework for Internet commerce.  It is payment system independent
   and can encapsulates a variety of payment systems. IOTP is able to
   handle cases where such merchant roles as the shopping site, the
   payment handler, the delivery handler of goods or services, and the
   provider of customer care are performed by different parties or by
   one party.
 
   [This draft is a place holder for an internet-draft version of the
   v1.0 starting point for the trade working group.]

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-v1.0-protocol-01.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-protocol-01.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-iotp-v1.0-protocol-01.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-v1.0-protocol-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-trade-iotp-v1.0-protocol-01.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]
cc: [email-masked]
Subject: CALL FOR ATTENDANCE: November WG Meeting in Tokyo
Date: Mon, 28 Sep 1998 15:07:20 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Please respond if you plan to attend:

MEETING

A meeting of the IETF TRADE working group was scheduled for 10-12
November in Tokyo, Japan, hosted by Hitachi.  At the last WG meeting
in Reston, Virginia, it was decided to proceed with the Tokyo meeting
but only if, by October 10th or thereabouts, at least 15 people were
willing to give reasonably firm commitments to attend.  In addition,
the host has asked to move the meeting one day earlier, to 9-11
November, which I hope will not be a problem for anyone.

AGENDA

I anticipate that the V1.0 spec. will be out by then and the biggest
single item on the agenda will be what should be considered for
version 2.0.  You should also expect the first day, the 9th, to be
primarily devoted to subgroup meetings on tunneling specific payment
systems through IOTP. Additional topics will be various supplemental
documents to the IOTP protocol specification and any further
implementation or interoperability experience.

LOGISTICS

The meeting will be at a Hitachi facility.  Air fares obviously depend
on where you are coming from, etc., but a spot check of fares from
Dulles Airport, outside Washington, DC, on one airline indicated that
November is in the low season and that inexpensive round trip
excursion fares could be obtained by reserving a week or more in
advance and staying in Japan a few extra days.

The following may give you an idea of hotel rates (info provided by
Hitachi):

 Suidobashi Grand Hotel

 The Hitachi corporate rate is available here for 7,000yen ($52).  This hotel
 is one station away from where we will be meeting.  I have also been told
 that it is a "business hotel" which basically means it is a cheap hotel
 along the lines of Motel 8 or something.

 Jyuraku Hotel

 This hotel is supposed to be a bit nicer, and is right next to the meeting
 spot.  However, we cannot get a corporate discount here.  The room charge is
 9,000yen ($67).

More Logistics details will be available later.

PLEASE CONTACT ME IF YOU ARE REASONABLY CERTAIN YOU WILL ATTEND.

Thnaks,
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: Re: IMPORTANT RE: I-D ACTION:draft-ietf-trade-iotp-v1.0-protocol-00.txt 
Date: Mon, 28 Sep 1998 02:25:48 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I hope that everyone will accept my apologies for not properly
managing the submission of this draft.

All future drafts are to be channeled through me as working group
chair and no future "draft-ietf-trade..." draft are to be posted to
the internet-drafts directories without my approval.

To avoid possibilities of confusion, I have appended below a place
holder version -01 of this draft which I will submit to be posted
in the Internet-Draft directories.

Thanks,
Donald

From:  David Burdett <[email-masked]>
Message-Id:  <c=GB%a=_%p=Mondex_Internati%l=[email-masked]
ex.com>
To:  "[email-masked]'" <[email-masked]>
Cc:  "[email-masked]'" <[email-masked]>
Date:  Sun, 27 Sep 1998 20:08:35 +0100
X-elistx:  ietf-trade

>Please note that the draft referred to by this E-mail was submitted by
>Surendra Reddy and not me.
>
>Although it names me as author as well as Surendra. I want to state that
>at no time prior to its submission to the IETF was this document made
>available to me for review.
>
>Upon downloading and examining Surendra's document I find it lacking.
>
>Specifically only one diagram from the PDF version available from the
>OTP web site (http://www.otp.org) has been included. In addition
>sections from the original document have been omitted without
>explanation.
>
>In my view this makes the document:
>*	unsuitable for review and discussion by the Trade WG as well as
>*	unsuitable for the building of OTP solutions
>
>It is *not* version 1.0 of IOTP.
>
>I want to disassociate myself from this particular version since I have
>not been involved in its production and it was submitted without my
>permission even though I am named as author.
>
>I am meeting with Surendra next Wednesday (30th November) and will work
>with him to identify how Surendra, in his role of Trade WG Editor, and I
>can work effectively together in the production of future versions of
>the specification. I will report back on this meeting with an e-mail to
>the WG.
>
>Finally, as described in the IETF charter, there *will* shortly be a
>*real* version 1.0 including changes arising from the RBC version from
>OTP as well as the changes described in the "Changes 2" file I recently
>submitted to the mailing list. I have also asked the chair of the Trade
>>WG,  Don Eastlake, to remove the version located at
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-protocol-00.txt
>as I think its presence only causes confusion.
>
>Regards
>David Burdett
>Development Director
>>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
>
>
>>----------
>>From: 	[email-masked][SMTP:[email-masked]]
>>Sent: 	23 September 1998 15:42
>>To: 	The recipient's address is unknown.
>>Cc: 	[email-masked]
>>Subject: 	I-D ACTION:draft-ietf-trade-iotp-v1.0-protocol-00.txt
>>
>><<File: ATT00006.txt>><<File:
>>draft-ietf-trade-iotp-v1.0-protocol-00.txt.url>>
>>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
>>	Author(s)	: S. Reddy, D. Burdett
>>	Filename	: draft-ietf-trade-iotp-v1.0-protocol-00.txt
>>	Pages		: 191
>>	Date		: 22-Sep-98
>>	
>>  The  Internet  Open  Trading  Protocol  (IOTP)  provides  an
>>  interoperable framework for Internet commerce. It is payment
>>  system independent and encapsulates payment systems such as SET,
>>  Mondex, CyberCash, DigiCash, GeldKarte, etc. IOTP is able to
>>  handle cases where such merchant roles as the shopping site, the
>>  payment handler, the Delivery Handler of goods or services, and
>>  the provider of customer support are performed by different
>>  parties or by one party.
>>
>>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-v1.0-protocol-00.txt".
>>A URL for the Internet-Draft is:
>>ftp://ftp.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-protocol-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-iotp-v1.0-protocol-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.
>>
>>
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>Mondex International Limited
>47-53 Cannon Street, London  EC4M 5SQ
>England
>Registered No: 3122085, England
>
>Telephone No: +44 (0)171 557 5000
>Web Site: http://www.mondex.com


INTERNET-DRAFT                                                 IOTP v1.0
                                                          September 1998
                                                      Expires March 1999

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

                         Donald E. Eastlake 3rd

                        Status of This Document

   A later version of this draft, file name draft-ietf-trade-iotp-v1.0-
   protocol-01.txt, is intended to become an Informational RFC.
   Distribution of this document is unlimited.  Comments should be sent
   to the TRADE WG mailing list <[email-masked]>.

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months.  Internet-Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

   Technical control over the Internet Open Trading Protocol is being
   transfered to the IETF TRADE working group from the OTP Consortium.
   In some cases, the most current version of techncial documents is an
   OTP Consortium version that has not yet been republished as an RFC
   and is available from <http://www.otp.org> web site (which has not
   yet been fully updates to indicate the technical switch to the IETF).

   In this case, see
   <http://www.otp.org/otp/Home.nsf/f86055a20977be50862564b3004d010a/
   42b496239c5956aa8625655a007b1835/$FILE/OTP_Spec_v_0-9-9_ltr.pdf>.  It
   is intended that that document be published as an later verson of
   this internet-draft and then as an Informational RFC.

D. Eastlake                                                     [Page 1]


INTERNET-DRAFT                 IOTP V1.0                  September 1998

Abstract

   The Internet Open Trading Protocol (IOTP) provides an interoperable
   framework for Internet commerce.  It is payment system independent
   and can encapsulates a variety of payment systems. IOTP is able to
   handle cases where such merchant roles as the shopping site, the
   payment handler, the delivery handler of goods or services, and the
   provider of customer care are performed by different parties or by
   one party.

   [This draft is a place holder for an internet-draft version of the
   v1.0 starting point for the trade working group.]

Table of Contents

      Status of This Document....................................1

      Abstract...................................................2
      Table of Contents..........................................2

      1. Place Holder............................................3
      2. Security Considerations.................................3

      References.................................................4
      Author's Address...........................................4
      Expiration and File Name...................................4

D. Eastlake                                                     [Page 2]


INTERNET-DRAFT                 IOTP V1.0                  September 1998

1. Place Holder

   Technical control over the Internet Open Trading Protocol is being
   transfered to the IETF TRADE working group from the OTP Consortium.
   In some cases, the most current version of technical documents is an
   OTP Consortium version that has not yet been republished as an RFC
   and is available from <http://www.otp.org> web site (which has not
   yet been fully updates to indicate the technical switch to the IETF).

   In this case, see
   <http://www.otp.org/otp/Home.nsf/f86055a20977be50862564b3004d010a/
   42b496239c5956aa8625655a007b1835/$FILE/OTP_Spec_v_0-9-9_ltr.pdf>.  It
   is intended that that document be appropriately reformated / edited
   and published as an later verson of this internet-draft and then as
   an Informational RFC.

2. Security Considerations

   Security of Internet Open Trade Protocol messages is primarily
   dependent on signatures within IOTP as described in [v0.9.9].

   Note that the security of payment protocols transported by IOTP is
   the responsibility of those payment protocols.

D. Eastlake                                                     [Page 3]


INTERNET-DRAFT                 IOTP V1.0                  September 1998

References

   v0.9.9 - David Burdett, "Internet Open Trading Protocol, Version
      0.9.9", OTP Consortium, 17 August 1998.

Author's Address

   Donald E. Eastlake 3rd
   IBM
   318 Acton Street
   Carlisle, MA 01741 USA

   Telephone:   +1 978 287 4877
                +1 914 784-7913
   FAX:         +1 978 371 7148
   email:       [email-masked]

Expiration and File Name

   This draft expires December 1998.

   Its file name is draft-ietf-trade-iotp-v1.0-protocol-01.txt.

D. Eastlake                                                     [Page 4]

-----------------------------------------------------------------------
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: 9 Sept. SET/OTP Design Subgroup Meeting Minutes
Date: Sun, 27 Sep 1998 16:57:52 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

[The first day of the TRADE WG meeting in Reston, a design subgroup
interested in profiling how to transport SET within IOTP met.  The
following minutes of this meeting were provided by Yoshiaki Kawatsura
of Hitachi.  I have lightly edited them and made some minor changes.
Please blame me for any errors. Thanks, Donald]

SET/OTP Design Subgroup Meeting Minutes
09/09 10:30-14:30

Attendees:
Donald Eastlake		IBM -- Chair
Arakawa Noriyasu	NTT
Stephen Howard		CertiCom
May Adams		Defense Information Systems Agency
Yoshiaki Kawatsura	Hitachi
Andrew Drapp		Hitachi

Minutes

Agenda Overview

+ Document Status: 3rd draft of the SET/OTP specification was
	distributed to a few people. At the time it had not been decided
	if the SET/OTP design subgroup would be open or not, so the
	document was not made public.
+ Subgroup Status: It was decided that the SET/OTP design team
	should be open.  As such, major versions of the document will be
	posted to the IETF-trade mailing list.  Minor updates will
	only be distributed to active members working on its
	development.
+ There was a short explanation on what role CommerceNet will have,
	and how it fulfills a different purpose than the IETF TRADE
	(IOTP) working group.

Technical Issues

+ Supported Services:
	1. Suspend/Resume: SET transactions should run to completion, so
	suspend and resume functions should not be necessary. 
	Mentioning suspend/resume in the document could cause more
	problems than it solves, so it was decided that suspend/resume
	should not be mentioned in the document.
	2. Customer Care Service: It as decided that Customer Care
	Service will NOT be covered in the first version of the SET/OTP
	specifications and such should be stated explicitly stated
	in the document.
	3.  Authentication: Should OTP authentication be done on top
	of SET authentication?  SET authentication fulfills a different
	purpose than OTP, so OTP authentication is still necessary.

+ Payment Issues: US credit card law requires that delivery (or
	specifically shipment) occur before the card is billed, how
	does this work with OTP?  There is no method for the Delivery
	Handler to inform the Payment Handler that the order has
	been shipped so the Payment Handler can now capture the funds. 
	This issue was tabled and will be brought up again at a general
	session of the IOTP WG meeting.  It will also be brought up
	on the IETF-trade mailing list.

+ SET Initiation Response Error (See Agenda): If the Error occurs,
	so it (case 1) produces a specific error message that is
	encapsulated and sent to the other transaction party, or
	(case 2) return an empty PaySchemeData component?  Since an
	error is the only case where the PaySchemeData component will be
	empty, this clearly signifies that an error has occurred. 
	Furthermore, since Payment Bridges are vendor specific, and
	it cannot be assumed that both transaction parties are using
	the same vendor and thus payment bridges, it is likely that
	one Payment Bridge will not be able to understand an error
	from the opposite Payment Bridge.  Furthermore, in Case 2,
	the OTP messages being sent are simpler and shorter.  Because of
	all the previous reasons, Case 2 was agreed upon.

+ SET/OTP specific receipt: Should the SET/OTP bridge produce a
	receipt that is specific to SET?  After some discussion, no
	value was seen in having a receipt specific to SET.  (Note:
	later after payment subgroups recombined, another subgroup
	brought up an issue that led to the creation of a SET specific
	receipt. See below.)
	
+ SET Certificate Registration and Inquire could be done in the
	payment scheme customer care message.

+ Authorization Handling: To avoid problems of delivery without
	authorization, it was decided that it will be mandatory for
	SET to process authorizations in real time when selling digital
	goods.

+ Error Severity: Set all SET errors as hard errors in OTP.  There
	are no SET errors that we can think of that would not result
	in needing to restart the transaction anyway, so there is no
	reason not to just set all errors as hard.

+ Security: In addition to the Payment Bridge verifying that the
	amount and brand are consistent between OTP and SET, it was
	agreed that the DD(OD) (Hash of the Order Description) and
	the LID-M (Local ID ? Merchant) should also be checked.

Other Issues

+ In Draft 3 there is a reference to the current version of the main
	OTP specification document as being version 0.9.2.  This should
	be updated to 0.9.9.

+ In section 8.2.1, the error generated when amounts don't match can
	be explicitly stated as an OTP inconsistent element error,
	as defined in the main OTP specification document.

+ One of the long-term goals of the SET/OTP design subgroup is to
	produce on or more RFC(s) to document its recommendations.
	
+ It was decided that no separate mailing list was necessary for the
	SET/OTP subgroup.

+ Goals: After the documents are released at a stable level, we
	should test interoperability of SET/OTP.  It was somewhat
	humorously noted that before we can test SET/OTP
	interoperability, OTP and SET themselves must be
	interoperable.

Payment Subgroups now recombined to discuss issues that arose during
the subgroup meetings.  The following issue was raised:

+ Should SET/OTP give information to OTP in the PayReceipt element
	so that there is proof of payment separate from the purchase? 
	If signatures are not used, in the current specification,
	there is no receipt that can be validated.  If PReq and PRes
	were saved, there would be signed information that could be
	used to prove payment.  One option was to include PRes and
	PReq in the PayReceipt element, but that would greatly increase
	the size of OTP messages, and the data would be redundant. 
	It was finally decided that the PayReceipt could include element
	references to the elements containing PReq and PRes.  If
	signatures are used, hashes of the referenced elements must
	also be used and saved.

[See David Burdett's comments on the above for more specific information.]

=====================================================================
 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]>
Cc: "[email-masked]'" <[email-masked]>
Subject: IMPORTANT RE: I-D ACTION:draft-ietf-trade-iotp-v1.0-protocol-00.txt
Date: Sun, 27 Sep 1998 20:08:35 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Please note that the draft reffered to by this E-mail was submitted by
Surendra Reddy and not me.

Although it names me as author as well as Surendra. I want to state that
at no time prior to its submission to the IETF was this document made
available to me for review.

Upon downloading and examining Surendra's document I find it lacking.

Specifically only one diagram from the PDF version available from the
OTP web site (http://www.otp.org) has been included. In addition
sections from the original document have been omitted without
explanation.

In my view this makes the document:
*	unsuitable for review and discussion by the Trade WG as well as
*	unsuitable for the building of OTP solutions

It is *not* version 1.0 of IOTP.

I want to disassociate myself from this particular version since I have
not been involved in its production and it was submitted without my
permission even though I am named as author.

I am meeting with Surendra next Wednesday (30th November) and will work
with him to identify how Surendra, in his role of Trade WG Editor, and I
can work effectively together in the production of future versions of
the specification. I will report back on this meeting with an e-mail to
the WG.

Finally, as described in the IETF charter, there *will* shortly be a
*real* version 1.0 including changes arising from the RBC version from
OTP as well as the changes described in the "Changes 2" file I recently
submitted to the mailing list. I have also asked the chair of the Trade
>WG,  Don Eastlake, to remove the version located at
ftp://ftp.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-protocol-00.txt
as I think its presence only causes confusion.

Regards
David Burdett
Development Director
>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

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	23 September 1998 15:42
>To: 	The recipient's address is unknown.
>Cc: 	[email-masked]
>Subject: 	I-D ACTION:draft-ietf-trade-iotp-v1.0-protocol-00.txt
>
><<File: ATT00006.txt>><<File:
>draft-ietf-trade-iotp-v1.0-protocol-00.txt.url>>
>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
>	Author(s)	: S. Reddy, D. Burdett
>	Filename	: draft-ietf-trade-iotp-v1.0-protocol-00.txt
>	Pages		: 191
>	Date		: 22-Sep-98
>	
>  The  Internet  Open  Trading  Protocol  (IOTP)  provides  an
>  interoperable framework for Internet commerce. It is payment
>  system independent and encapsulates payment systems such as SET,
>  Mondex, CyberCash, DigiCash, GeldKarte, etc. IOTP is able to
>  handle cases where such merchant roles as the shopping site, the
>  payment handler, the Delivery Handler of goods or services, and
>  the provider of customer support are performed by different
>  parties or by one party.
>
>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-v1.0-protocol-00.txt".
>A URL for the Internet-Draft is:
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-protocol-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-iotp-v1.0-protocol-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.
>
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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-iotp-v1.0-protocol-00.txt
Date: Wed, 23 Sep 1998 10:42:37 -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		: Internet Open Trading Protocol - IOTP
	Author(s)	: S. Reddy, D. Burdett
	Filename	: draft-ietf-trade-iotp-v1.0-protocol-00.txt
	Pages		: 191
	Date		: 22-Sep-98
	
  The  Internet  Open  Trading  Protocol  (IOTP)  provides  an
  interoperable framework for Internet commerce. It is payment
  system independent and encapsulates payment systems such as SET,
  Mondex, CyberCash, DigiCash, GeldKarte, etc. IOTP is able to
  handle cases where such merchant roles as the shopping site, the
  payment handler, the Delivery Handler of goods or services, and
  the provider of customer support are performed by different
  parties or by one party.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-trade-iotp-v1.0-protocol-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]

From: Donald Eastlake <[email-masked]>
To: [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Subject: Minutes of the September 9-11 IETF Trade WG Meeting at Cyber
Date: Fri, 25 Sep 1998 00:10:16 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The detailed technical decisions have already been reported to the list for
consideration by David Burdett in his message which is available at <
http://www.elistx.com/archives/ietf-trade/199809/msg00023.html>.  The material
here together with that message are the main meeting minutes.

Informational Highlights

A set of changes is being advanced for SET 2.0 which include a variety of
enhancements within the area that SET has covered but also include some things
the expand the boundaries of SET and get closer to IOTP such as merchant
authentication early in the shopping sequence.

The OECD is looking into cooperative ways to tax Internet commerce.  (See
separate messages posted on this topic.)

Bill Presentment was a popular topic and there was sentiment for having a bill
presentment section of a future requirements document that would emphasize
sending bills via email and mention the money transfer alternatives for their
payment.

SET in IOTP

The first day we split into an open group discussing SET in IOTP and a much
smaller closed group discussing Mondex in IOTP.  Separate minutes of the SET
IOTP meeting will be posted.

Implementation

The Royal Bank of Canada has implemented IOTP 0.9.  Their draft comments on 0.9
were reviewed in detail although Chris Smith of the Royal Bank was
unfortunately not able to be there.  A final version of these comments should
be posted to the list shortly.

Current Document & Technical Questions

See URL above for pointer to techncial decision detials.

A number of the documents are behind schedule and people need to be prodded to
make commitments for completing documents.  The current architecture document
still needs to be put up on the www.otp.org web site and announced.

Version 2.0 Planning

A major goal of the working group is to develop a Version 2 IOTP for the IETF
standards track.  We reviewed the Version 2 documents called for in the charter
and the possible new items in and out of scope for Version 2.  These lists were
refined with the main change that there was strong sentiment to include some
limited server to server messages so that, for example, the Payment Handler can
notify the Merchant of payment disposition and the Delivery Handler can notify
the Merchant and the Payment Handler of delivery disposition.

Dave Burdett gave a presentation on Dynamic Definition of Trading Sequences.
This would be a major extension and refinement of OTP in version 2.  It would
permit much more general serial/parallel sequences of the various
authentication, offer, payment, delivery, customer care, etc., exchanges.
Basically, the originating OTP server (usually the Merchant) could specify the
blueprint for the work flow of the remainder of the transaction.  In some ways,
this simplifies OTP and makes it substantially more general.

Upcoming Meetings

There was sentiment to proceed with the November 10-12 meeting hosted by
Hitachi in Japan but only if at least 15 reasonably firm attendees sign up by
or around October 10th.  At the Hitachi meeting, it would be decided whether to
continue with these three day meetings but they will probably be continued at
the rate of three a year (down for the 5 or 6 before) and be half way between
the IETF meetings.  This would imply one in early February 1999, perhaps in
Europe.

Attendance:

May Adams, Defense Information Systems Agency
Terry Allen, Veo Systems
Noriyasu Arakwa, NTT
Hans-Bernhard Beykirch, SIZ
Brian Boesch, CyberCash
David Burdett, Mondex
Adrew Dapp, Hitachi
Donald Eastlake, IBM
Masaaki Hiroya, Hitachi
Stephen P. Howard, CertiCom
Yoshiaki Kawatsura, Hitachi
Paul Lampru, Citibank

=================================================================
Donald E. Eastlake, 3rd
318 Acton Street, Carlisle, MA 01741 USA
Internet: [email-masked]
1-978-287-4877, fax 1-978-371-7148
-----------------------------------------------------------------------
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]>,  'Yoshiaki KAWATSURA' <[email-masked]>,  David Burdett <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Spec Changes from IOTP Workshop at CyberCash Reston, 
Date: Thu, 24 Sep 1998 17:39:00 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

> Is that clearer? ... Yes
>
> An interesting problem though which requires more thought. Any ideas
> on the solution?
>
> David
     
  Yes, I think....
  
  First, would this be a more detailed version of what must happen, given 
  that there is more than one Package involved.
  
      |         sends PayExchBlk
  OTP Client(Consumer)
      |         sends PaySchemeData Component (1)
  PH OTP software(OAC)
      |         sends Packaged Data (1)
  Payment Bridge
      |         sends Packaged Data (2-PaySchemeData) and Packaged Data 
  PH OTP software(OAC)
      |         sends PayReceipt Component (2) and PaySchemeData
  OTP Client(Consumer)
      |         sends PayRespBlk
  
  The problem I see is that PayRespBlk includes BOTH PayReceipt and 
  PaySchemeData.
  
  In some payment systems, these are distinct items. In others, they are 
  not. Handling this is the job of the Payment Bridge (yes?). It seems that 
  if both pieces are present, then only the PayReceipt needs to be kept, 
  although the PaySchemeData may need to be used. (Note that in some 
  payment systems, there may not be any PayReceipt. What would a 'bearer 
  note' system provide? What is needed then is the Status only.)
  
  A Bridge may, in some cases, have to make special effort to generate a 
  PayReceipt. For example, in a 'bearer note' system, it might be required 
  to generate a 'bearer note accepted' digital signature over the note. 
  This is what would be placed in the PayReceipt Component.
  
  It seems that, in fact, the PaySchemeData can be dropped, but the 
  PayReceipt cannot be dropped. Is this actually the case? In a SET 
  transaction, is there anything for the recipient of the final 
  PaySchemeData to do with it, other than keep it? If this is the case, 
  then no ElRefs are needed - PayReceipt is always kept (if supplied) and 
  PaySchemeData is used if needed, or dropped if NOT needed. In fact, this 
  is implied by the element PayRespBlk, which in ver 0.9.9 already is:
  
  <!ELEMENT PayRespBlk (Status, PayReceipt, PaySchemeData?)>
  
  There is a small problem with the above diagram - in most cases, the 
  Consumer will NOT be sending the PayRespBlk. That will be the job of the 
  PaymentHandler. However, all of the above notes apply regardless. This 
  problem may be, in part, responsible for some misunderstandings around 
  this problem.
  
  If we add PayNote, then we end up with...
  
  <!ELEMENT PayRespBlk, (Status, PayNote?. PayReceipt, PaySchemeData?)>
  
  where:
  
     Status        - see 5.14, keep, report, may pass to Delivery
     PayNote       - see 5.??, xml:lang dependent, displayable, keep
     PayReceipt    - see 5.10, keep, may check, may pass to CC
     PaySchemeData - see 5.9,  use internally, discard
  
  and
  
     'keep'               == file in persistent storage
     'report'             == indicate this to the user
     'may pass to ...'    == that this may be needed in a future OTP msg
     'xml:lang dependent' == user needs natural language ability
     'displayable'        == can or should be shown to the user as is
     'may check'          == recipient may test this info for correctness
     'use internally'     == continued local processing needs this
     'discard'            == it may be discarded upon transaction end
  
  Does this move the discussion forward?
  
  ...Chris
  
  P.S. As an aside, is the above <!ELEMENT> description in useful format?

     
>Yoshiaki wrote:
>>In current Payment APIs, Payment Bridge receives only the PackagedData 
>>by the OAC, not the Component.The contents of the PayReceipt Component 
>>are written by the Payment Bridge. Therefore an ElRef attribute can 
>>not be used in the payment receipt data because the Payment Bridge 
>>does not know the ID of the Components.
>
>To which David Responded:
>>>> I'm not sure I understand this. Can we discuss in the conference call 
>on
>24th. David<<<
>
>OK, let me see if I can explain this.  The Message flow would look
something 
>like this:
>
>OTP Client(Consumer)
>    |         sends PaySchemeData Component (1) 
>PH OTP software(OAC)
>    |         sends Packaged Data (1) 
>Payment Bridge
>    |         sends Packaged Data  (2) 
>PH OTP software(OAC)
>    |         sends PayReceipt Component (2) 
>OTP Client(Consumer)
>
>The Packaged Data (2) contains the Payment Scheme Specific Receipt 
>, which is created by the Payment Bridge software.  When the
>PH OTP Software(OAC) forwards the packaged content to the Payment Bridge, 
>it does not send any of the OTP message outside of the packaged
>content.  The labeling (ID) of which component is which is in the OTP part 
>of the message.  The Payment Bridge itself never receives this 
>information.  So, when it generates the Pay Receipt, it does not know 
>what components to reference.  Is that clearer?
>
>--
>Andrew Drapp
>[email-masked]
>Hitachi Systems Development Laboratory 
>1099 Ozenji, Asao, Kawasaki, 215-0014 JAPAN 
>TEL:+81-44-966-9111   FAX:+81-44-966-1796
>Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F 
>
>-----Original Message-----
>From:     David Burdett [SMTP:[email-masked]] 
>Sent:     Wednesday, September 23, 1998 4:33 PM
>To:     'Yoshiaki KAWATSURA'
>Cc:     [email-masked]'
>Subject:     RE: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11 
>September 1998
>
>See comments below.
>
>David
>
>>----------
>>From:      Yoshiaki KAWATSURA[SMTP:[email-masked]] 
>>Sent:      17 September 1998 12:37
>>To:      David Burdett
>>Cc:      [email-masked]; [email-masked] 
>>Subject:      Re: Spec Changes from IOTP Workshop at CyberCash Reston,
9-11 
>>September 1998
>>
>>David,
>>My comment is below(included the another issue.) 
>>>>>>> Thu, 17 Sep 1998 10:25:08 +0100,
>>     David Burdett <[email-masked]> said:
>>> 4)     There was discussion about the "PackagedContent" of the Pay
Receipt 
>>> Component. This arose because the sub-group which was considering how
>>> SET can be encapsulated within OTP had decided to leave this content 
>>> "empty" since receipt information was contained in the SET messages 
>>> themselves.
>>>
>>>      Now the definition of the Pay Receipt Component says that it is 
>>> designed to prove, after the payment is complete, that the payment had 
>>> occurred ***independently of the purchase***. An analogy is that it is 
>>> the equivalent of the typically yellow (in the US) slip produced by 
>>> real world credit card terminals which the customer may retain as
>>> evidence of the payment. This slip does not usually contain any
>>> identification of what goods were purchased. If the SET protocol when 
>>> encapsulated within OTP did not retain these messages then it would be 
>>> the equivalent of forcing the Consumer to always "throw away the
>>> credit card slip". However there was reluctance to copy the SET
>>> messages within the Pay Receipt Component since they could be several 
>>> Kb in length.
>>>
>>>      The proposed solution to this problem is to change the Pay Receipt 
>>> Component so that it contains :
>>> a)     the payment receipt data in its PackagedContent, and/or
>>> b)     a new ElRef attribute, that contains references to other
Components 
>>> (potentially including Pay Scheme Components) which together make up
>>> the receipt. Note that:
>>
>>In current Payment APIs, Payment Bridge receives only the PackagedData 
>>by the OAC, not the Component.The contents of the PayReceipt Component 
>>are written by the Payment Bridge. Therefore an ElRef attribute can 
>>not be used in the payment receipt data because the Payment Bridge 
>>does not know the ID of the Components.
>>>> I'm not sure I understand this. Can we discuss in the conference call 
>on
>24th. David<<<
>>
>>--
>>Another Issue:
>>In the TpoBlk, ErrorNetLocn is listed twice, once in the 
>>ProtocolOptions component and once in the Org component.  Should one 
>>of them be deleted?  Since each trading role has its own ErrorNetLocn, 
>>it makes since to leave it in the Org component.  If we delete it from 
>>the ProtocolOptions component, then we should probably move the 
>>CancelNetLocn element to the Org component as well.
>>>>Agreed<<<
>>
>>----
>>Yoshiaki Kawatsura : E-mail [email-masked]
>> Business & Information Systems Development Devision, Hitachi,Ltd. 
>> Voice: +81-45-948-1418(direct) Fax: +81-45-948-1421
>>
>----------------------------------------------------------------------- 
>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]
>
     
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mondex International Limited
47-53 Cannon Street, London  EC4M 5SQ 
England
Registered No: 3122085, England
     
Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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' <[email-masked]>
Subject: Changes 2
Date: Thu, 24 Sep 1998 17:05:54 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

THe attached contains the latest list of changes list with revision marks 
to highlight changes from the first copy including dicussions from todays 
conference call.

I suggest that we allow one further week for changes then on the 2nd of 
October, we freeze the list, since by then we should have feedback from the 
RBC project - I'm reliably informed ;), and then I will work on producing 
the definitive version.

Regards

David
[[ CHANGE~1.DOC : 4152 in WINMAIL.DAT ]]
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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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]'" <[email-masked]>
Subject: RE: FW: Authorization before OTP
Date: Thu, 24 Sep 1998 16:42:00 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Discussions like this make me think that an Authentication Exchange should 
be allowed to become as fully complex as Payment Exchange IN THE SENSE THAT 
there may be multiple round trips, and more than two parties may be 
involved.

In addition, it would allow the (already existing) requirement of 
Customer(PaymentInstrument) authenticated by PaymentHandler, even though 
the Customer must send the first AuthRequest TO the PaymentHandler.

In flow...
                Authentication Exchange
   Customer                                Payment Handler
   -------------------------------------------------------
                   --AuthRequest--> 
                   <-AuthExchange-- (Auth Details; crypto method and
challenge)
 (crypto response) --AuthExchange->   check response
                   <-AuthResponse-- send status

1. Yes, I know it adds round trips. Some of these could travel at the same
   time as parts of the Payment Exchange. Some can't. If you want this
   functionality. it doesn't come for free.

2. This moves us more towards dynamic and generalized Exchange sets. 
   Do we *really* want this in Baseline?

3. Finally, some of the 'ContinueNetLocn' functionality could be handled
   by allowing one party (the Merchant) to send an AuthRequest to the
Consumer
   but require that the AuthResponse be shipped elsewhere (PaymentHandler).
We
   do already offer something like this (if I recall correctly) but not in
this
   more open fashion.

Finally, we are again seeing that Org elements (perhaps even new
organizations) 
may be added to the transaction partway through. For example, I may be
prepared 
to give certain Org details to a DeliveryHandler (or PaymentHandler) that I
do 
not want to send to the other party. As such, I do not want to ship the Org 
components as they appeared on the TPO - I may even want to add details that
the
Merchant was not given.

This is (my opinion) an even more clear-cut reason to allow Org
(organizations) 
to be added to the transaction after the startup. There may be several ways
to 
do this, but we need to decide if we will allow Org components to be added
or 
modified and what the implications are.

And, again, is this something we really want to do for Baseline?

-----

We are moving steadily in the direction of dynamic transactions and flexible

signature architectures. Do we NEED this for Baseline (for 1.0) or can this
wait
for a later version?

...chris

______________________________ Reply Separator
_________________________________
Subject: FW: Authorization before OTP
Author:  "Andrew Drapp" [SMTP:[email-masked]] at Internet
Date:    1998-09-24 09:10

This message from David Burdett, and meant for the list.
     
--
Andrew Drapp
[email-masked]
Hitachi Systems Development Laboratory
1099 Ozenji, Asao, Kawasaki, 215-0014 JAPAN 
TEL:+81-44-966-9111   FAX:+81-44-966-1796
Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F
     
-----Original Message-----
From:     David Burdett [SMTP:[email-masked]] 
Sent:     Thursday, September 24, 1998 9:36 PM
To:     'Andrew Drapp'
Subject:     RE: Authorization before OTP
     
See comments below.
     
David
>----------
>From:      Andrew Drapp[SMTP:[email-masked]] 
>Sent:      24 September 1998 06:02
>To:      David Burdett; [email-masked]' 
>Subject:      RE: Authorization before OTP
>
>
>David,
>
>I think I explained myself poorly.  When I said that the Org component is
in 
>the first OTP message, I was referring to the TPO as the first OTP message.

>
>
>When you say "The TPO Block can contain Organization Components" how
exactly 
>do you mean *can*.  From what I understood, the Org components were removed

>from the Offer response, and placed only in the TPO Block.  The Org 
>component would then be copied from message to message.  So, once the TPO 
>message is sent, the Org component has a fixed value that cannot be
changed. 
>
>
>If we change the Authentication Transaction so that it contains the details

>of the organization which is requesting the Authentication, then those 
>details should also include a net location for the auth response to go to. 
> If we made that change, then both the consumer and the merchant could 
>authenticate each other before a trade actually occurs.
>
>I think that would solve this problem.
>>>Agreed. Provided that the trading role(s) used by the requesting 
organisation reflect the organisation's intended role in the actual 
transaction. You could also make a constraint that the Organisation 
component should not change between the use in the authentication and 
the use in, for example, the Baseline Purchase.<<<
>
>--
>Andrew Drapp
>[email-masked]
>Hitachi Systems Development Laboratory 
>1099 Ozenji, Asao, Kawasaki, 215-0014 JAPAN 
>TEL:+81-44-966-9111   FAX:+81-44-966-1796
>Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F 
>
>-----Original Message-----
>From:     David Burdett [SMTP:[email-masked]] 
>Sent:     Wednesday, September 23, 1998 4:33 PM
>To:     'Andrew Drapp'
>Cc:     [email-masked]' 
>Subject:     RE: Authorization before OTP 
>
>Andrew
>
>Not quite right. The TPO Block can contain Organisation Components. We 
>should change the definition of the Authentication Transaction to >require 
that this contains the details of the organisation which is >requesting the 
Authentication specifying the role in which the >authenticator is taking in 
the transaction (Merchant, Payment Handler or >Delivery Handler).
>
>The consumer will then know who to send the response to. 
>
>David
>
>
>>----------
>>From:      Andrew Drapp[SMTP:[email-masked]] 
>>Sent:      22 September 1998 04:15
>>To:      [email-masked]' 
>>Subject:      Authorization before OTP 
>>
>>
>>At the OTP meeting in Reston, there was some discussion of using the 
>>Authorization exchange to automate the collection of personal information 
>
>>for a sale.  This would save time in typing out you name and address each 
>
>>time you purchased something.  This would have to occur before the first 
>OTP
>>message is sent, because the Org block is in the first message and cannot 
>be
>>changed later on.
>>
>>From what I remember of the meeting, it was generally agreed that this was

>a
>>good idea, and should be included in version 1.0 or 2.0. 
>>
>>However, I recently noticed a problem with that approach.  When the 
>consumer
>>receives an AuthReq block, it will have to be in HTML because the OTP 
>client
>>has not started yet.  This will kick off the OTP client which will create 
>
>>the AuthResp block.  The problem is, that the OTP client does not know 
>where
>>to send the AuthResp block.  No address information is included in the 
>>AuthReq block.  It is assumed that the OTP client could just check the 
>>TransId for the location, but because this occurs before the Offer 
>Exchange,
>>there is no TransId to refer too.
>>
>>Because of this, I suggest that:
>>
>>1.  We add addressing information to the AuthReq block, 
>>
>>or
>>
>>2.  We dump the idea to use the Authorization exchange outside of an OTP 
>>transaction.
>>
>>
>>Regards,
>>
>>Andrew Drapp
>>
>>
>>--
>>Andrew Drapp
>>[email-masked]
>>Hitachi Systems Development Laboratory 
>>1099 Ozenji, Asao, Kawasaki, 215-0014 JAPAN 
>>TEL:+81-44-966-9111   FAX:+81-44-966-1796
>>Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F 
>>
>>
>>----------------------------------------------------------------------- 
>>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]
>>
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>Mondex International Limited
>47-53 Cannon Street, London  EC4M 5SQ 
>England
>Registered No: 3122085, England
>
>Telephone No: +44 (0)171 557 5000
>Web Site: http://www.mondex.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]
>
     
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mondex International Limited
47-53 Cannon Street, London  EC4M 5SQ 
England
Registered No: 3122085, England
     
Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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: Andrew Drapp <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: Authorization before OTP
Date: Thu, 24 Sep 1998 22:10:47 +0900
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This message from David Burdett, and meant for the list.

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

-----Original Message-----
From:	David Burdett [SMTP:[email-masked]]
Sent:	Thursday, September 24, 1998 9:36 PM
To:	'Andrew Drapp'
Subject:	RE: Authorization before OTP

See comments below.

David
>----------
>From: 	Andrew Drapp[SMTP:[email-masked]]
>Sent: 	24 September 1998 06:02
>To: 	David Burdett; [email-masked]'
>Subject: 	RE: Authorization before OTP
>
>
>David,
>
>I think I explained myself poorly.  When I said that the Org component is in 
>the first OTP message, I was referring to the TPO as the first OTP message. 
>
>
>When you say "The TPO Block can contain Organization Components" how exactly 
>do you mean *can*.  From what I understood, the Org components were removed 
>from the Offer response, and placed only in the TPO Block.  The Org 
>component would then be copied from message to message.  So, once the TPO 
>message is sent, the Org component has a fixed value that cannot be changed. 
>
>
>If we change the Authentication Transaction so that it contains the details 
>of the organization which is requesting the Authentication, then those 
>details should also include a net location for the auth response to go to. 
> If we made that change, then both the consumer and the merchant could 
>authenticate each other before a trade actually occurs.
>
>I think that would solve this problem.
>>>Agreed. Provided that the trading role(s) used by the requesting
organisation reflect the organisation's intended role in the actual
transaction. You could also make a constraint that the Organisation
component should not change between the use in the authentication and
the use in, for example, the Baseline Purchase.<<<
>
>--
>Andrew Drapp
>[email-masked]
>Hitachi Systems Development Laboratory
>1099 Ozenji, Asao, Kawasaki, 215-0014 JAPAN
>TEL:+81-44-966-9111   FAX:+81-44-966-1796
>Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F
>
>-----Original Message-----
>From:	David Burdett [SMTP:[email-masked]]
>Sent:	Wednesday, September 23, 1998 4:33 PM
>To:	'Andrew Drapp'
>Cc:	[email-masked]'
>Subject:	RE: Authorization before OTP
>
>Andrew
>
>Not quite right. The TPO Block can contain Organisation Components. We
>should change the definition of the Authentication Transaction to
>require that this contains the details of the organisation which is
>requesting the Authentication specifying the role in which the
>authenticator is taking in the transaction (Merchant, Payment Handler or
>Delivery Handler).
>
>The consumer will then know who to send the response to.
>
>David
>
>
>>----------
>>From: 	Andrew Drapp[SMTP:[email-masked]]
>>Sent: 	22 September 1998 04:15
>>To: 	[email-masked]'
>>Subject: 	Authorization before OTP
>>
>>
>>At the OTP meeting in Reston, there was some discussion of using the
>>Authorization exchange to automate the collection of personal information 
>
>>for a sale.  This would save time in typing out you name and address each 
>
>>time you purchased something.  This would have to occur before the first 
>OTP
>>message is sent, because the Org block is in the first message and cannot 
>be
>>changed later on.
>>
>>From what I remember of the meeting, it was generally agreed that this was 
>a
>>good idea, and should be included in version 1.0 or 2.0.
>>
>>However, I recently noticed a problem with that approach.  When the 
>consumer
>>receives an AuthReq block, it will have to be in HTML because the OTP 
>client
>>has not started yet.  This will kick off the OTP client which will create 
>
>>the AuthResp block.  The problem is, that the OTP client does not know 
>where
>>to send the AuthResp block.  No address information is included in the
>>AuthReq block.  It is assumed that the OTP client could just check the
>>TransId for the location, but because this occurs before the Offer 
>Exchange,
>>there is no TransId to refer too.
>>
>>Because of this, I suggest that:
>>
>>1.  We add addressing information to the AuthReq block,
>>
>>or
>>
>>2.  We dump the idea to use the Authorization exchange outside of an OTP
>>transaction.
>>
>>
>>Regards,
>>
>>Andrew Drapp
>>
>>
>>--
>>Andrew Drapp
>>[email-masked]
>>Hitachi Systems Development Laboratory
>>1099 Ozenji, Asao, Kawasaki, 215-0014 JAPAN
>>TEL:+81-44-966-9111   FAX:+81-44-966-1796
>>Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F
>>
>>
>>-----------------------------------------------------------------------
>>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]
>>
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>Mondex International Limited
>47-53 Cannon Street, London  EC4M 5SQ
>England
>Registered No: 3122085, England
>
>Telephone No: +44 (0)171 557 5000
>Web Site: http://www.mondex.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]
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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]'" <[email-masked]>,  'Yoshiaki KAWATSURA' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11 September 1998
Date: Thu, 24 Sep 1998 13:48:58 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Is that clearer? ... Yes

An interesting problem though which requires more thought. Any ideas on
the solution?

David

>----------
>From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
>Sent: 	24 September 1998 11:00
>To: 	[email-masked]
>Cc: 	David Burdett; [email-masked]; [email-masked]
>Subject: 	RE: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11
>September 1998
>
>I revised some points of Andrew's comment. See below, please
>
>----
>Yoshiaki Kawatsura : E-mail [email-masked]
> Business & Information Systems Development Devision, Hitachi,Ltd.
> Voice: +81-45-948-1418(direct) Fax: +81-45-948-1421
>
>
>
>>>>>> Thu, 24 Sep 1998 14:16:42 +0900,
>	Andrew Drapp <[email-masked]> said:
>
>Yoshiaki wrote:
>>In current Payment APIs, Payment Bridge receives only the PackagedData
>>by the OAC, not the Component.The contents of the PayReceipt Component
>>are written by the Payment Bridge. Therefore an ElRef attribute can
>>not be used in the payment receipt data because the Payment Bridge
>>does not know the ID of the Components.
>
>To which David Responded:
>>>> I'm not sure I understand this. Can we discuss in the conference call 
>on
>24th. David<<<
>
>OK, let me see if I can explain this.  The Message flow would look something 
>like this:
>
>OTP Client(Consumer)
>    |         sends PaySchemeData Component (1)
>PH OTP software(OAC)
>    |         sends Packaged Data (1)
>Payment Bridge
>    |         sends Packaged Data  (2)
>PH OTP software(OAC)
>    |         sends PayReceipt Component (2)
>OTP Client(Consumer)
>
>The Packaged Data (2) contains the Payment Scheme Specific Receipt
>, which is created by the Payment Bridge software.  When the
>PH OTP Software(OAC) forwards the packaged content to the Payment Bridge,
>it does not send any of the OTP message outside of the packaged
>content.  The labeling (ID) of which component is which is in the OTP part
>of the message.  The Payment Bridge itself never receives this
>information.  So, when it generates the Pay Receipt, it does not know
>what components to reference.  Is that clearer?
>
>--
>Andrew Drapp
>[email-masked]
>Hitachi Systems Development Laboratory
>1099 Ozenji, Asao, Kawasaki, 215-0014 JAPAN
>TEL:+81-44-966-9111   FAX:+81-44-966-1796
>Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F
>
>-----Original Message-----
>From:	David Burdett [SMTP:[email-masked]]
>Sent:	Wednesday, September 23, 1998 4:33 PM
>To:	'Yoshiaki KAWATSURA'
>Cc:	[email-masked]'
>Subject:	RE: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11 
>September 1998
>
>See comments below.
>
>David
>
>>----------
>>From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
>>Sent: 	17 September 1998 12:37
>>To: 	David Burdett
>>Cc: 	[email-masked]; [email-masked]
>>Subject: 	Re: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11
>>September 1998
>>
>>David,
>>My comment is below(included the another issue.)
>>>>>>> Thu, 17 Sep 1998 10:25:08 +0100,
>>	David Burdett <[email-masked]> said:
>>> 4)	There was discussion about the "PackagedContent" of the Pay Receipt
>>> Component. This arose because the sub-group which was considering how
>>> SET can be encapsulated within OTP had decided to leave this content
>>> "empty" since receipt information was contained in the SET messages
>>> themselves.
>>>
>>> 	Now the definition of the Pay Receipt Component says that it is
>>> designed to prove, after the payment is complete, that the payment had
>>> occurred ***independently of the purchase***. An analogy is that it is
>>> the equivalent of the typically yellow (in the US) slip produced by
>>> real world credit card terminals which the customer may retain as
>>> evidence of the payment. This slip does not usually contain any
>>> identification of what goods were purchased. If the SET protocol when
>>> encapsulated within OTP did not retain these messages then it would be
>>> the equivalent of forcing the Consumer to always "throw away the
>>> credit card slip". However there was reluctance to copy the SET
>>> messages within the Pay Receipt Component since they could be several
>>> Kb in length.
>>>
>>> 	The proposed solution to this problem is to change the Pay Receipt
>>> Component so that it contains :
>>> a)	the payment receipt data in its PackagedContent, and/or
>>> b)	a new ElRef attribute, that contains references to other Components
>>> (potentially including Pay Scheme Components) which together make up
>>> the receipt. Note that:
>>
>>In current Payment APIs, Payment Bridge receives only the PackagedData
>>by the OAC, not the Component.The contents of the PayReceipt Component
>>are written by the Payment Bridge. Therefore an ElRef attribute can
>>not be used in the payment receipt data because the Payment Bridge
>>does not know the ID of the Components.
>>>> I'm not sure I understand this. Can we discuss in the conference call 
>on
>24th. David<<<
>>
>>--
>>Another Issue:
>>In the TpoBlk, ErrorNetLocn is listed twice, once in the
>>ProtocolOptions component and once in the Org component.  Should one
>>of them be deleted?  Since each trading role has its own ErrorNetLocn,
>>it makes since to leave it in the Org component.  If we delete it from
>>the ProtocolOptions component, then we should probably move the
>>CancelNetLocn element to the Org component as well.
>>>>Agreed<<<
>>
>>----
>>Yoshiaki Kawatsura : E-mail [email-masked]
>> Business & Information Systems Development Devision, Hitachi,Ltd.
>> Voice: +81-45-948-1418(direct) Fax: +81-45-948-1421
>>
>-----------------------------------------------------------------------
>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]
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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]'" <[email-masked]>,  'Hannu Nikkanen' <[email-masked]>
Subject: RE: Authorization before OTP
Date: Thu, 24 Sep 1998 13:45:26 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

>Hannu said "Also, it would be nice to have (optional) receiver name (if
different from "payer"). "

I *think* this is already covered in that the "DelivTo" role is the name
of the "reciever" where the Consumer role is the person or organisation
that is the "payer".

David

>----------
>From: 	Hannu Nikkanen[SMTP:[email-masked]]
>Sent: 	24 September 1998 10:20
>To: 	[email-masked]
>Subject: 	RE: Authorization before OTP
>
>At 01:57 AM 9/24/98 -0400, Donald Eastlake wrote:
>
>>---------------------------------------------------------------------------
>-----
>>I think that some way to deliver a ship-to address to the merchant, while it
>>may seem minor, is an important capability in practice.  The problem of
>>where
>>to send the IOTP response for an IOTP authentication request that is
>>included
>>in an HTTP response might eventually occur with other requests than
>>authenticaiton and in other trasnports than HTTP.
>>
>Strong support, in real life that's often needed.
>
>Also, it would be nice to have (optional) receiver name (if different from
>"payer"). In the office we use company credit card for authorized purchases
>and sometimes it's really difficult to find out, whose purchases the
>different records in the bill are.
>
>Hannu
> 
>
> 
>
>
>
>-----------------------------------------------------------------------
>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]
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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]'" <[email-masked]>,  'Donald Eastlake' <[email-masked]>
Subject: RE: Authorization before OTP
Date: Thu, 24 Sep 1998 13:41:36 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

See comments below

>----------
>From: 	Donald Eastlake[SMTP:[email-masked]]
>Sent: 	24 September 1998 06:57
>To: 	[email-masked]
>Subject: 	RE: Authorization before OTP

>I think that some way to deliver a ship-to address to the merchant, while it
>may seem minor, is an important capability in practice.  The problem of where
>to send the IOTP response for an IOTP authentication request that is included
>in an HTTP response might eventually occur with other requests than
>authenticaiton and in other trasnports than HTTP.
>
>Perhaps there should be an optional ContinuationNetLoc field which, if it
>occurs in a response, is where to send the next request and if it occurs in a
>request is where to send the response.  This would raise the question of what
>this means if it occurs in an IOTP request enclosed in an HTTP request but
>that
>could be treated as an error (i.e., the documention of ContinuationNetLoc
>could
>say that it may be prohibited in some transport contexts as indicated in the
>IOTP supplement for that transport)...
>>> I don't really like the idea of dynamically re-directing responses
although it is very flexible and powerful since it could potentially
be a "spoofer's" charter so that a message, e.g. for a payment could
be sent anywhere.

One way around this is to use signatures on the messages which contain a
re-direction which could potentially be any message.

I think it better to just use the Organisation Component net location.

David
<<<
>
>Donald
>
>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
>
>
>
>[email-masked] on 09/21/98 11:40:16 PM
>Please respond to [email-masked]
>To: [email-masked]
>cc:
>Subject: Authorization before OTP
>
>
>
>At the OTP meeting in Reston, there was some discussion of using the
>Authorization exchange to automate the collection of personal information
>for a sale.  This would save time in typing out you name and address each
>time you purchased something.  This would have to occur before the first OTP
>message is sent, because the Org block is in the first message and cannot be
>changed later on.
>
>>From what I remember of the meeting, it was generally agreed that this was a
>good idea, and should be included in version 1.0 or 2.0.
>
>However, I recently noticed a problem with that approach.  When the consumer
>receives an AuthReq block, it will have to be in HTML because the OTP client
>has not started yet.  This will kick off the OTP client which will create
>the AuthResp block.  The problem is, that the OTP client does not know where
>to send the AuthResp block.  No address information is included in the
>AuthReq block.  It is assumed that the OTP client could just check the
>TransId for the location, but because this occurs before the Offer Exchange,
>there is no TransId to refer too.
>
>Because of this, I suggest that:
>
>1.  We add addressing information to the AuthReq block,
>
>or
>
>2.  We dump the idea to use the Authorization exchange outside of an OTP
>transaction.
>
>
>Regards,
>
>Andrew Drapp
>
>
>--
>Andrew Drapp
>[email-masked]
>Hitachi Systems Development Laboratory
>1099 Ozenji, Asao, Kawasaki, 215-0014 JAPAN
>TEL:+81-44-966-9111   FAX:+81-44-966-1796
>Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F
>
>
>-----------------------------------------------------------------------
>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]
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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], [email-masked]
Cc: [email-masked]
Subject: RE: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11 September 1998
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 24 Sep 1998 19:00:02 +0900 (JST)
Lines: 128
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I revised some points of Andrew's comment. See below, please

----
Yoshiaki Kawatsura : E-mail [email-masked]
 Business & Information Systems Development Devision, Hitachi,Ltd.
 Voice: +81-45-948-1418(direct) Fax: +81-45-948-1421

>>>>> Thu, 24 Sep 1998 14:16:42 +0900,
	Andrew Drapp <[email-masked]> said:

Yoshiaki wrote:
>In current Payment APIs, Payment Bridge receives only the PackagedData
>by the OAC, not the Component.The contents of the PayReceipt Component
>are written by the Payment Bridge. Therefore an ElRef attribute can
>not be used in the payment receipt data because the Payment Bridge
>does not know the ID of the Components.

To which David Responded:
>>> I'm not sure I understand this. Can we discuss in the conference call 
on
24th. David<<<

OK, let me see if I can explain this.  The Message flow would look something 
like this:

OTP Client(Consumer)
    |         sends PaySchemeData Component (1)
PH OTP software(OAC)
    |         sends Packaged Data (1)
Payment Bridge
    |         sends Packaged Data  (2)
PH OTP software(OAC)
    |         sends PayReceipt Component (2)
OTP Client(Consumer)

The Packaged Data (2) contains the Payment Scheme Specific Receipt
, which is created by the Payment Bridge software.  When the
PH OTP Software(OAC) forwards the packaged content to the Payment Bridge,
it does not send any of the OTP message outside of the packaged
content.  The labeling (ID) of which component is which is in the OTP part
of the message.  The Payment Bridge itself never receives this
information.  So, when it generates the Pay Receipt, it does not know
what components to reference.  Is that clearer?

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

-----Original Message-----
From:	David Burdett [SMTP:[email-masked]]
Sent:	Wednesday, September 23, 1998 4:33 PM
To:	'Yoshiaki KAWATSURA'
Cc:	[email-masked]'
Subject:	RE: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11 
September 1998

See comments below.

David

>----------
>From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
>Sent: 	17 September 1998 12:37
>To: 	David Burdett
>Cc: 	[email-masked]; [email-masked]
>Subject: 	Re: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11
>September 1998
>
>David,
>My comment is below(included the another issue.)
>>>>>> Thu, 17 Sep 1998 10:25:08 +0100,
>	David Burdett <[email-masked]> said:
>> 4)	There was discussion about the "PackagedContent" of the Pay Receipt
>> Component. This arose because the sub-group which was considering how
>> SET can be encapsulated within OTP had decided to leave this content
>> "empty" since receipt information was contained in the SET messages
>> themselves.
>>
>> 	Now the definition of the Pay Receipt Component says that it is
>> designed to prove, after the payment is complete, that the payment had
>> occurred ***independently of the purchase***. An analogy is that it is
>> the equivalent of the typically yellow (in the US) slip produced by
>> real world credit card terminals which the customer may retain as
>> evidence of the payment. This slip does not usually contain any
>> identification of what goods were purchased. If the SET protocol when
>> encapsulated within OTP did not retain these messages then it would be
>> the equivalent of forcing the Consumer to always "throw away the
>> credit card slip". However there was reluctance to copy the SET
>> messages within the Pay Receipt Component since they could be several
>> Kb in length.
>>
>> 	The proposed solution to this problem is to change the Pay Receipt
>> Component so that it contains :
>> a)	the payment receipt data in its PackagedContent, and/or
>> b)	a new ElRef attribute, that contains references to other Components
>> (potentially including Pay Scheme Components) which together make up
>> the receipt. Note that:
>
>In current Payment APIs, Payment Bridge receives only the PackagedData
>by the OAC, not the Component.The contents of the PayReceipt Component
>are written by the Payment Bridge. Therefore an ElRef attribute can
>not be used in the payment receipt data because the Payment Bridge
>does not know the ID of the Components.
>>> I'm not sure I understand this. Can we discuss in the conference call 
on
24th. David<<<
>
>--
>Another Issue:
>In the TpoBlk, ErrorNetLocn is listed twice, once in the
>ProtocolOptions component and once in the Org component.  Should one
>of them be deleted?  Since each trading role has its own ErrorNetLocn,
>it makes since to leave it in the Org component.  If we delete it from
>the ProtocolOptions component, then we should probably move the
>CancelNetLocn element to the Org component as well.
>>>Agreed<<<
>
>----
>Yoshiaki Kawatsura : E-mail [email-masked]
> Business & Information Systems Development Devision, Hitachi,Ltd.
> Voice: +81-45-948-1418(direct) Fax: +81-45-948-1421
>
-----------------------------------------------------------------------
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: Thu, 24 Sep 1998 12:20:55 +0300
To: [email-masked]
From: Hannu Nikkanen <[email-masked]>
Subject: RE: Authorization before OTP
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

At 01:57 AM 9/24/98 -0400, Donald Eastlake wrote:

>---------------------------------------------------------------------------
-----
>I think that some way to deliver a ship-to address to the merchant, while it
>may seem minor, is an important capability in practice.  The problem of where
>to send the IOTP response for an IOTP authentication request that is included
>in an HTTP response might eventually occur with other requests than
>authenticaiton and in other trasnports than HTTP.
>
Strong support, in real life that's often needed.

Also, it would be nice to have (optional) receiver name (if different from
"payer"). In the office we use company credit card for authorized purchases
and sometimes it's really difficult to find out, whose purchases the
different records in the bill are.

Hannu

 

-----------------------------------------------------------------------
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: Authorization before OTP
Date: Tue, 22 Sep 1998 12:15:18 +0900
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

At the OTP meeting in Reston, there was some discussion of using the 
Authorization exchange to automate the collection of personal information 
for a sale.  This would save time in typing out you name and address each 
time you purchased something.  This would have to occur before the first OTP 
message is sent, because the Org block is in the first message and cannot be 
changed later on.

>From what I remember of the meeting, it was generally agreed that this was a
good idea, and should be included in version 1.0 or 2.0.

However, I recently noticed a problem with that approach.  When the consumer 
receives an AuthReq block, it will have to be in HTML because the OTP client 
has not started yet.  This will kick off the OTP client which will create 
the AuthResp block.  The problem is, that the OTP client does not know where 
to send the AuthResp block.  No address information is included in the 
AuthReq block.  It is assumed that the OTP client could just check the 
TransId for the location, but because this occurs before the Offer Exchange, 
there is no TransId to refer too.

Because of this, I suggest that:

1.  We add addressing information to the AuthReq block,

or

2.  We dump the idea to use the Authorization exchange outside of an OTP 
transaction.

Regards,

Andrew Drapp

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

-----------------------------------------------------------------------
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: RE: Authorization before OTP
Date: Thu, 24 Sep 1998 01:57:44 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I'm not sure why this failed the first time....

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

---------------------- Forwarded by Donald Eastlake/Hawthorne/IBM on 09/23/98
10:44 PM ---------------------------
Please respond to [email-masked]
To: Donald Eastlake/Hawthorne/IBM@IBMUS
cc:
Subject: Returned mail: Host unknown (Error 281)

The original message was received at Tue, 22 Sep 1998 08:34:16 -0400
from relay1.server.ibm.com [9.14.2.98]

   ----- The following addresses had permanent fatal errors -----
<[email-masked]>

   ----- Transcript of session follows -----
550 <[email-masked]>... Host unknown (Error 281)
--------------------------------------------------------------------------------
Final-Recipient: RFC822; [email-masked]
Action: failed
Status: 5.1.2
Remote-MTA: DNS; smtp.elistx.com
Last-Attempt-Date: Tue, 22 Sep 1998 08:37:29 -0400
--------------------------------------------------------------------------------
I think that some way to deliver a ship-to address to the merchant, while it
may seem minor, is an important capability in practice.  The problem of where
to send the IOTP response for an IOTP authentication request that is included
in an HTTP response might eventually occur with other requests than
authenticaiton and in other trasnports than HTTP.

Perhaps there should be an optional ContinuationNetLoc field which, if it
occurs in a response, is where to send the next request and if it occurs in a
request is where to send the response.  This would raise the question of what
this means if it occurs in an IOTP request enclosed in an HTTP request but that
could be treated as an error (i.e., the documention of ContinuationNetLoc could
say that it may be prohibited in some transport contexts as indicated in the
IOTP supplement for that transport)...

Donald

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

[email-masked] on 09/21/98 11:40:16 PM
Please respond to [email-masked]
To: [email-masked]
cc:
Subject: Authorization before OTP

At the OTP meeting in Reston, there was some discussion of using the
Authorization exchange to automate the collection of personal information
for a sale.  This would save time in typing out you name and address each
time you purchased something.  This would have to occur before the first OTP
message is sent, because the Org block is in the first message and cannot be
changed later on.

>From what I remember of the meeting, it was generally agreed that this was a
good idea, and should be included in version 1.0 or 2.0.

However, I recently noticed a problem with that approach.  When the consumer
receives an AuthReq block, it will have to be in HTML because the OTP client
has not started yet.  This will kick off the OTP client which will create
the AuthResp block.  The problem is, that the OTP client does not know where
to send the AuthResp block.  No address information is included in the
AuthReq block.  It is assumed that the OTP client could just check the
TransId for the location, but because this occurs before the Offer Exchange,
there is no TransId to refer too.

Because of this, I suggest that:

1.  We add addressing information to the AuthReq block,

or

2.  We dump the idea to use the Authorization exchange outside of an OTP
transaction.

Regards,

Andrew Drapp

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

-----------------------------------------------------------------------
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: Andrew Drapp <[email-masked]>
To: 'David Burdett' <[email-masked]>,  'Yoshiaki KAWATSURA' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11 September 1998
Date: Thu, 24 Sep 1998 14:16:42 +0900
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Yoshiaki wrote:
>In current Payment APIs, Payment Bridge receives only the PackagedData
>by the OAC, not the Component.The contents of the PayReceipt Component
>are written by the Payment Bridge. Therefore an ElRef attribute can
>not be used in the payment receipt data because the Payment Bridge
>does not know the ID of the Components.

To which David Responded:
>>> I'm not sure I understand this. Can we discuss in the conference call 
on
24th. David<<<

OK, let me see if I can explain this.  The Message flow would look something 
like this:

OTP Client
    |         sends Payment Component (1)
PH OTP software
    |         sends Packaged Data (1)
Payment Bridge
    |         sends Packaged Data  (2)
PH OTP software
    |         sends Payment Component (2)
OTP Client

The Packaged Data (2) contains the Pay Receipt component, which is created 
by the Payment Bridge software.  When the PH OTP software forwards the 
packaged content to the Payment Bridge, it does not send any of the OTP 
message outside of the packaged content.  The labeling of which component is 
which is in the OTP part of the message.  The Payment Bridge itself never 
receives this information.  So, when it generates the Pay Receipt, it does 
not know what components to reference.  Is that clearer?

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

-----Original Message-----
From:	David Burdett [SMTP:[email-masked]]
Sent:	Wednesday, September 23, 1998 4:33 PM
To:	'Yoshiaki KAWATSURA'
Cc:	[email-masked]'
Subject:	RE: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11 
September 1998

See comments below.

David

>----------
>From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
>Sent: 	17 September 1998 12:37
>To: 	David Burdett
>Cc: 	[email-masked]; [email-masked]
>Subject: 	Re: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11
>September 1998
>
>David,
>My comment is below(included the another issue.)
>>>>>> Thu, 17 Sep 1998 10:25:08 +0100,
>	David Burdett <[email-masked]> said:
>> 4)	There was discussion about the "PackagedContent" of the Pay Receipt
>> Component. This arose because the sub-group which was considering how
>> SET can be encapsulated within OTP had decided to leave this content
>> "empty" since receipt information was contained in the SET messages
>> themselves.
>>
>> 	Now the definition of the Pay Receipt Component says that it is
>> designed to prove, after the payment is complete, that the payment had
>> occurred ***independently of the purchase***. An analogy is that it is
>> the equivalent of the typically yellow (in the US) slip produced by
>> real world credit card terminals which the customer may retain as
>> evidence of the payment. This slip does not usually contain any
>> identification of what goods were purchased. If the SET protocol when
>> encapsulated within OTP did not retain these messages then it would be
>> the equivalent of forcing the Consumer to always "throw away the
>> credit card slip". However there was reluctance to copy the SET
>> messages within the Pay Receipt Component since they could be several
>> Kb in length.
>>
>> 	The proposed solution to this problem is to change the Pay Receipt
>> Component so that it contains :
>> a)	the payment receipt data in its PackagedContent, and/or
>> b)	a new ElRef attribute, that contains references to other Components
>> (potentially including Pay Scheme Components) which together make up
>> the receipt. Note that:
>
>In current Payment APIs, Payment Bridge receives only the PackagedData
>by the OAC, not the Component.The contents of the PayReceipt Component
>are written by the Payment Bridge. Therefore an ElRef attribute can
>not be used in the payment receipt data because the Payment Bridge
>does not know the ID of the Components.
>>> I'm not sure I understand this. Can we discuss in the conference call 
on
24th. David<<<
>
>--
>Another Issue:
>In the TpoBlk, ErrorNetLocn is listed twice, once in the
>ProtocolOptions component and once in the Org component.  Should one
>of them be deleted?  Since each trading role has its own ErrorNetLocn,
>it makes since to leave it in the Org component.  If we delete it from
>the ProtocolOptions component, then we should probably move the
>CancelNetLocn element to the Org component as well.
>>>Agreed<<<
>
>----
>Yoshiaki Kawatsura : E-mail [email-masked]
> Business & Information Systems Development Devision, Hitachi,Ltd.
> Voice: +81-45-948-1418(direct) Fax: +81-45-948-1421
>
>
>-----------------------------------------------------------------------
>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]
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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: Andrew Drapp <[email-masked]>
To: 'David Burdett' <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: RE: Authorization before OTP
Date: Thu, 24 Sep 1998 14:02:09 +0900
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,

I think I explained myself poorly.  When I said that the Org component is in 
the first OTP message, I was referring to the TPO as the first OTP message. 

When you say "The TPO Block can contain Organization Components" how exactly 
do you mean *can*.  From what I understood, the Org components were removed 
from the Offer response, and placed only in the TPO Block.  The Org 
component would then be copied from message to message.  So, once the TPO 
message is sent, the Org component has a fixed value that cannot be changed. 

If we change the Authentication Transaction so that it contains the details 
of the organization which is requesting the Authentication, then those 
details should also include a net location for the auth response to go to. 
 If we made that change, then both the consumer and the merchant could 
authenticate each other before a trade actually occurs.

I think that would solve this problem.

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

-----Original Message-----
From:	David Burdett [SMTP:[email-masked]]
Sent:	Wednesday, September 23, 1998 4:33 PM
To:	'Andrew Drapp'
Cc:	[email-masked]'
Subject:	RE: Authorization before OTP

Andrew

Not quite right. The TPO Block can contain Organisation Components. We
should change the definition of the Authentication Transaction to
require that this contains the details of the organisation which is
requesting the Authentication specifying the role in which the
authenticator is taking in the transaction (Merchant, Payment Handler or
Delivery Handler).

The consumer will then know who to send the response to.

David

>----------
>From: 	Andrew Drapp[SMTP:[email-masked]]
>Sent: 	22 September 1998 04:15
>To: 	[email-masked]'
>Subject: 	Authorization before OTP
>
>
>At the OTP meeting in Reston, there was some discussion of using the
>Authorization exchange to automate the collection of personal information 

>for a sale.  This would save time in typing out you name and address each 

>time you purchased something.  This would have to occur before the first 
OTP
>message is sent, because the Org block is in the first message and cannot 
be
>changed later on.
>
>From what I remember of the meeting, it was generally agreed that this was 
a
>good idea, and should be included in version 1.0 or 2.0.
>
>However, I recently noticed a problem with that approach.  When the 
consumer
>receives an AuthReq block, it will have to be in HTML because the OTP 
client
>has not started yet.  This will kick off the OTP client which will create 

>the AuthResp block.  The problem is, that the OTP client does not know 
where
>to send the AuthResp block.  No address information is included in the
>AuthReq block.  It is assumed that the OTP client could just check the
>TransId for the location, but because this occurs before the Offer 
Exchange,
>there is no TransId to refer too.
>
>Because of this, I suggest that:
>
>1.  We add addressing information to the AuthReq block,
>
>or
>
>2.  We dump the idea to use the Authorization exchange outside of an OTP
>transaction.
>
>
>Regards,
>
>Andrew Drapp
>
>
>--
>Andrew Drapp
>[email-masked]
>Hitachi Systems Development Laboratory
>1099 Ozenji, Asao, Kawasaki, 215-0014 JAPAN
>TEL:+81-44-966-9111   FAX:+81-44-966-1796
>Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F
>
>
>-----------------------------------------------------------------------
>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]
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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: Wed, 23 Sep 1998 09:01:41 +0100
From: Michael Gillespie <[email-masked]>
To: Andrew Drapp <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Consumer Authorization of PH
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I hope that I have understood you correctly because I think that this equates
with an area of "business risk", as perceived by the Consumer, but which may
have been satisfactorily covered within the Model.

>From the Customer's perspective there are some Merchants with whom they would
never do business because they don't trust them for a number of reasons, could
be product quality or after sales service quality etc.  But there are some
Merchants whom the Customer had noy previously known, and which they may become
unhappy/suspicious about DURING the total sales process - even after the Product
has been Selected, Payment Methods agreed, but before the "Point-of-No-Return"
in the Payment Stage.  As a Consumer I am not TOO worried that the problem can't
be resolved if I pay by Credit or Debit Card.  I AM worried if I pay by E-Cash,
especially if it is a type where Merchant Disintermediation is permitted (ie
Mondex in UK), that the "Merchant" could do a runner with my E-Cash which they
subsequently "spend" rather than "bank".  The TRADING RISK is very much on the
CONSUMER to be happy with the AUTHENTICITY of the Merchant.  From the other
angle, the Merchant (Payment Handler) is more than haapy to accept Payment from
ANYONE for a Transaction, so long as it is, in their view, "good money" and for
which they will receive Settlement.

With the interest being shown by Fraudsters in the opportunities/challenges for
them with both Smart Cards and E-Commerce, Consumers (including me!) do want to
be complete peace of mind (with zero risk) that the Merchant is not a
fraudster/student purporting to be one of well-known highly-trusted Merchants.

So, I'm interested in Andrew's views, but I would hope that his concerns have
been fully covered already in the Model.

Andrew Drapp wrote:

> There may be a need for the Consumer to authenticate the Payment Handler
> before sending the PaymentRequest message.  Imagine a situation where
> someone sets up a PH and then spoofs the IP of a known PH.  When the
> consumer sends the PaymentRequest message, it could be intercepted by the
> fake PH.
>
> In the current version of the specs, a trading exchange cannot be
> temporarily suspended and an authentication exchange started.  Since
> everything is signed and is assumed to be going over a secure channel (ssl),
> it seems that there is no reason that a PH or DH would need to authenticate
> a consumer.  Furthermore, it was mentioned at Reston that the fake PH would
> have to decrypt the offer exchange messages in order to successfully spoof a
> PH. I don't think this is quite true.  Once a hacker knows what PH a
> merchant uses, and what brands, he can set up a fake PH at his leisure.
>
> The simplest way to solve this would be to leave it up to the implementation
> of the client OTP software.  Something like having a checkbox somewhere
> saying "Send Authorization Request and wait for verification before sending
> Payment Request."  There should  be little problem adding an
> AuthReq/AuthResp between the OfferResp and the PayReq messages.
>
> Does this seem like something we should solve in OTP, or leave as an
> exercise for the reader?  Does anyone have any suggestions on how to change
> OTP to allow for the consumer to Authenticate the Payment Handler before any
> personal information is sent?
>
> Regards,
>
> Andrew Drapp
>
> --
> Andrew Drapp
> [email-masked]
> Hitachi Systems Development Laboratory
> 1099 Ozenji, Asao, Kawasaki, 215-0014 JAPAN
> TEL:+81-44-966-9111   FAX:+81-44-966-1796
> Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F
>
> -----------------------------------------------------------------------
> 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: "[email-masked]'" <[email-masked]>,  'Andrew Drapp' <[email-masked]>
Subject: RE: Consumer Authorization of PH
Date: Wed, 23 Sep 1998 08:33:29 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

We didn't authenticate the Payment Handler in OTP since all OTP really
does is carry a payment protocol. This means that it's up to the Payment
Protocol to do its own authentication to check that a payment is being
done to the correct organisation and stop the transaction if its not.

You could argue that if you're using a simple payment method like SCCD
where you just give the Payment Handler your credit card number, then
you will possibly have the risks which you suggest. However today
zillions of people are doing just this some without using SSL and some
with and nobody seems to be complaining.

Spoofing the payment handler becomes a problem then people will have an
incentive to use a more secure payment method like SET.

Any more thoughts anybody. This is one we should discuss.

David

>----------
>From: 	Andrew Drapp[SMTP:[email-masked]]
>Sent: 	22 September 1998 05:09
>To: 	[email-masked]'
>Subject: 	Consumer Authorization of PH
>
>
>There may be a need for the Consumer to authenticate the Payment Handler 
>before sending the PaymentRequest message.  Imagine a situation where 
>someone sets up a PH and then spoofs the IP of a known PH.  When the 
>consumer sends the PaymentRequest message, it could be intercepted by the 
>fake PH.
>
>In the current version of the specs, a trading exchange cannot be 
>temporarily suspended and an authentication exchange started.  Since 
>everything is signed and is assumed to be going over a secure channel (ssl), 
>it seems that there is no reason that a PH or DH would need to authenticate 
>a consumer.  Furthermore, it was mentioned at Reston that the fake PH would 
>have to decrypt the offer exchange messages in order to successfully spoof a 
>PH. I don't think this is quite true.  Once a hacker knows what PH a 
>merchant uses, and what brands, he can set up a fake PH at his leisure.
>
>The simplest way to solve this would be to leave it up to the implementation 
>of the client OTP software.  Something like having a checkbox somewhere 
>saying "Send Authorization Request and wait for verification before sending 
>Payment Request."  There should  be little problem adding an 
>AuthReq/AuthResp between the OfferResp and the PayReq messages.
>
>Does this seem like something we should solve in OTP, or leave as an 
>exercise for the reader?  Does anyone have any suggestions on how to change 
>OTP to allow for the consumer to Authenticate the Payment Handler before any 
>personal information is sent?
>
>Regards,
>
>Andrew Drapp
>
>--
>Andrew Drapp
>[email-masked]
>Hitachi Systems Development Laboratory
>1099 Ozenji, Asao, Kawasaki, 215-0014 JAPAN
>TEL:+81-44-966-9111   FAX:+81-44-966-1796
>Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F
>
>
>-----------------------------------------------------------------------
>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]
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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: 'Andrew Drapp' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Authorization before OTP
Date: Wed, 23 Sep 1998 08:33:27 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Andrew

Not quite right. The TPO Block can contain Organisation Components. We
should change the definition of the Authentication Transaction to
require that this contains the details of the organisation which is
requesting the Authentication specifying the role in which the
authenticator is taking in the transaction (Merchant, Payment Handler or
Delivery Handler).

The consumer will then know who to send the response to.

David

>----------
>From: 	Andrew Drapp[SMTP:[email-masked]]
>Sent: 	22 September 1998 04:15
>To: 	[email-masked]'
>Subject: 	Authorization before OTP
>
>
>At the OTP meeting in Reston, there was some discussion of using the 
>Authorization exchange to automate the collection of personal information 
>for a sale.  This would save time in typing out you name and address each 
>time you purchased something.  This would have to occur before the first OTP 
>message is sent, because the Org block is in the first message and cannot be 
>changed later on.
>
>From what I remember of the meeting, it was generally agreed that this was a 
>good idea, and should be included in version 1.0 or 2.0.
>
>However, I recently noticed a problem with that approach.  When the consumer 
>receives an AuthReq block, it will have to be in HTML because the OTP client 
>has not started yet.  This will kick off the OTP client which will create 
>the AuthResp block.  The problem is, that the OTP client does not know where 
>to send the AuthResp block.  No address information is included in the 
>AuthReq block.  It is assumed that the OTP client could just check the 
>TransId for the location, but because this occurs before the Offer Exchange, 
>there is no TransId to refer too.
>
>Because of this, I suggest that:
>
>1.  We add addressing information to the AuthReq block,
>
>or
>
>2.  We dump the idea to use the Authorization exchange outside of an OTP 
>transaction.
>
>
>Regards,
>
>Andrew Drapp
>
>
>--
>Andrew Drapp
>[email-masked]
>Hitachi Systems Development Laboratory
>1099 Ozenji, Asao, Kawasaki, 215-0014 JAPAN
>TEL:+81-44-966-9111   FAX:+81-44-966-1796
>Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F
>
>
>-----------------------------------------------------------------------
>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]
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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: "[email-masked]'" <[email-masked]>
Subject: RE: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11 September 1998
Date: Wed, 23 Sep 1998 08:33:26 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

See comments below.

David

>----------
>From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
>Sent: 	17 September 1998 12:37
>To: 	David Burdett
>Cc: 	[email-masked]; [email-masked]
>Subject: 	Re: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11
>September 1998
>
>David,
>My comment is below(included the another issue.)
>>>>>> Thu, 17 Sep 1998 10:25:08 +0100,
>	David Burdett <[email-masked]> said:
>> 4)	There was discussion about the "PackagedContent" of the Pay Receipt 
>> Component. This arose because the sub-group which was considering how 
>> SET can be encapsulated within OTP had decided to leave this content 
>> "empty" since receipt information was contained in the SET messages 
>> themselves.
>> 
>> 	Now the definition of the Pay Receipt Component says that it is 
>> designed to prove, after the payment is complete, that the payment had 
>> occurred ***independently of the purchase***. An analogy is that it is 
>> the equivalent of the typically yellow (in the US) slip produced by 
>> real world credit card terminals which the customer may retain as 
>> evidence of the payment. This slip does not usually contain any 
>> identification of what goods were purchased. If the SET protocol when 
>> encapsulated within OTP did not retain these messages then it would be 
>> the equivalent of forcing the Consumer to always "throw away the 
>> credit card slip". However there was reluctance to copy the SET 
>> messages within the Pay Receipt Component since they could be several 
>> Kb in length.
>> 
>> 	The proposed solution to this problem is to change the Pay Receipt 
>> Component so that it contains :
>> a)	the payment receipt data in its PackagedContent, and/or
>> b)	a new ElRef attribute, that contains references to other Components 
>> (potentially including Pay Scheme Components) which together make up 
>> the receipt. Note that:
>
>In current Payment APIs, Payment Bridge receives only the PackagedData
>by the OAC, not the Component.The contents of the PayReceipt Component
>are written by the Payment Bridge. Therefore an ElRef attribute can
>not be used in the payment receipt data because the Payment Bridge
>does not know the ID of the Components.
>>> I'm not sure I understand this. Can we discuss in the conference call on
24th. David<<<
>
>--
>Another Issue:
>In the TpoBlk, ErrorNetLocn is listed twice, once in the
>ProtocolOptions component and once in the Org component.  Should one
>of them be deleted?  Since each trading role has its own ErrorNetLocn,
>it makes since to leave it in the Org component.  If we delete it from
>the ProtocolOptions component, then we should probably move the
>CancelNetLocn element to the Org component as well.
>>>Agreed<<<
>
>----
>Yoshiaki Kawatsura : E-mail [email-masked]
> Business & Information Systems Development Devision, Hitachi,Ltd.
> Voice: +81-45-948-1418(direct) Fax: +81-45-948-1421
>
>
>-----------------------------------------------------------------------
>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]
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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' <[email-masked]>,  'Andrew Drapp' <[email-masked]>
Subject: RE: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11 September 1998
Date: Wed, 23 Sep 1998 08:33:24 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

On second thoughts, there is no reason why an *optional* PayNote, cannot
be added into version 1.0.

David

>----------
>From: 	Andrew Drapp[SMTP:[email-masked]]
>Sent: 	17 September 1998 12:05
>To: 	David Burdett; 'IETF Trade'
>Subject: 	RE: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11
>September 1998
>
>
>> VERSION 2.0 IDEAS
>> 1)	There was discussion about the Consumer authenticating the Payment
>>Handler
>>    as part of a Payment Exchange for Version 2.0. Andrew Drapp of Hitachi
>>will
>>    post a message.
>
>Sorry about the delay.  We have had a couple of national holidays here this
>week, so I am a bit behind on things.  I should have it posted by the end of
>the week.
>
>>  2)	Idea raised that the Payment Handler should be able to provide
>>information 
>>     over and above the information in the Payment Receipt Component to the 
>>     Consumer. For example, if payment was being done by money transfer or 
>>     a debit transaction then the Payment Handler could provide information
>>on 
>>     the remaining balance on the account after the transfer was complete.
>>This
>>     might need an additional component such as a "Payment Note" component.
>
>Actually, I was hoping this could be included in version 1.0.  Basically, in
>the Payment Receipt Component, adding an additional field so it would appear
>as:
>
><!ELEMENT PayReceipt (PackagedContent, PayNote) >
><!ATTLIST PayReceipt
>...>
>
>Where, PayNote would have the same use as the PackegedContonent element in
>the Order Component.   The PayNote element would be just an additional
>Packaged Content element.
>
>
>
>--
>Andrew Drapp
>[email-masked]
>Hitachi Systems Development Laboratory
>1099 Ozenji, Asao, Kawasaki, 215 JAPAN
>TEL:+81-44-966-9111   FAX:+81-44-966-1796
>
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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: Andrew Drapp <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Consumer Authorization of PH
Date: Tue, 22 Sep 1998 13:09:56 +0900
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

There may be a need for the Consumer to authenticate the Payment Handler 
before sending the PaymentRequest message.  Imagine a situation where 
someone sets up a PH and then spoofs the IP of a known PH.  When the 
consumer sends the PaymentRequest message, it could be intercepted by the 
fake PH.

In the current version of the specs, a trading exchange cannot be 
temporarily suspended and an authentication exchange started.  Since 
everything is signed and is assumed to be going over a secure channel (ssl), 
it seems that there is no reason that a PH or DH would need to authenticate 
a consumer.  Furthermore, it was mentioned at Reston that the fake PH would 
have to decrypt the offer exchange messages in order to successfully spoof a 
PH. I don't think this is quite true.  Once a hacker knows what PH a 
merchant uses, and what brands, he can set up a fake PH at his leisure.

The simplest way to solve this would be to leave it up to the implementation 
of the client OTP software.  Something like having a checkbox somewhere 
saying "Send Authorization Request and wait for verification before sending 
Payment Request."  There should  be little problem adding an 
AuthReq/AuthResp between the OfferResp and the PayReq messages.

Does this seem like something we should solve in OTP, or leave as an 
exercise for the reader?  Does anyone have any suggestions on how to change 
OTP to allow for the consumer to Authenticate the Payment Handler before any 
personal information is sent?

Regards,

Andrew Drapp

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

-----------------------------------------------------------------------
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 Minutes from IETF Chicago
Date: Sun, 20 Sep 1998 23:45:29 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The following minutes were taken by Surendra Reddy
<[email-masked]>.  I have made some minor changes and additions
and should be blamed for any errors.

Thanks,
Donald

Minutes of the 1st IETF Trade Working Group Meeting:
Wednesday August 26th, 1998
9 am-11:30 AM

1. Donald Eastlake started the 1st IETF Trade Working Group meeting
with the following agenda:

	0. Agenda Bashing (5 minutes)
	1. Status of Implementation
		a. Royal Bank of Canada (15 minutes)
		b. other(s)?
	2.  v1.0 Status of Documents (15 minutes)
		a. Main 1.0 OTP Draft
		b. OTP Digital Signatures
		c. OTP architecutre
		d. OTP over HTTP
		e. SET over OTP
		f.  Secure Channel Credit/Debit over OTP
		g.  Electronic cash over OTP
	3. v1.0 Technical Issues (40 minutes)
		a. Digital Signatures
		b. other technical issues
	4. v2.0 Planning (30 minutes) Disucssion of how to proceed
		towards a fuller OTP
	5. Future meetings (15 minutes)
		a. September at CyberCash in Virginia
		b. November at Hitachi in Japan
		c. December at IETF

Unfortunately a number of documents were not ready in time and so
could not be substantively discussed.

2.  Group members raised many questions regarding the trade
charter. Donald advised them to discuss that on the list.

3.  IOTP 1.0 will be published as informational RFC.

4.  Group felt that we need to come up with requirements for 2.0 work
which will be carried out under IETF Working Group.  Donald pointed
Business Functional requirements of the IOTP 1.0 spec would be a good
candidates for starting of discussions on IOTP 2.0 requirements.

5.  Donald requested the group members to send their
suggestions/comments on transitioning IOTP specification development
from OTP Consortium to IETF.

6.  Implementation Status of IOTP Spec 0.9: RBC(Royal Bank of Canada)
has implemented OTP product based on otp .9 spec. Waiting for Chris
Smith's report on the completeness of the .9 spec and hence released
99.

7.  Donald explained the difference between OBI (Open Buying on the
Internet) and IOTP as:

IOTP(C2B) -- customer to {merchant, payment handler, deliver,
	customer care, payment customer care}.
OBI(B2B) -- { requistor, approver, payer} to merchant.  Is more matured
	specification but deployment seems to be disappointing

8.  Patrik Faltstrom (Area Director) explained to the group that all
IETF Trade WG intermediate meetings between IETF meetings MUST be
announced on the IETF Announce list and minutes SHOULD be published to
WG mailing list.

9.  On the issue of getting access to the OTP Consortium web site
private area and mailing lists, Donald and Steve Fabes explained that
all mailing lists from OTP can be moved to IETF Trade WG archive and
Steve Fabes also mentioned that all IETF Trade WG members will be
given access to the current OTP private area.  All IETF Trade
discussions are archived at: http://www.elistx/com/archives/ietf-trade

10.  Steve Fabes read out the list of OTP consortium members.

11. Different members expressed the immediate need for strawman
documents on Requirements and current IOTP specification. Donald
assured to the group that these documents would be published at the
earlist as I-Ds.

12.  Next interim IETF Trade WG meeting will be held at Cybercash in
Reston, Virginia, on September 9th through 11th and Donald mentioned
that all the minutes of these meeting would be published Trade
discussion list.

As there is no further issues to be discussed, meeting adjourned.
-----------------------------------------------------------------------
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: Surendra Reddy <[email-masked]>
To: David Burdett <[email-masked]>,  'IETF Trade' <[email-masked]>
Subject: RE: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11 September 1998
Date: Thu, 17 Sep 1998 06:36:38 +0100
Importance: Normal
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This is a multi-part message in MIME format.

------=_NextPart_000_000C_01BDE205.85B753A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Can someone post the meeting minutes. 

Surendra

> -----Original Message-----
> From:	[email-masked] 
> [mailto:[email-masked]] On Behalf Of David Burdett
> Sent:	Thursday, September 17, 1998 10:25 AM
> To:	'IETF Trade'
> Subject:	Spec Changes from IOTP Workshop at CyberCash 
> Reston, 9-11 September 1998
> 
> This note contains changes to the OTP specs that were identified 
> during the Trade WG Workshop held at CyberCash in Reston VA o 
> 9-11 September. It contains:
> * Changes which the attendees at the meeting thought should be 
>   included in Version 1.0 of the specification
> * Some ideas which should be considered for inclusion in Version 
>   2.0. Note that there are additional potential changes which 
>   were identified and discussed which are included in the 
>   Charter. Therefore this list is not exhaustive.
> 
> The wider views and comments of other Trade WG members is 
> requested before finalising these changes.
> 
> Regards
> 
> David Burdett
> ---------------------
> CHANGES FOR VERSION 1.0 AS AGREED BY WORKSHOP ATTENDEES
> 1)	The Payment Response Signature currently does not sign the 
> Status component. This means that the success or failure of the 
> Payment can not be authenticated using a Payment Handler 
> signature. Therefore propose that the Signature in the same OTP 
> Message as the Payment Response Block signs the Status Component 
> if signatures are being used.
> 
> 2)	The Delivery Request Block contains no indication of the 
> success or failure of the Payment and therefore that the Delivery 
> is authorised. Currently this can only be inferred if a signature 
> is present. However as signatures may be used to authenticate a 
> payment has failed (see previous point), this is not sufficient. 
> Therefore propose that the Status Component from the OTP Message 
> that contains the Payment Request is passed to the Delivery 
> handler together with the Delivery Request.
> 
> 3)	For consistency, propose that we also include the Status 
> Component from the Offer Response in the Payment Request to prove 
> to the Payment Handler that the generation of the Offer Response 
> was successful.
> 
> 4)	There was discussion about the "PackagedContent" of the Pay 
> Receipt Component. This arose because the sub-group which was 
> considering how SET can be encapsulated within OTP had decided to 
> leave this content "empty" since receipt information was 
> contained in the SET messages themselves. 
> 
> 	Now the definition of the Pay Receipt Component says that 
> it is designed to prove, after the payment is complete, that the 
> payment had occurred ***independently of the purchase***. An 
> analogy is that it is the equivalent of the typically yellow (in 
> the US) slip produced by real world credit card terminals which 
> the customer may retain as evidence of the payment. This slip 
> does not usually contain any identification of what goods were 
> purchased. If the SET protocol when encapsulated within OTP did 
> not retain these messages then it would be the equivalent of 
> forcing the Consumer to always "throw away the credit card slip". 
> However there was reluctance to copy the SET messages within the 
> Pay Receipt Component since they could be several Kb in length.
> 
> 	The proposed solution to this problem is to change the Pay 
> Receipt Component so that it contains :
> a)	the payment receipt data in its PackagedContent, and/or
> b)	a new ElRef attribute, that contains references to other 
> Components (potentially including Pay Scheme Components) which 
> together make up the receipt. Note that:
> i)	the components which must be referenced are payment method 
> dependent,
> ii)	each of the components referenced must be hashed and signed 
> in the Payment Response signature component, if one is being used
> iii)	the client software should save all the components 
> referenced so that the payment receipt can be reconstructed when required
> 
> 5)	Terry Allen had previously raised by e-mail a suggestion 
> that the OTP Critical attribute should be changed to #REQUIRED 
> and default to 'True'. This was agreed.
> 
> 6)	Dual Brand is included in the explanation of Brands and 
> Brand Selection. However Dual Brands need no special treatment by 
> the Merchant and therefore has no impact on the DTD. It is 
> proposed to clarify the description of Dual Brand to state that 
> it does not need to be included in the DTD as each brand is 
> treated separately.
> 
> 7)	Propose to change the content type of PackagedContent to 
> CDATA from NMTOKEN as NMTOKEN does not validly allow a forward 
> slash which may be contained, for example as in "plain/text"
> 
> 8)	Order Description Component:
> a)	Currently this states: "The description of the order in the 
> Packaged Content should not include currency and amount 
> information since this is contained in the payment related 
> trading components (Brand List, Brand Selection and Payment)." 
> This was considered to strong a statement by the attendees.
> b)	Therefore propose it should say "Although the amount and 
> currency are likely to appear in the Packaged Content it is the 
> amount and currency contained in the payment related trading 
> components (Brand List, Brand Selection and Payment) that is 
> authoritative. This means it is important that the amount 
> actually being paid (as contained in the payment related trading 
> components) is prominently displayed to the Consumer."
> 
> 9)	Payment Handler & Delivery Handler.
> a)	Identified a need for the Payment Handler to be able to 
> inform the Delivery Handler of out of band information about the 
> results of the payment. For example that a credit card payment 
> had been authorised but not captured. As there may be other 
> information which a Payment Handler might need to communicate to 
> the Delivery Handler, it is proposed to provide a generalised 
> approach to sending this information is included in OTP. This 
> could be included as an additional Packaged Content element on 
> the Payment Response Block which is then copied to the Delivery 
> Request Block. 
> b)	Note that there is also be a need for exchange of 
> information between the Payment Handler and the Delivery Handler 
> about the results of a delivery after the OTP transaction is 
> complete, for example so that the credit card payment can be 
> captured. Note that it is proposed that it is *not* included in 
> version 1.0 of OTP although it could be included in version 2.0.
> 
> 10)	Correction. Figure 30 in the spec (Refund without 
> Authentication) is incorrect as it is the same as figure 29.
> 
> 11)	Correction to section 7. References to Organisation 
> Components in the description of an Offer Response Block contains 
> should be moved to the TPO Block. This will make it consistent 
> with the DTD.
> 
> 12)	Section 7.1.3 Authentication Response Block should include 
> reference to the ability for Consumers to include Organisation 
> components as part of the response. This will make it consistent 
> with the DTD
> 
> VERSION 2.0 IDEAS
> 1)	There was discussion about the Consumer authenticating the 
> Payment Handler as part of a Payment Exchange for Version 2.0. 
> Andrew Drapp of Hitachi will post a message.
> 
> 2)	Idea raised that the Payment Handler should be able to 
> provide information over and above the information in the Payment 
> Receipt Component to the Consumer. For example, if payment was 
> being done by money transfer or a debit transaction then the 
> Payment Handler could provide information on the remaining 
> balance on the account after the transfer was complete.  This 
> might need an additional component such as a "Payment Note" component.
> 
> 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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> Mondex International Limited
> 47-53 Cannon Street, London  EC4M 5SQ
> England
> Registered No: 3122085, England
> 
> Telephone No: +44 (0)171 557 5000
> Web Site: http://www.mondex.com

------=_NextPart_000_000C_01BDE205.85B753A0
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

------=_NextPart_000_000C_01BDE205.85B753A0--

-----------------------------------------------------------------------
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: 'David Burdett' <[email-masked]>,  'IETF Trade' <[email-masked]>
Subject: RE: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11 September 1998
Date: Thu, 17 Sep 1998 20:05:40 +0900
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

------ =_NextPart_000_01BDE276.8C9168C0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

> VERSION 2.0 IDEAS
> 1)	There was discussion about the Consumer authenticating the Payment 
Handler
>    as part of a Payment Exchange for Version 2.0. Andrew Drapp of Hitachi 
will
>    post a message.

Sorry about the delay.  We have had a couple of national holidays here this 
week, so I am a bit behind on things.  I should have it posted by the end of 
the week.

>  2)	Idea raised that the Payment Handler should be able to provide 
information
>     over and above the information in the Payment Receipt Component to the 

>     Consumer. For example, if payment was being done by money transfer or 

>     a debit transaction then the Payment Handler could provide information 
on
>     the remaining balance on the account after the transfer was complete. 
 This
>     might need an additional component such as a "Payment Note" 
component.

Actually, I was hoping this could be included in version 1.0.  Basically, in 
the Payment Receipt Component, adding an additional field so it would appear 
as:

<!ELEMENT PayReceipt (PackagedContent, PayNote) >
<!ATTLIST PayReceipt
...>

Where, PayNote would have the same use as the PackegedContonent element in 
the Order Component.   The PayNote element would be just an additional 
Packaged Content element.

--
Andrew Drapp
[email-masked]
Hitachi Systems Development Laboratory
1099 Ozenji, Asao, Kawasaki, 215 JAPAN
TEL:+81-44-966-9111   FAX:+81-44-966-1796

------ =_NextPart_000_01BDE276.8C9168C0
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

------ =_NextPart_000_01BDE276.8C9168C0--

-----------------------------------------------------------------------
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: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11 September 1998
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 17 Sep 1998 20:07:03 +0900 (JST)
Lines: 50
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,
My comment is below(included the another issue.)
>>>>> Thu, 17 Sep 1998 10:25:08 +0100,
	David Burdett <[email-masked]> said:
> 4)	There was discussion about the "PackagedContent" of the Pay Receipt 
> Component. This arose because the sub-group which was considering how 
> SET can be encapsulated within OTP had decided to leave this content 
> "empty" since receipt information was contained in the SET messages 
> themselves.
> 
> 	Now the definition of the Pay Receipt Component says that it is 
> designed to prove, after the payment is complete, that the payment had 
> occurred ***independently of the purchase***. An analogy is that it is 
> the equivalent of the typically yellow (in the US) slip produced by 
> real world credit card terminals which the customer may retain as 
> evidence of the payment. This slip does not usually contain any 
> identification of what goods were purchased. If the SET protocol when 
> encapsulated within OTP did not retain these messages then it would be 
> the equivalent of forcing the Consumer to always "throw away the 
> credit card slip". However there was reluctance to copy the SET 
> messages within the Pay Receipt Component since they could be several 
> Kb in length.
> 
> 	The proposed solution to this problem is to change the Pay Receipt 
> Component so that it contains :
> a)	the payment receipt data in its PackagedContent, and/or
> b)	a new ElRef attribute, that contains references to other Components 
> (potentially including Pay Scheme Components) which together make up 
> the receipt. Note that:

In current Payment APIs, Payment Bridge receives only the PackagedData
by the OAC, not the Component.The contents of the PayReceipt Component
are written by the Payment Bridge. Therefore an ElRef attribute can
not be used in the payment receipt data because the Payment Bridge
does not know the ID of the Components.

--
Another Issue:
In the TpoBlk, ErrorNetLocn is listed twice, once in the
ProtocolOptions component and once in the Org component.  Should one
of them be deleted?  Since each trading role has its own ErrorNetLocn,
it makes since to leave it in the Org component.  If we delete it from
the ProtocolOptions component, then we should probably move the
CancelNetLocn element to the Org component as well.

----
Yoshiaki Kawatsura : E-mail [email-masked]
 Business & Information Systems Development Devision, Hitachi,Ltd.
 Voice: +81-45-948-1418(direct) Fax: +81-45-948-1421

-----------------------------------------------------------------------
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: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11 September 1998
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 17 Sep 1998 20:37:05 +0900 (JST)
Lines: 51
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,
My comment is below(included the another issue.)
>>>>> Thu, 17 Sep 1998 10:25:08 +0100,
	David Burdett <[email-masked]> said:
> 4)	There was discussion about the "PackagedContent" of the Pay Receipt 
> Component. This arose because the sub-group which was considering how 
> SET can be encapsulated within OTP had decided to leave this content 
> "empty" since receipt information was contained in the SET messages 
> themselves.
> 
> 	Now the definition of the Pay Receipt Component says that it is 
> designed to prove, after the payment is complete, that the payment had 
> occurred ***independently of the purchase***. An analogy is that it is 
> the equivalent of the typically yellow (in the US) slip produced by 
> real world credit card terminals which the customer may retain as 
> evidence of the payment. This slip does not usually contain any 
> identification of what goods were purchased. If the SET protocol when 
> encapsulated within OTP did not retain these messages then it would be 
> the equivalent of forcing the Consumer to always "throw away the 
> credit card slip". However there was reluctance to copy the SET 
> messages within the Pay Receipt Component since they could be several 
> Kb in length.
> 
> 	The proposed solution to this problem is to change the Pay Receipt 
> Component so that it contains :
> a)	the payment receipt data in its PackagedContent, and/or
> b)	a new ElRef attribute, that contains references to other Components 
> (potentially including Pay Scheme Components) which together make up 
> the receipt. Note that:

In current Payment APIs, Payment Bridge receives only the PackagedData
by the OAC, not the Component.The contents of the PayReceipt Component
are written by the Payment Bridge. Therefore an ElRef attribute can
not be used in the payment receipt data because the Payment Bridge
does not know the ID of the Components.

--
Another Issue:
In the TpoBlk, ErrorNetLocn is listed twice, once in the
ProtocolOptions component and once in the Org component.  Should one
of them be deleted?  Since each trading role has its own ErrorNetLocn,
it makes since to leave it in the Org component.  If we delete it from
the ProtocolOptions component, then we should probably move the
CancelNetLocn element to the Org component as well.

----
Yoshiaki Kawatsura : E-mail [email-masked]
 Business & Information Systems Development Devision, Hitachi,Ltd.
 Voice: +81-45-948-1418(direct) Fax: +81-45-948-1421

-----------------------------------------------------------------------
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' <[email-masked]>
Subject: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11 September 1998
Date: Thu, 17 Sep 1998 10:25:08 +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_01BDE225.72754FC0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

This note contains changes to the OTP specs that were identified 
during the Trade WG Workshop held at CyberCash in Reston VA o 9-11 
September. It contains:
*	Changes which the attendees at the meeting thought should be 
included in Version 1.0 of the specification
*	Some ideas which should be considered for inclusion in Version 2.0. 
Note that there are additional potential changes which were identified 
and discussed which are included in the Charter. Therefore this list 
is not exhaustive.

The wider views and comments of other Trade WG members is requested 
before finalising these changes.

Regards

David Burdett
---------------------
CHANGES FOR VERSION 1.0 AS AGREED BY WORKSHOP ATTENDEES
1)	The Payment Response Signature currently does not sign the Status 
component. This means that the success or failure of the Payment can 
not be authenticated using a Payment Handler signature. Therefore 
propose that the Signature in the same OTP Message as the Payment 
Response Block signs the Status Component if signatures are being 
used.

2)	The Delivery Request Block contains no indication of the success or 
failure of the Payment and therefore that the Delivery is authorised. 
Currently this can only be inferred if a signature is present. However 
as signatures may be used to authenticate a payment has failed (see 
previous point), this is not sufficient. Therefore propose that the 
Status Component from the OTP Message that contains the Payment 
Request is passed to the Delivery handler together with the Delivery 
Request.

3)	For consistency, propose that we also include the Status Component 
from the Offer Response in the Payment Request to prove to the Payment 
Handler that the generation of the Offer Response was successful.

4)	There was discussion about the "PackagedContent" of the Pay Receipt 
Component. This arose because the sub-group which was considering how 
SET can be encapsulated within OTP had decided to leave this content 
"empty" since receipt information was contained in the SET messages 
themselves.

	Now the definition of the Pay Receipt Component says that it is 
designed to prove, after the payment is complete, that the payment had 
occurred ***independently of the purchase***. An analogy is that it is 
the equivalent of the typically yellow (in the US) slip produced by 
real world credit card terminals which the customer may retain as 
evidence of the payment. This slip does not usually contain any 
identification of what goods were purchased. If the SET protocol when 
encapsulated within OTP did not retain these messages then it would be 
the equivalent of forcing the Consumer to always "throw away the 
credit card slip". However there was reluctance to copy the SET 
messages within the Pay Receipt Component since they could be several 
Kb in length.

	The proposed solution to this problem is to change the Pay Receipt 
Component so that it contains :
a)	the payment receipt data in its PackagedContent, and/or
b)	a new ElRef attribute, that contains references to other Components 
(potentially including Pay Scheme Components) which together make up 
the receipt. Note that:
i)	the components which must be referenced are payment method 
dependent,
ii)	each of the components referenced must be hashed and signed in the 
Payment Response signature component, if one is being used
iii)	the client software should save all the components referenced so 
that the payment receipt can be reconstructed when required

5)	Terry Allen had previously raised by e-mail a suggestion that the 
OTP Critical attribute should be changed to #REQUIRED and default to 
'True'. This was agreed.

6)	Dual Brand is included in the explanation of Brands and Brand 
Selection. However Dual Brands need no special treatment by the 
Merchant and therefore has no impact on the DTD. It is proposed to 
clarify the description of Dual Brand to state that it does not need 
to be included in the DTD as each brand is treated separately.

7)	Propose to change the content type of PackagedContent to CDATA from 
NMTOKEN as NMTOKEN does not validly allow a forward slash which may be 
contained, for example as in "plain/text"

8)	Order Description Component:
a)	Currently this states: "The description of the order in the 
Packaged Content should not include currency and amount information 
since this is contained in the payment related trading components 
(Brand List, Brand Selection and Payment)." This was considered to 
strong a statement by the attendees.
b)	Therefore propose it should say "Although the amount and currency 
are likely to appear in the Packaged Content it is the amount and 
currency contained in the payment related trading components (Brand 
List, Brand Selection and Payment) that is authoritative. This means 
it is important that the amount actually being paid (as contained in 
the payment related trading components) is prominently displayed to 
the Consumer."

9)	Payment Handler & Delivery Handler.
a)	Identified a need for the Payment Handler to be able to inform the 
Delivery Handler of out of band information about the results of the 
payment. For example that a credit card payment had been authorised 
but not captured. As there may be other information which a Payment 
Handler might need to communicate to the Delivery Handler, it is 
proposed to provide a generalised approach to sending this information 
is included in OTP. This could be included as an additional Packaged 
Content element on the Payment Response Block which is then copied to 
the Delivery Request Block.
b)	Note that there is also be a need for exchange of information 
between the Payment Handler and the Delivery Handler about the results 
of a delivery after the OTP transaction is complete, for example so 
that the credit card payment can be captured. Note that it is proposed 
that it is *not* included in version 1.0 of OTP although it could be 
included in version 2.0.

10)	Correction. Figure 30 in the spec (Refund without Authentication) 
is incorrect as it is the same as figure 29.

11)	Correction to section 7. References to Organisation Components in 
the description of an Offer Response Block contains should be moved to 
the TPO Block. This will make it consistent with the DTD.

12)	Section 7.1.3 Authentication Response Block should include 
reference to the ability for Consumers to include Organisation 
components as part of the response. This will make it consistent with 
the DTD

VERSION 2.0 IDEAS
1)	There was discussion about the Consumer authenticating the Payment 
Handler as part of a Payment Exchange for Version 2.0. Andrew Drapp of 
Hitachi will post a message.

2)	Idea raised that the Payment Handler should be able to provide 
information over and above the information in the Payment Receipt 
Component to the Consumer. For example, if payment was being done by 
money transfer or a debit transaction then the Payment Handler could 
provide information on the remaining balance on the account after the 
transfer was complete.  This might need an additional component such 
as a "Payment Note" component.

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.com
------ =_NextPart_000_01BDE225.72754FC0
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

------ =_NextPart_000_01BDE225.72754FC0--
-----------------------------------------------------------------------
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' <[email-masked]>,  David Birch <[email-masked]>
Subject: RE: OTP, OECD and tax collection
Date: Tue, 15 Sep 1998 23:42:52 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Tax evasion is as old as the centuries. I doubt that OTP if its used for
tax collection by the governments will change peoples inclination to pay
(or not pay) one bit. The point is, if governments want to collect taxes
then they will find a way to do it and most merchants who have a
reputation to protect will follow it. 

It would be a bit sad though if tax collection is what people remembered
OTP for ...

But I really I though people working on OTP would like to know about
what the German government is doing.

David Burdett

>----------
>From: 	David Birch
>Sent: 	15 September 1998 07:20
>To: 	David Burdett; 'IETF Trade'
>Subject: 	Re: OTP, OECD and tax collection
>
>David Burdett said
>
>>If it is successful, then there 
>>should be a strong government led push to implement OTP.
>
>and a strong consumer-led push not to use it?
>
>Cheers :)
>Dave Birch.
>
>=== mailto:[email-masked] ===== http://www.hyperion.co.uk/ ===
>
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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]

Subject: Re: OTP, OECD and tax collection
Date: Tue, 15 Sep 1998 07:20:12 +0100
From: Dave Birch <[email-masked]>
To: David Burdett <[email-masked]>,  'IETF Trade' <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David Burdett said

>If it is successful, then there 
>should be a strong government led push to implement OTP.

and a strong consumer-led push not to use it?

Cheers :)
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]

Date: Mon, 14 Sep 98 16:17:52 GMT
From: William Allen Simpson <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Normative literal files...
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

> From: Donald Eastlake <[email-masked]>
> Possibilities for embedding include MIME or other special formating so that,
> for example, there would be a standard RFC822/MIME prefix you could prepend to
> an RFC text and MIME processing of the result would exhibit the literal files
> or other standardized special processing would extract them.  Or there could be
> permission to include relative URLs pointing to files via the RFC directory,
> presumably with file names constrained to start with RFCnnnn for files
> associated with RFCnnnn or the like.
>
As best as I remember, for ifmib, there is an iftype file referenced at
IANA.  The base is contained in the RFC, but the most current and
complete is accessed from the net.

On the other hand, most of the ifmib is paginated, and you have to
extract it from the rfc by hand, as you previously mentioned.

You could look at the PGP publication technique.  We should make that
(or something like it) an Internet Standard :)

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
-----------------------------------------------------------------------
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' <[email-masked]>
Subject: OTP, OECD and tax collection
Date: Mon, 14 Sep 1998 22:41:58 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The attached PDF file describes how the German government is proposing to 
the OECD that OTP is used to facilitate the collection of sales taxes (e.g. 
VAT or some other sales tax) for purchases made on the Internet.

The proposal is due to be disccussed at the OECD Electronic Commerce 
conference in early October in Ottawa. If it is successful, then there 
should be a strong government led push to implement OTP.

The PDF file contains a diagram which describes the process. The text of 
the document is also contained below (minus the diagram).

Regards

David Burdett

[[ OTP_OE~1.PDF : 5377 in WINMAIL.DAT ]]

Text of document follows ...

OTP, OECD AND TAX COLLECTION
This note describes how the German government is proposing to the OECD that 
OTP is used to facilitate the collection of sales taxes (e.g. VAT or some 
other sales tax) for purchases made on the Internet. It is a record of an 
explanation provided by Hans Bernhard Beykirch of SIZ (the IT Development 
and Coordination Centre of the German Savings Banks Organisation) during 
the IETF Trade Working Group workshop held at CyberCash, Reston, VA, USA on 
10-11 September 1998.

This proposal will be discussed at the OECD conference on Electronic 
Commerce in Ottawa on 7-9 October 1998 (see 
http://www.oecd.org/news_and_events/release/nw98-78a.htm).

This note contains:
*	an explanation of the current problems with collecting tax for sales on 
the Internet
*	the solution proposed by the German government
*	alternative solutions being proposed
*	an analysis of the likely impact.

The explanation below is believed to be accurate although the author 
accepts no responsibility for any inconsistencies or inaccuracies which 
this note may contain.

Also please note that any views described here represent the views of the 
Author rather than Mondex International.

CURRENT SITUATION
Currently sales taxes are normally charged based on the location of the 
Merchant on the assumption that the purchaser is also in the same location 
at the time of purchase. However if a Merchant is "exporting" goods or 
services then no sales tax is imposed at the point of sale and, instead, 
taxes are (or should be) imposed at the point of importation based on the 
eventual destination of the goods or services which is typically the 
location or residence of the purchaser.

This presents a problem for tax collection authorities since it is easy 
(and commercially advantageous) for a Merchant to not impose a sales tax, 
but subsequently very difficult for the tax to be collected at the point of 
importation especially when the goods or services are being "imported" 
electronically over the Internet.

As a result governments are currently suffering decreases in sales tax 
revenue from purchases made over the Internet. This problem will only get 
worse if, as anticipated, Internet purchases begin to represent larger 
proportions of the total sales of goods or services within a country.

It is the author's understanding that the intention of the OECD is that 
sales taxes continue to be based on the location of the purchaser rather 
than the location of the Merchant. The problem is how to collect it 
efficiently, fairly and effectively.

GERMAN GOVERNMENT PROPOSAL
After discussions with and at the suggestion of SIZ the German government 
has now proposed the following solution to the problem as illustrated in 
the diagram below.

<<<< Diagram here >>>

The first step is that the Merchant obtains information on proof of 
residence of the purchaser. This could potentially take a number of forms 
including:
*	the Consumer entering location information on an HTML form
*	the use of a software digital certificate, or
*	a hardware token such as a smart card.

This information is then used to look up tax rate information which applies 
to that location. provided by the Government Financial Administration (or 
tax collecting authority) of the country where the Merchant is located. So 
for example if a US merchant was making a sale to a UK consumer then the 
tax rate which was provided would be 17.5% (the UK VAT rate). If the 
consumer was based in the US, then the State as well as the Country would 
be taken into account. This "looking up" of data could occur either in real 
time or more likely as a regular download of information.

The merchant would then calculate the tax due using this rate and include 
this amount in the amount which the consumer is due to pay. So for example 
if a UK Consumer was buying goods for $100 from a US merchant, then they 
would be charged a total of $117.50.

The Merchant would also keep records of their transactions so that, at 
intervals agreed with the tax authority they make a payment either directly 
to their Financial Administration or via their Financial Institution (e.g. 
a bank).

They would also submit tax returns for a period to their financial 
administration likely to be along the lines of:

Loc	Rate	No Tx	Tax due	
UK	17.5	357	4783.23 USD	
DE	16.5	2403	5783.49 USD	

The financial administration for each country would then use the 
information in the tax returns to settle the taxes due between them.

For the Merchant this is, in many ways, "business as usual" since Merchants 
need to keep records of the transactions they have made under current 
accounting practices. These records will be subject to audit by their 
accountants and possibly their Government's Financial Administration Tax 
Inspectors.

OTP's role in this approach is to provide the means by which the Merchant 
can provide information to the Consumer about the taxes being paid in a way 
which is globally interoperable, non-refutable and should stand up in law. 
The messaging structure of OTP could also be used to provide a standardised 
way by which Merchants obtain information on tax rates from their 
Government's Financial Administration and a way by which they submit their 
tax returns.

ALTERNATIVE SOLUTIONS PROPOSED
Hans Bernhard Beykirch knows of one alternative proposal being put forward 
which suggests that payment brands would be required to collect taxes for 
Internet transactions. In outline this would mean that when a payment is 
being captured it would have to be identified as being an Internet 
transaction and taxes at the appropriate rate captured and returned to the 
central government by the Payment gateway which accepts the payment.

ANALYSIS
In the Author's view, if governments are losing tax revenue (as on the 
Internet) it is inevitable that they will eventually take steps to reverse 
the situation. Otherwise additional tax revenues would have to be collected 
using other more direct forms of taxation which would probably be unfair. 
Basically it is unrealistic to expect the Internet to be a "tax free zone" 
for commerce in the medium to long term.

Collecting taxes from the Merchants using OTP closely follows current 
models of sales tax collection, whereas collecting taxes using the Payment 
Gateway is a radical departure. It is also likely that using a payment 
method for tax collection will only work for payment methods which involve 
capture and settlement of individual payments. This would make payment 
methods which don't require settlement of each payment more attractive as a 
means of evading tax.

Finally, if OTP is used as the means by which Tax is collected for Internet 
purchases, it should provide a strong "top down" government led pressure 
for OTP's adoption.

David Burdett
Mondex International Ltd
14 September 1998

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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: Surendra Reddy <[email-masked]>
To: "Donald E. Eastlake 3rd" <[email-masked]>
Cc: [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Subject: RE: Namespace? (was Re: Normative literal files...)
Date: Mon, 14 Sep 1998 12:01:54 +0100
Importance: Normal
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I meant registering an IOTP XML namespace.

surendra

> -----Original Message-----
> From: Donald E. Eastlake 3rd [mailto:[email-masked]]
> Sent: Monday, September 14, 1998 7:44 PM
> To: Surendra Reddy
> Cc: [email-masked]
> Subject: Namespace? (was Re: Normative literal files...)
>
>
> Hi Surendra,
>
> I've dropped the poised mailing list from the cc's because I don't
> quite see what it has to do with namespaces (and I don't quite see
> what namespaces have to do with my original message).  Are you talking
> about registering aniotp XML namespace?  Registering the IOTP
> APPLICATION/IOTP type?  or just what?
>
> Thanks,
> Donlad
>
> From:  Surendra Reddy <[email-masked]>
> To:  Donald Eastlake <[email-masked]>, [email-masked]
> Cc:  [email-masked]
> Date:  Mon, 14 Sep 1998 07:31:57 -0700
> Message-ID:  <[email-masked]>
>
> >How about registering IOTP namespace with IANA?
> >
> >Surendra
> >
> >
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]]On Behalf Of Donald Eastlake
> >> Sent: Sunday, September 13, 1998 9:46 PM
> >> To: [email-masked]
> >> Cc: [email-masked]
> >> Subject: Normative literal files...
> >>
> >>
> >> Hi,
> >>
> >> I am posting this on behalf of the IETF TRADE working group.
> >>
> >> At its recent meeting in Reston, Virginia, questions arose in
> the WG as to
> >> how
> >> to best handle the XML DTD that is part of the Internet Open
> >> Trading Protocol
> >> specification.The WG charter calls for intially publishing IOTP V1.0 as
> >> Informational and developing a V2.0 aimed at Proposed Standard but that
> >> distinction is not important to this question.
> >>
> >> Since RFCs are the only authoritative protocol publication ofthe
> >> IETF, such
> >> items as DTDs, C source code, MIBs, etc, must all be shoehorned
> >> into such a
> >> paginated format, currently in ASCII (and in some cases
> PostScript).  But
> >> manysuch literal descriptive "files" commonly exceed a page and
> >> it would be
> >> desireable to have their exact content accessible for machine
> >> processing.  I
> >> know that this topic has been raised before and the general
> >> decision was to
> >> muddle along with the understanding that people will attack the
> >> ASCII version
> >> of the RFC with a text editor and hopefully extract a good
> copy.  Is this
> >> still
> >> the case or should their be some way of associating normative
> >> literal files
> >> with an RFC, possibly by some standardized machine processable means of
> >> embedd
> >> ing them in the RFC or linking them to it, so the exact machine
> >> processable
> >> file (and possibly a checksum) can be mechanically accessed?
> >>
> >> Possibilities for embedding include MIME or other special
> >> formating so that,
> >> for example, there would be a standard RFC822/MIME prefix you
> >> could prepend
> >> to
> >> an RFC text and MIME processing of the result would exhibit the
> >> literal files
> >> or other standardized special processing would extract them.  Or
> >> there could
> >> be
> >> permission to include relative URLs pointing to files via the RFC
> >> directory,
> >> presumably with file names constrained to start with RFCnnnn for files
> >> associated with RFCnnnn or the like.
> >>
> >> Any thoughts?
> >> Donald
> >>
> >> 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
> >> -----------------------------------------------------------------------
> >> 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]

To: Surendra Reddy <[email-masked]>
cc: [email-masked]
Subject: Namespace? (was Re: Normative literal files...)
Date: Mon, 14 Sep 1998 14:44:02 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Hi Surendra,

I've dropped the poised mailing list from the cc's because I don't
quite see what it has to do with namespaces (and I don't quite see
what namespaces have to do with my original message).  Are you talking
about registering an iotp XML namespace?  Registering the IOTP
APPLICATION/IOTP type?  or just what?

Thanks,
Donlad

From:  Surendra Reddy <[email-masked]>
To:  Donald Eastlake <[email-masked]>, [email-masked]
Cc:  [email-masked]
Date:  Mon, 14 Sep 1998 07:31:57 -0700
Message-ID:  <[email-masked]>

>How about registering IOTP namespace with IANA?
>
>Surendra
>
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]]On Behalf Of Donald Eastlake
>> Sent: Sunday, September 13, 1998 9:46 PM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: Normative literal files...
>>
>>
>> Hi,
>>
>> I am posting this on behalf of the IETF TRADE working group.
>>
>> At its recent meeting in Reston, Virginia, questions arose in the WG as to
>> how
>> to best handle the XML DTD that is part of the Internet Open
>> Trading Protocol
>> specification.The WG charter calls for intially publishing IOTP V1.0 as
>> Informational and developing a V2.0 aimed at Proposed Standard but that
>> distinction is not important to this question.
>>
>> Since RFCs are the only authoritative protocol publication ofthe
>> IETF, such
>> items as DTDs, C source code, MIBs, etc, must all be shoehorned
>> into such a
>> paginated format, currently in ASCII (and in some cases PostScript).  But
>> manysuch literal descriptive "files" commonly exceed a page and
>> it would be
>> desireable to have their exact content accessible for machine
>> processing.  I
>> know that this topic has been raised before and the general
>> decision was to
>> muddle along with the understanding that people will attack the
>> ASCII version
>> of the RFC with a text editor and hopefully extract a good copy.  Is this
>> still
>> the case or should their be some way of associating normative
>> literal files
>> with an RFC, possibly by some standardized machine processable means of
>> embedd
>> ing them in the RFC or linking them to it, so the exact machine
>> processable
>> file (and possibly a checksum) can be mechanically accessed?
>>
>> Possibilities for embedding include MIME or other special
>> formating so that,
>> for example, there would be a standard RFC822/MIME prefix you
>> could prepend
>> to
>> an RFC text and MIME processing of the result would exhibit the
>> literal files
>> or other standardized special processing would extract them.  Or
>> there could
>> be
>> permission to include relative URLs pointing to files via the RFC
>> directory,
>> presumably with file names constrained to start with RFCnnnn for files
>> associated with RFCnnnn or the like.
>>
>> Any thoughts?
>> Donald
>>
>> 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
>> -----------------------------------------------------------------------
>> 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: Surendra Reddy <[email-masked]>
To: Donald Eastlake <[email-masked]>, [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Cc: [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Subject: RE: Normative literal files...
Date: Mon, 14 Sep 1998 07:31:57 -0700
Importance: Normal
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

How about registering IOTP namespace with IANA?

Surendra

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Donald Eastlake
> Sent: Sunday, September 13, 1998 9:46 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Normative literal files...
>
>
> Hi,
>
> I am posting this on behalf of the IETF TRADE working group.
>
> At its recent meeting in Reston, Virginia, questions arose in the WG as to
> how
> to best handle the XML DTD that is part of the Internet Open
> Trading Protocol
> specification.The WG charter calls for intially publishing IOTP V1.0 as
> Informational and developing a V2.0 aimed at Proposed Standard but that
> distinction is not important to this question.
>
> Since RFCs are the only authoritative protocol publication ofthe
> IETF, such
> items as DTDs, C source code, MIBs, etc, must all be shoehorned
> into such a
> paginated format, currently in ASCII (and in some cases PostScript).  But
> manysuch literal descriptive "files" commonly exceed a page and
> it would be
> desireable to have their exact content accessible for machine
> processing.  I
> know that this topic has been raised before and the general
> decision was to
> muddle along with the understanding that people will attack the
> ASCII version
> of the RFC with a text editor and hopefully extract a good copy.  Is this
> still
> the case or should their be some way of associating normative
> literal files
> with an RFC, possibly by some standardized machine processable means of
> embedd
> ing them in the RFC or linking them to it, so the exact machine
> processable
> file (and possibly a checksum) can be mechanically accessed?
>
> Possibilities for embedding include MIME or other special
> formating so that,
> for example, there would be a standard RFC822/MIME prefix you
> could prepend
> to
> an RFC text and MIME processing of the result would exhibit the
> literal files
> or other standardized special processing would extract them.  Or
> there could
> be
> permission to include relative URLs pointing to files via the RFC
> directory,
> presumably with file names constrained to start with RFCnnnn for files
> associated with RFCnnnn or the like.
>
> Any thoughts?
> Donald
>
> 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
> -----------------------------------------------------------------------
> 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: Donald Eastlake <[email-masked]>
To: [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Cc: [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Subject: Normative literal files...
Date: Mon, 14 Sep 1998 00:46:08 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Hi,

I am posting this on behalf of the IETF TRADE working group.

At its recent meeting in Reston, Virginia, questions arose in the WG as to how
to best handle the XML DTD that is part of the Internet Open Trading Protocol
specification.  The WG charter calls for intially publishing IOTP V1.0 as
Informational and developing a V2.0 aimed at Proposed Standard but that
distinction is not important to this question.

Since RFCs are the only authoritative protocol publication of the IETF, such
items as DTDs, C source code, MIBs, etc, must all be shoehorned into such a
paginated format, currently in ASCII (and in some cases PostScript).  But
manysuch literal descriptive "files" commonly exceed a page and it would be
desireable to have their exact content accessible for machine processing.  I
know that this topic has been raised before and the general decision was to
muddle along with the understanding that people will attack the ASCII version
of the RFC with a text editor and hopefully extract a good copy.  Is this still
the case or should their be some way of associating normative literal files
with an RFC, possibly by some standardized machine processable means of embedd
ing them in the RFC or linking them to it, so the exact machine processable
file (and possibly a checksum) can be mechanically accessed?

Possibilities for embedding include MIME or other special formating so that,
for example, there would be a standard RFC822/MIME prefix you could prepend to
an RFC text and MIME processing of the result would exhibit the literal files
or other standardized special processing would extract them.  Or there could be
permission to include relative URLs pointing to files via the RFC directory,
presumably with file names constrained to start with RFCnnnn for files
associated with RFCnnnn or the like.

Any thoughts?
Donald

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
-----------------------------------------------------------------------
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: "[email-masked]'" <[email-masked]>
Subject: RE: PackagedContent of Brand,PayProtocol,ProtocolAmount
Date: Sat, 5 Sep 1998 02:09:44 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Yoshiaki

You are correct in what you say about Packaged Content. However this
change has already been made to the version 0.99 which is on the otp web
site.

I apologise for this inconsistency.

Let me explain ...

I *think* the version of the OTP specs you're looking at has a "print
date" (see bottom right of first page) of "18/08/98 23:39" (lets call
this version A). The current version on the web site has a print date of
"17/08/98 19:18" (lets call this version B). There are *very* few
differences between them but one of them is the one you identify.

I tried to post version A to the web site but it failed. However I also
sent version A to OTP-dev which is how you have a copy (I think).

However before I could repost version A to the Web Site, I received
comments on an earlier version (version 0.9.8) of the spec from Werner
Hans which were *very* sensible and corrected a number of silly errors.
I therefore made the changes to version A to create version B which was
then, successfully, posted to the Web site.

However I forgot that I'd sent version A to otp-dev, and hence the
inconsistency ... :-( 

If you want to understand the changes between version A and version B,
please read the attached copy of Werner's e-mail and my response which I
sent to otp-dev.

Question 12 caused the inconsistency you identify. Also note that the
section numbers in the e-mail refer to version 0.98 which are all one
higher than in version 0.99.

If you have any more questions please get in touch.

David

>----------
>From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
>Sent: 	04 September 1998 11:46
>To: 	[email-masked]
>Cc: 	[email-masked]
>Subject: 	PackagedContent of Brand,PayProtocol,ProtocolAmount
>
>PackagedContent of Brand,PayProtocol,ProtocolAmount are specified as
>#REQUIRED in OTP Specification document ver0.99, such that,
> <!ELEMENT Brand (PackagedContent)> // See 5.6.1 
> <!ELEMENT ProtocolAmount (PackagedContent)> // See 5.6.2 
> <!ELEMENT PayProtocol (PackagedContent)> // See 5.6.4
>
>I think this mistakes. 
>
>I think the correct are as followings,
> <!ELEMENT ProtocolAmount (PackagedContent?)>
> <!ELEMENT Brand (PackagedContent?)>
> <!ELEMENT PayProtocol (PackagedContent?)>
>
>OTP Data Type Difinition document Ver0.99 is also described them above,
>such that "PackagedContent?".
>                          ^
>
>----
>Yoshiaki Kawatsura : E-mail [email-masked]
> Business & Information Systems Development Devision, Hitachi,Ltd.
> Voice: +81-45-948-1418(direct) Fax: +81-45-948-1421
>
>
>
>
>-----------------------------------------------------------------------
>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]
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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]
Subject: PackagedContent of Brand,PayProtocol,ProtocolAmount
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Fri, 04 Sep 1998 19:46:13 +0900 (JST)
Lines: 25
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

PackagedContent of Brand,PayProtocol,ProtocolAmount are specified as
#REQUIRED in OTP Specification document ver0.99, such that,
 <!ELEMENT Brand (PackagedContent)> // See 5.6.1 
 <!ELEMENT ProtocolAmount (PackagedContent)> // See 5.6.2 
 <!ELEMENT PayProtocol (PackagedContent)> // See 5.6.4

I think this mistakes. 

I think the correct are as followings,
 <!ELEMENT ProtocolAmount (PackagedContent?)>
 <!ELEMENT Brand (PackagedContent?)>
 <!ELEMENT PayProtocol (PackagedContent?)>

OTP Data Type Difinition document Ver0.99 is also described them above,
such that "PackagedContent?".
                          ^

----
Yoshiaki Kawatsura : E-mail [email-masked]
 Business & Information Systems Development Devision, Hitachi,Ltd.
 Voice: +81-45-948-1418(direct) Fax: +81-45-948-1421

-----------------------------------------------------------------------
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: 'Steve Fabes' <[email-masked]>,  "[email-masked]'" <[email-masked]>
Cc: 'Brian Boesch' <[email-masked]>
Subject: Reston IETF OTP WG attendance 
Date: Fri, 4 Sep 1998 10:54:00 +0900
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

There will be three, or possibly four of us from Hitachi at the meeting. 
 Oh, and since this is for donuts, I am partial to the glazed chocolate 
ones.  Those always seem to be the first to run out, so I am counting on 
your foresight and planning.  ;-)

--
Andrew Drapp
[email-masked]
Hitachi Systems Development Laboratory
1099 Ozenji, Asao, Kawasaki, 215 JAPAN
TEL:+81-44-966-9111   FAX:+81-44-966-1796

-----Original Message-----
From:	Steve Fabes [SMTP:[email-masked]]
Sent:	Friday, September 04, 1998 1:35 AM
To:	[email-masked]'
Cc:	'Brian Boesch'
Subject:	******* IMPORTANT NEWS - MUST READ ****************

Sorry for the panic banner but we would like to hear (quickly) from those 
who will attend the OTP TRADE Working Group meeting to be held at 
CyberCash's facility in Reston next week. Need is simple - chairs and 
donuts!

The meeting is a three day event. Please note that the first day session on 
the 9th will be for payment specific work and in fact should be considered 
outside the realm of IETF interest. Todate we have two active payment groups 
- SET and Mondex, the later requiring a signed NDA with Mondex in order to 
attend.

The IETF session is on 10-11th and will focus on the OTP Spec v0.9.9 and the 
plans to move it to v1.0 and over the next year onto v2,0.

Know also that we will carve out an hour or so - probably on Friday to 
address one aspect of the shut-down of the old OTP Consortium regarding the 
OTP-Dev email list group and the CommerceNet proposal.

So............. please reply and state your planned attendance by each of 
the three days... thanks Steve
Steve Fabes
Development Director, Mondex International Advanced Technology
111 Pine St 6th Floor, San Francisco, CA 94111
Tel:1-415-645-6972 Fax: 1-415-956-5017
<http://www.mondex.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]'" <[email-masked]>
Cc: 'Brian Boesch' <[email-masked]>
Subject: ******* IMPORTANT NEWS - MUST READ ****************
Date: Thu, 3 Sep 1998 09:34:52 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Sorry for the panic banner but we would like to hear (quickly) from =
those who will attend the OTP TRADE Working Group meeting to be held at =
CyberCash's facility in Reston next week. Need is simple - chairs and =
donuts!

The meeting is a three day event. Please note that the first day session =
on the 9th will be for payment specific work and in fact should be =
considered outside the realm of IETF interest. Todate we have two active =
payment groups - SET and Mondex, the later requiring a signed NDA with =
Mondex in order to attend.=20

The IETF session is on 10-11th and will focus on the OTP Spec v0.9.9 and =
the plans to move it to v1.0 and over the next year onto v2,0.

Know also that we will carve out an hour or so - probably on Friday to =
address one aspect of the shut-down of the old OTP Consortium regarding =
the OTP-Dev email list group and the CommerceNet proposal.=20

So............. please reply and state your planned attendance by each =
of the three days... thanks Steve
Steve Fabes =20
Development Director, Mondex International Advanced Technology
111 Pine St 6th Floor, San Francisco, CA 94111
Tel:1-415-645-6972 Fax: 1-415-956-5017=20
<http://www.mondex.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]
Subject: Rough Agenda for Trade Meeting 9-11 Sep 1998
Date: Wed, 02 Sep 1998 19:48:49 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This a rough agenda for the previously scheduled meeting.  There may
be some re-arrangement, espcecially of the material on the 10th and
11th.

Day One:  This day will be primarily devoted to meetings of those
concerned with how specific payment protocols will be tunnelled
through the Internet Open Trading Protocol (IOTP).  There will be an
initial general gathering, probably something like 9am to 10am,
followed by breakout into payment system specific groups, a break
for lunch, and re-assembly from 4pm to 5pm to discuss and IOTP
requirements or modifications that have been suggested by the
payment system meetings. No doubt there will be an open payment
system meeting on SET.

(Note that there may be closed parallel meetings on proprietary
payment systems.   IOTP is designed so that proprietary payment
system payloads can be transported by IOTP messages.  Needless to
say, it is the open payment system independent IOTP framework that
is the main target for eventual IETF standardization.)

Day Two:  This day nad the start of the third day will be have the
primary technical discussion of IOTP.  Expected to run from 9am to
5pm with a lunch break.  Topics to include: 1. Status of
Implementation 1.a Royal Bank of Canada 1... other(s)? 2. v1.0
Status of Documents and Technical Issues 2.a Main 1.0 OTP Draft, 
DTD 2.b OTP Digital Signatures 2.c OTP architecutre 2.d OTP over
HTTP 2.e SET over OTP 2.f Secure Channel Credit/Debit over OTP 2...
others(s)? 3. v2.0 Planning Disucssion of requirements and how to
proceed towards a fuller OTP 4. Future meetings 5.b November at
Hitachi in Japan? 5.c December at IETF?

Day Three:  Overflow of WG technical disucssions from day two
followed by OTP Consortium discussion.  Expected to start at 9am,
have a lunch break, and conclude by 3pm.  Although it will be open,
the OTP Consortium discussion portion is not an official part of the
WG meeting. The Consortium is expected to evolve into a membership
group that may coordinate some interoperability testing and promote
IOTP.

Thanks,
Donald

=====================================================================
 Donald E. Eastlake 3rd   +1 978-287-4877    [email-masked]
 318 Acton Street         +1 978-371-7148(fax)
 Carlisle, MA 01741 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: 'Hannu Nikkanen' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]'>
Subject: RE: I have a comment for Spec. 5.4.1(Order Description)
Date: Wed, 2 Sep 1998 19:11:57 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

See comments below between >>> and <<< which compare Hannu's comments
against what OTP currently provides.

David

>----------
>From: 	Hannu Nikkanen[SMTP:[email-masked]]
>Sent: 	02 September 1998 10:34
>To: 	[email-masked]'
>Subject: 	RE: I have a comment for Spec. 5.4.1(Order Description)
>
>Hi,
>
>find below a few points about currency exchange, which might be considered,
>when functionality of currency exchange is thought about.
>
>Merchant viewpoint
>
>1) The merchant may have fixed price in one currency only and give prices
>in other currencies based on current exchange rate. (logic: offer cheap
>exchange service). 
>>>
It is merchant decision to decied how prices in different currencies are
calculated. However it is done, OTP allows a merchants to list as many
currencies/amounts as they want.
<<<
>
>2) The Merchant may have fixed prices in some currencies (logic: easy for
>Customers in that area, supports advertisement campaign, requirement from
>the manufacturer). In that case, the prices, taking into consideration the
>ever changing exchange rates, are not the same.
>>>
See response to item 1
<<<
>
>3) The bill may cover purchases over a period of time, so that exchange
>rates may change.
>>>
This is currently not in Baseline OTP as it supports a single purchase
of goods or services at a point in time.
<<<
>
>4) The price of some products may depend on Payment Method (e.g. special
>discount with Acme Card). 
>>>
Baseline OTP supports this by linking brands to payment methods and
currencies/prices
<<<
>
>Customer viewpoint. The customer may have some Payment methods and wants to
>minimize and control the cost.  
>
>a) (Related to 2) Customer should be able to select any of the announced
>prices of a certain product.
>>>
OTP supports this
<<<
>
>b) (Related to 3 and 2) Customer should be able to decide the payment
>method for each of the purchases (or several chopping carts might be needed)
>>> Customer can select payment method for a single purchase. If multiple
payment methods are required then, in Baseline OTP, separate
purchases (shopping carts are needed)
<<<
>
>c) (Related to 4 and possible purchases in multiple currencies) The bill
>should contain the price of each Item also in the charging currency of the
>payment method.
>>>
The format and content of the Bill (in OTP the Order Description) is
completely under the control of the Merchant. So this requirement can be
met if the Merchant wants to
<<<
>
>d) (Related to c and the need to control cost) Often, it is more acceptable
>to have the price of each of the items rounded to the nearest penny and sum
>those up for total charge than hide some decimals for more exact total
>charge.
>>>
Two points here:
*	as for the previous point, the Merchant decides the content of the
Order Description
*	OTP allows amounts to be stated in fractions of a penny. How this is
handled is dependent on the Payment Method which should set rules, e.g.
(fractions are an error, round the figure to the neares penny or
truncate the fractions). This would be defined in the payment supplement
for the payment method.
<<<
>
>Hannu
>
>-----------------------------------------------------------------------
>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]
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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]'" <[email-masked]>,  'Terry Allen' <[email-masked]>
Subject: RE: OTP baseline deposit - what is offered?
Date: Wed, 2 Sep 1998 18:44:15 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Terry raises two points:
*	on the Baseline Deposit, and
*	on the use of the ShortDesc attribute in the Protocol Options
Component

Each is discussed below.

BASELINE DEPOSIT
In outline the Order Description would contain information about the
amount deposited and the account to be credited. Let's compare the real
world and OTP to see why.

If you think what typically happens in the real world when somebody
deposits cash:
*	the customer fills in a slip at the bank stating the account they want
credited and the amount they are depositing,
*	the customer hands over the slip and the cash to the cashier
*	the cashier makes whatever entries are necessary in manual or computer
systems, and finally
*	the cashier returns typically the stub of the slip with a bank "stamp"
as a receipt
*	the customer checks the receipt is stamped by the bank and is for the
correct amount [:-)] and goes on their way

One of the important things for the customer is that they have a receipt
which:
*	records the amount deposited and the account being credited,
*	is signed by the bank,
*	proves the deposit occurred, and
*	they can use to prove after the event to resolve problems

Now if we consider what happens in OTP:
*	the Order Description in the Offer Response would contain information
on the amount deposited and the account being credited
*	the signature on the Payment Receipt by the Bank (or its Payment
Handler) would bind the Offer Response (and hence the Order Description)
to the actual payment and is equivalent to the "stamp" on the slip
*	using a Customer Care Transaction (in a later version of OTP), the
customer could later use the Payment Receipt to resolve problems.

The main difference between OTP and the real world is that the Bank,
rather than the customer fills out the slip. This is because *in the
baseline version of OTP* the customer cannot fill out the slip herself
and send it to the Bank. If we wanted to do this then we, or some other
standards developer, would have to define the structure of the deposit
slip (Order Description) in a way which was universally and globally
acceptable to all banks which is not easy and I would suggest is a job
for perhaps the appropriate Banking subgroup in an organisation like
ISO.

So I think the current approach should allow sufficient flexibility so
that any bank could potentially use it for deposits for any electronic
cash scheme.

PROTOCOL OPTIONS COMPONENT - use of ShortDesc attribute

Terry has spotted a mistake. 

In an earlier version of OTP the OtpTransType attribute (now in the
Transaction ID Component) was in the Protocol Options Component. However
when the attribute was moved, the introduction to the Protocol Options
Component wasn't changed.

I suggest the introduction should now read:

"Protocol Options contains information and data which the Consumer needs
to carry out the transactionm including:
*	a description of the transaction being carried out in the Consumer's
native language, and
*	a list of Net Locations which can be used depending on the success or
failure of the transaction"

On second thoughts the use of the Protocol Options component has changed
so much that we perhaps we ought to rename it. How about "Consumer Data"
? Thoughts?

Regards

David

>----------
>From: 	Terry Allen[SMTP:[email-masked]]
>Sent: 	01 September 1998 22:48
>To: 	[email-masked]
>Subject: 	OTP baseline deposit - what is offered?
>
>
>For an OTP baseline deposit (7.2), what is the Offer?  the
>workflow diagram in fig 20 shows the consumer transmitting
>apparently all the necessary information before the OTP
>transaction gets started, and (after authentication, which
>is certainly desireable to avoid denial of service attacks
>from noncustomers evilly attempting to deposit minuscule
>amounts of e-cash...) the financial institution sending 
>an Offer Response (rather than an Offer).  Did the consumer
>make an Offer, or is there no Offer here?  In the
>OfferRespBlk, would the optional Order element be used,
>and what might it contain?
>
>I think this is really a question about how to characterize
>the exchange of value between bank and customer.  If the
>bank doesn't charge the customer a service charge (or if
>the service charge is calculated on some other basis than
>per-deposit), what is the bank giving the customer?  I've
>wondered about this for awhile.  The best I can come up with
>is that the bank provides (aside from notice of successful
>deposit) a credit to the customer's account, which, however,
>is never itself delivered to the customer because it's an
>entry on the bank's books.  Does that make sense here?
>
>Unrelated, for baseline, ProtocolOptions (5.1) is supposed
>to name one of the baseline transactions.  would that be
>in the ShortDesc attribute?
>
>regards, Terry
>
>
>Terry Allen                             Veo Systems, Inc.
>Business Language Designer              4005 Miranda Ave., no. 150	
>(Common Business Language - CBL)        Palo Alto, Calif.,  94034
>tallen[at]sonic.net			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]
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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: Wed, 02 Sep 1998 12:34:19 +0300
To: "[email-masked]'" <[email-masked]>
From: Hannu Nikkanen <[email-masked]>
Subject: RE: I have a comment for Spec. 5.4.1(Order Description)
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Hi,

find below a few points about currency exchange, which might be considered,
when functionality of currency exchange is thought about.

Merchant viewpoint

1) The merchant may have fixed price in one currency only and give prices
in other currencies based on current exchange rate. (logic: offer cheap
exchange service). 

2) The Merchant may have fixed prices in some currencies (logic: easy for
Customers in that area, supports advertisement campaign, requirement from
the manufacturer). In that case, the prices, taking into consideration the
ever changing exchange rates, are not the same.

3) The bill may cover purchases over a period of time, so that exchange
rates may change.

4) The price of some products may depend on Payment Method (e.g. special
discount with Acme Card). 

Customer viewpoint. The customer may have some Payment methods and wants to
minimize and control the cost.  

a) (Related to 2) Customer should be able to select any of the announced
prices of a certain product.

b) (Related to 3 and 2) Customer should be able to decide the payment
method for each of the purchases (or several chopping carts might be needed)

c) (Related to 4 and possible purchases in multiple currencies) The bill
should contain the price of each Item also in the charging currency of the
payment method.

d) (Related to c and the need to control cost) Often, it is more acceptable
to have the price of each of the items rounded to the nearest penny and sum
those up for total charge than hide some decimals for more exact total charge.

Hannu

-----------------------------------------------------------------------
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]>,  "'Smith, C. (Chris)'" <[email-masked]>
Subject: RE: I have a comment for Spec. 5.4.1(Order Description)
Date: Wed, 2 Sep 1998 00:12:27 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Chris Smith said ...
>>>
     I concur strongly with the 'display brand list amount' 
     recommendation. This is the equivalent of the Mondex requirement
for 
     a similar function, and in the Interac debit system (Canadian)
where 
     the PINpad displays the amount, as part of a confirmation, even 
     though the consumer knew the amount before they selected Interac as
     the payment mechanism. It seems to work quite well in these areas.
<<<

This made me also think that we need to distinguish between:
*	the amount and currency on the Brand list which is equivalent to what
the Merchant displays on the till and is used by the Consumer to
determine how much to pay, and
*	the amount and currency displayed by the payment system (e.g. Mondex,
Interac or other debit terminals) which shows the amount which the
payment system thinks is actually being paid and which the Consumer is
asked to confirm

This email (and also Sam Hartman's very recent email) also leads to the
following questions:
*	we're suggesting we specify (perhaps mandate?) the behaviour of the
client or server system which handle the OTP protocol e.g. wrt to
displaying and confirmation of payment information. We're not just
specifying the protocol itself. Should we be doing this?
*	if we do want to specify this constraint as part of the protocol, how
do we enforce it ...

David Burdett

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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: Werner Hans <[email-masked]>
To: [email-masked]
Date: Tue, 1 Sep 1998 19:22:50 +0000
Subject: Payment API 0.9.8
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

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

The version 0.9.8 of the Payment API should
conform with the OTP Specification 0.9.9 and might be
published on the OTP website.

It considers the following payment related activities:
- brand compilation at the merchant,
- brand selection at the consumer, and
- payment.

Furthermore, several topics have been adjusted.
Most notable:
- authentication and
- error notification and processing.

However, the architecture part is not changed.

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

--Message-Boundary-7277
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:  otparc98.zip
     Date:  23 Aug 1998, 14:20
     Size:  725486 bytes.
     Type:  ZIP-archive

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

--Message-Boundary-7277--
-----------------------------------------------------------------------
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: "Richard D. Brown" <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: 'David Burdett' <[email-masked]>,  'Yoshiaki KAWATSURA' <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: RE: I have a comment for Spec. 5.4.1(Order Description)
Date: Tue, 1 Sep 1998 18:30:02 -0500
Organization: GlobeSet, inc.
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,

Since I've always argued that currency negotiation should have happened 
before an invoice (Order in OTP terminology) is tendered to the Buyer, I 
like the second option better. However, when I mean Order, I actually mean 
the Order component and not the XML package that is used for the Order 
Description. In fact, I prefer the way it used to be - with the amount 
being displayed in the Order component - but we have rejected this approach 
in order to enable single-trip dialog while proposing multiple currencies 
and/or multiple brands.

Though trying to save a round-trip between the Buyer and the Seller makes 
some (or a lot of  :-)) sense, this may render the trade dialog a bit 
inconsistent. My feeling is that this kind of shortcut will be adopted at 
first (as few payment options exist), but will be necessarily abandonned as 
the system will mature. Support for multiple payment instruments will 
require in most circumstances an additional round-trip ...

Sincerely,

Richard D. Brown

On Tuesday, September 01, 1998 11:34 AM, David Burdett 
[SMTP:[email-masked]] wrote:
> I'm in two minds about this:
> *	on the one hand, allowing the Order Description to also include an
> amount field provides an easy way to display information about the price
> and goods ordered together to the Consumer. This also has the advantage
> that it conforms with the guidelines for SET and anyway, we can't
> actually stop Merchants putting in price information if they want to,
> *	on the other hand putting price information in the Order Description
> as well as the Brand List means that the price appears twice in the OTP
> message which presents an opportunity for it to be inconsistent (either
> accidentally or deliberately), and it is *always* the Brand List price
> which is used to determine the actual amount which is paid and *not* the
> price in the order description which is what the Consumer sees.
>
> The ideal solution would be to have the price defined once only, in the
> Order Description, we could do this by using some sort of escape
> sequence to identify the text which describes the currency code and
> price from within the Order Description. However, this becomes more
> difficult once a Merchant starts accepting multiple currencies and it is
> not clear which currencies apply.
>
> This makes me think that we should make a strong recommendation that
> solutions which implement OTP should *always* display the amount in the
> Brand List to the Consumer for review. Another alternative for Merchant
> would be to do a Brand Dependent Purchase where the selected Brand and
> Currency is sent back to the Merchant who then provides an Order
> Description containing the Currency selected. Although this involves an
> additional round trip.
>
> What do other people think?
>
> David
>
> >----------
> >From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> >Sent: 	29 August 1998 15:58
> >To: 	[email-masked]
> >Cc: 	[email-masked]
> >Subject: 	I have a comment for Spec. 5.4.1(Order Description)
> >
> >I forward my comment for OTP Spec 0.99.
> >David was agreed, but he suggested this mail is forwarded to trade-ML.
> >
> >-- Forward
> >I have one comment for the OTP Specification 0.99.
> >
> >5.4.1 Order Description Content
> >"This description of the order in the Packaged Content
> > should not include currency and amount information since this is
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > contained in the payment related trading components."
> >
> >I suggest the above description should be deleted.
> >This restriction is too strong.
> >
> >The amount information in BrandList is machine readable but the amount
> >information in Order Description may be used as human readability. (Of
> >course, the amount information in BrandList can be used for human
> >readability though.)
> >
> >Actually, SET allows to include the amount information in Order
> >Description, s.t. SET allows to have the amount information twice,
> >because the element PurchAmt also exists.
> >
> >-- Backward
> >
> >----
> >Yoshiaki Kawatsura : E-mail [email-masked]
> > Business & Information Systems Development Devision, Hitachi,Ltd.
> > Voice: +81-45-948-1418(direct) Fax: +81-45-948-1421
> >-----------------------------------------------------------------------
> >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]
> >
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> Mondex International Limited
> 47-53 Cannon Street, London  EC4M 5SQ
> England
> Registered No: 3122085, England
>
> Telephone No: +44 (0)171 557 5000
> Web Site: http://www.mondex.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: 'Yoshiaki KAWATSURA' <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: RE: I have a comment for Spec. 5.4.1(Order Description)
Date: Tue, 1 Sep 1998 17:34:02 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I'm in two minds about this:
*	on the one hand, allowing the Order Description to also include an
amount field provides an easy way to display information about the price
and goods ordered together to the Consumer. This also has the advantage
that it conforms with the guidelines for SET and anyway, we can't
actually stop Merchants putting in price information if they want to,
*	on the other hand putting price information in the Order Description
as well as the Brand List means that the price appears twice in the OTP
message which presents an opportunity for it to be inconsistent (either
accidentally or deliberately), and it is *always* the Brand List price
which is used to determine the actual amount which is paid and *not* the
price in the order description which is what the Consumer sees.

The ideal solution would be to have the price defined once only, in the
Order Description, we could do this by using some sort of escape
sequence to identify the text which describes the currency code and
price from within the Order Description. However, this becomes more
difficult once a Merchant starts accepting multiple currencies and it is
not clear which currencies apply.

This makes me think that we should make a strong recommendation that
solutions which implement OTP should *always* display the amount in the
Brand List to the Consumer for review. Another alternative for Merchant
would be to do a Brand Dependent Purchase where the selected Brand and
Currency is sent back to the Merchant who then provides an Order
Description containing the Currency selected. Although this involves an
additional round trip.

What do other people think?

David

>----------
>From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
>Sent: 	29 August 1998 15:58
>To: 	[email-masked]
>Cc: 	[email-masked]
>Subject: 	I have a comment for Spec. 5.4.1(Order Description)
>
>I forward my comment for OTP Spec 0.99.
>David was agreed, but he suggested this mail is forwarded to trade-ML.
>
>-- Forward
>I have one comment for the OTP Specification 0.99.
>
>5.4.1 Order Description Content
>"This description of the order in the Packaged Content 
> should not include currency and amount information since this is 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^      
> contained in the payment related trading components."
>
>I suggest the above description should be deleted.
>This restriction is too strong.
>
>The amount information in BrandList is machine readable but the amount
>information in Order Description may be used as human readability. (Of
>course, the amount information in BrandList can be used for human
>readability though.) 
>
>Actually, SET allows to include the amount information in Order
>Description, s.t. SET allows to have the amount information twice,
>because the element PurchAmt also exists.
>
>-- Backward
>
>----
>Yoshiaki Kawatsura : E-mail [email-masked]
> Business & Information Systems Development Devision, Hitachi,Ltd.
> Voice: +81-45-948-1418(direct) Fax: +81-45-948-1421
>-----------------------------------------------------------------------
>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]
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.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, C. (Chris)" <[email-masked]>
To: David Burdett <[email-masked]>, [email-masked]
Subject: RE: I have a comment for Spec. 5.4.1(Order Description)
Date: Tue, 1 Sep 1998 14:58:00 -0400 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

     What do other people think?
     
     David
     
Chris Smith>>>
        Replies below...
_________________________ Reply Separator _________________________________
Subject: RE: I have a comment for Spec. 5.4.1(Order Description)
Author:  "David Burdett" [SMTP:[email-masked]] at Internet
Date:    1998-09-01 12:34

I'm in two minds about this:
     
The ideal solution would be to have the price defined once only, in the 
Order Description, we could do this by using some sort of escape 
sequence to identify the text which describes the currency code and 
price from within the Order Description. However, this becomes more 
difficult once a Merchant starts accepting multiple currencies and it is 
not clear which currencies apply.

Chris Smith>>>
     This is (in part) what some people expect the namespaces area to 
     resolve. A 'purchase amount' field could be included inside whatever 
     XML structures are used in the order description.
     
     There are two difficulties: (1) the order description should really be 
     formatted in XML for this to work, and (2) there is still no way that 
     I see to include a namespaced field and imply that it is BOTH the 
     'order price' and the 'payment amount'. It can be one or the other, 
     but not both!
     
This makes me think that we should make a strong recommendation that 
solutions which implement OTP should *always* display the amount in the 
Brand List to the Consumer for review. Another alternative for Merchant 
would be to do a Brand Dependent Purchase where the selected Brand and 
Currency is sent back to the Merchant who then provides an Order 
Description containing the Currency selected. Although this involves an 
additional round trip.

Chris Smith>>>
     I concur strongly with the 'display brand list amount' 
     recommendation. This is the equivalent of the Mondex requirement for 
     a similar function, and in the Interac debit system (Canadian) where 
     the PINpad displays the amount, as part of a confirmation, even 
     though the consumer knew the amount before they selected Interac as 
     the payment mechanism. It seems to work quite well in these areas.
     
-----------------------------------------------------------------------
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, 1 Sep 1998 14:48:52 -0700
From: Terry Allen <[email-masked]>
To: [email-masked]
Subject: OTP baseline deposit - what is offered?
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

For an OTP baseline deposit (7.2), what is the Offer?  the
workflow diagram in fig 20 shows the consumer transmitting
apparently all the necessary information before the OTP
transaction gets started, and (after authentication, which
is certainly desireable to avoid denial of service attacks
from noncustomers evilly attempting to deposit minuscule
amounts of e-cash...) the financial institution sending 
an Offer Response (rather than an Offer).  Did the consumer
make an Offer, or is there no Offer here?  In the
OfferRespBlk, would the optional Order element be used,
and what might it contain?

I think this is really a question about how to characterize
the exchange of value between bank and customer.  If the
bank doesn't charge the customer a service charge (or if
the service charge is calculated on some other basis than
per-deposit), what is the bank giving the customer?  I've
wondered about this for awhile.  The best I can come up with
is that the bank provides (aside from notice of successful
deposit) a credit to the customer's account, which, however,
is never itself delivered to the customer because it's an
entry on the bank's books.  Does that make sense here?

Unrelated, for baseline, ProtocolOptions (5.1) is supposed
to name one of the baseline transactions.  would that be
in the ShortDesc attribute?

regards, Terry

Terry Allen                             Veo Systems, Inc.
Business Language Designer              4005 Miranda Ave., no. 150	
(Common Business Language - CBL)        Palo Alto, Calif.,  94034
tallen[at]sonic.net			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: David Burdett <[email-masked]>
Cc: 'Yoshiaki KAWATSURA' <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: Re: I have a comment for Spec. 5.4.1(Order Description)
From: Sam Hartman <[email-masked]>
Date: 01 Sep 1998 13:50:04 -0500
Lines: 5
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I think that OTP should require implementations to display the price
from the brand info---I.E. conformant implementations MUST display the
price that is actually being charged.  If you do anything else, you
potentially mislead the consumer.

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