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

From: David Burdett <[email-masked]>
Date: Thu, 17 Sep 1998 10:25:08 +0100

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

---

From: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 17 Sep 1998 20:07:03 +0900 (JST)

David,
My comment is below(included the another issue.)
>>>>> Thu, 17 Sep 1998 10:25:08 +0100,
> (potentially including Pay Scheme Components) which together make up 

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: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 17 Sep 1998 20:37:05 +0900 (JST)

David,

----

---

From: Surendra Reddy <[email-masked]>
Date: Thu, 17 Sep 1998 06:36:38 +0100

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
> 
> during the Trade WG Workshop held at CyberCash in Reston VA o 
> 9-11 September. It contains:
> * 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
> ---------------------
> 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 :
> b)	a new ElRef attribute, that contains references to other 
> Components (potentially including Pay Scheme Components) which 
> together make up the receipt. Note that:
> 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"
> 
> 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."
> 
> 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.
> 
> 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.
> 
> US Advanced Technology Office: 111 Pine St, 6th Floor, San 
> Francisco, CA 94111