Subject: RE: PayReceiptRefs (Problem of IOTP Spec.)

From: David Burdett <[email-masked]>
Date: Tue, 11 May 1999 14:23:06 +0100

Yoshiaki

I have read it and it's on my list of things to do. Unfortunately I didn't
have the time last week and this week I'm at CardTech Securtech all week in
Chicago. I hope to respond to you next week. Hope this is OK.

David

> ----------
> From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> Sent: 	10 May 1999 00:24
> To: 	[email-masked]
> Cc: 	[email-masked]; [email-masked]
> Subject: 	Re: PayReceiptRefs (Problem of IOTP Spec.)
> 
> David,
> I sent the following mail two weeks ago. Did you have a chance to read it?
> Please let me know some comments for my proposal.
> 
> Thanks,
> --
> Yoshiaki Kawatsura
> 
> --
> There is a problem for PayReceiptRefs in PayReceipt component in the
> current IOTP specification.
> 
> Problem:
> In the current specification, we can not use the PayReceiptRefs.  IOTP
> Payment Bridge of the Payment Handler can not set the PayReceiptRefs
> because the Bridge can not know IOTP Component ID.  IOTP Payment Bridge
> of the Consumer can not also get the components correspond to IDs
> which is included in the PayReceiptRefs.
> 
> So I suggest the following changes.
>  
> Change:
> (a) Change PayReceiptRefs to PayReceiptRefNames element.
>     (PayReceiptRefs is dropped)
> (b) PayReceiptRefNames defines as the list of Name element in
>     PackagedContent of PaySchemeData component.
> (c) The Name element in PackagedContent must be unique in the transaction.
> (d) The PaySchemeData Component, that Name element is the same ones 
> in the token of PayReceiptRefNames, must be hashed and signed in the
> Payment
> Response signature component.
> 
> Sequence of Process:
> (1) The Payment Hander Payment Bridge set the PayReceiptRefNames.
> (2) Payment Handler OAC hashes and signs to the corresponding
> PaySchemeData.
> (3) Consumer OAC checks the signatures.
> (4) OAC picks up the PackagedContents which include the same Name
>     element in PayReceiptRefNames and passes them to the Payment Bridge as
>     PayReceiptPackagedContent in the CheckPayReceipt.
> 
> What do you think this?
> 
> 
> 

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

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

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

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

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

---

From: David Burdett <[email-masked]>
Date: Tue, 18 May 1999 02:16:57 +0100

Yoshiaki

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. The DTD for the PaymentReceipt and PaymentSchemeData components become
...
<!-- PAYMENT SCHEME COMPONENT -->
<!ELEMENT PaySchemeData (PackagedContent+) >
<!ATTLIST PaySchemeData
 ID                 ID      #REQUIRED
 PaymentRef         NMTOKEN #REQUIRED <<<<<NEW
 ConsumerPaymentId  CDATA   #IMPLIED
 PaymentHandlerPayId CDATA  #IMPLIED
 ContentSoftwareId  CDATA   #IMPLIED >

<!-- PAYMENT RECEIPT COMPONENT -->
<!ELEMENT PayReceipt (PackagedContent+) >
<!ATTLIST PayReceipt
 ID                 ID      #REQUIRED
 PaymentRef         NMTOKEN #REQUIRED
 PayReceiptNameRefs NMTOKENS #IMPLIED <<<<CHANGED
 ContentSoftwareId  CDATA   #IMPLIED >

Any questions let me know.

David

> Sent: 	02 May 1999 08:30
> Subject: 	PayReceiptRefs (Problem of IOTP Spec.)
> 
> P.S. I can not response till 9th May because I will go to Thai Land in
> vacation.
>  
> Thanks,
> --
> Yoshiaki Kawatsura
> 

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200

---

From: David Burdett <[email-masked]>
Date: Wed, 26 May 1999 00:01:40 +0100

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

So  your change as described below will be made.

David

> Sent: 	25 May 1999 00:27
> To: 	[email-masked]
> Cc: 	[email-masked]
> Subject: 	RE: PayReceiptRefs (Problem of IOTP Spec.)
> 
> David,
> 
> I believe some payment methods would use only the PayReceiptNameRefs
> in the PayReceipt Component as the payment receipt, so that
> PackagedContents does not need to be used.
>  
> Thus, would you change the PayReceipt Component as follows? :
>  
> From:
> To:
> <!ELEMENT PayReceipt (PackagedContent*) >
> 
> And we also should add the description saying that "At least the
> PackagedContent or PayReceiptNameRefs has to exist in the
> PayReceipt Component."
>  
>   What do you think about?
>  
>  
> >>>>> Tue, 18 May 1999 02:16:57 +0100,
> 	David Burdett <[email-masked]> said:
> 
> > Yoshiaki
> > 
> > > From: 	Yoshiaki KAWATSURA[SMTP:@bisd.hitachi.co.jp]
> > > Sent: 	02 May 1999 08:30
> > > Cc: 	[email-masked]; @bisd.hitachi.co.jp
> ----
> Yoshiaki Kawatsura : E-mail [email-masked]
>  Business & Information Systems Development Devision, Hitachi,Ltd.
> Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
> 

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200