Subject: 9 Sept. SET/OTP Design Subgroup Meeting Minutes

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Sun, 27 Sep 1998 16:57:52 -0400

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