Subject: RE: Spec Changes from IOTP Workshop at CyberCash Reston, 9-11 September 1998

From: Andrew Drapp <[email-masked]>
Date: Thu, 17 Sep 1998 20:05:40 +0900

> 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

---

From: David Burdett <[email-masked]>
Date: Wed, 23 Sep 1998 08:33:24 +0100

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
>>     might need an additional component such as a "Payment Note" component.
>

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

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]>
Date: Wed, 23 Sep 1998 08:33:26 +0100

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

---

From: David Burdett <[email-masked]>
Date: Thu, 24 Sep 1998 13:48:58 +0100

Is that clearer? ... Yes

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

David

>Sent: 	24 September 1998 11:00
>To: 	[email-masked]
>Cc: 	David Burdett; [email-masked]; [email-masked]
>I revised some points of Andrew's comment. See below, please
>
>----
>Yoshiaki Kawatsura : E-mail [email-masked]
>>>>>> Thu, 24 Sep 1998 14:16:42 +0900,
>	Andrew Drapp <[email-masked]> said:
>
>Yoshiaki wrote:
>To which David Responded:
>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]
>1099 Ozenji, Asao, Kawasaki, 215-0014 JAPAN
>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]'