Subject: Draft new TRADE WG Charter, two week comment period

From: Eastlake Donald-LDE008 <[email-masked]>
Date: Thu, 10 Aug 2000 21:51:27 -0400

Hi,

Here is the draft charter that was presented in Pittsburgh with some minor
edits.  I would like to send this in to our Area Director soon.  Please try
to get any comments or suggestions to me or posted to the list within two
weeks.

Thanks,
Donald

Chair: Donald Eastlake 3rd <[email-masked]>
Applications Area Advisor: Patrik Faltstrom

Mailing Lists:
	General Discussion:[email-masked] 
	To Subscribe: [email-masked]
	In Body: (un)subscribe
	Archive: http://www.eListX.com/archives/ietf-trade 

The Internet Open Trading Protocol is an interoperable framework
for Internet commerce. It is optimized for the case where the
buyer and the merchant do not have a prior acquaintance and is
payment system independent. It can encapsulate and support payment
systems such as SET, Mondex, secure channel card payment,
GeldKarte, etc. IOTP is able to handle cases where such merchant
roles as the shopping site, the payment handler, the deliverer of
goods or services, and the provider of customer support are
performed by different Internet sites.

The working group will document interoperability experience with
IOTP version 1 (which has been published as an Informational RFC)
and develop the requirements for IOTP version 2. Selection of
items for inclusion in version requirements 2 is to be from the
following: 
 - Separation of a content independent Messaging Layer 
 - Dynamic Definition of Trading Sequences 
 - Offer Request Block 
 - Improved Problem Resolution (extend to cover presentation of
 	signed receipt to customer support party, etc.)
 - Server to Server messages
 - Standardized XML Digital Signatures based on output from
 	the XMLDSIG working group
 
The following is out of scope for IOTP version 2:
 - legal or regulatory issues surrounding the implementation of
 	the protocol or information systems using it.
 - specification of an XML Messaging Layer

The working group will specify requirements for Digital-Rights
Trading.

The working group will specify requirements for and then a syntax
and processing model of ECML (Electronic Commerce Modeling
Language) V2.

Milestones

00 Sep  Internet Draft publication
	Secure Channel Credit/Debit

00 Sep  Working Group Last Call
	SET Supplement
	Architecture and Payment API
	
00 Oct  Submit to IESG
	SET Supplement (Informational)
	Architecture and Payment API (Informational)

00 Nov  Internet Draft publication
	IOTP V2.0 Requirements
	ECML V2.0 Requirements

00 Nov  Submit to IESG
	Secure Channel Credit/Debit (Proposed Standard?)
	"Digital Rights" Trading Requirements (Informational)

00 Dec  Internet Draft publication
	IOTP V2.0 Specification
	ECML V2.0 Specification

00 Dec  Submit to IESG
	ECML V2.0 Requirements (Informational)

01 Jan  Submit to IESG
	IOTP V2.0 Requirements (Informational)

01 Feb  Submit to IESG
	ECML V2.0 Specification (Proposed Standard)

01 Mar  Submit to IESG
	IOTP V2.0 Specification  (Proposed Standard)

---

From: Ko Fujimura <[email-masked]>
Date: Tue, 15 Aug 2000 20:34:01 +0900

Eastlake Donald-LDE008 wrote:
...
>         the XMLDSIG working group

Coordination between IOTP and ECML may be an item should be considered.
I think that IOTP version 2 should specify the position of ECML version 2.
How do you think? 

> The working group will specify requirements for Digital-Rights

I'm sorry for not resolving the issue of the document title.
How about "Requirements for Generic Rights Trading"?

Regards,

Ko Fujimura

---

From: Andras Varga <[email-masked]>
Date: Wed, 16 Aug 2000 17:48:29 +0200

Donald Eastlake wrote:
[...]
>  	the XMLDSIG working group

I'd like to suggest two more items for inclusion:

1) issues concerning server-side IOTP wallets (or IOTP-enabled WalletServers).

When using server-side wallets which reside in a WalletServer,
a typical scenario is this:
 1. consumer browses in the Merchant's shop and decides to check out
 2. consumer clicks on the "Pay" link in the shop. The URL points
    to the WalletServer and contains additional parameters like
    e.g. merchant address and order number
 3. consumer logs into the WalletServer
 4. the WalletServer retrieves the Offer from the Merchant;
    data for this (e.g. OfferRequest URL) come from parameters
    from the URL used to invoke the WalletServer
 5. now payment & delivery goes on like the Consumer had
    a locally installed IOTP wallet

An item which would be worth standardizing is the URL used to
invoke the WalletServer. (Using such an URL to get to the
WalletServer has certain advantages over using e.g. a mime-type
sent down from the shop.)

This URL should include parameters which -at minimum- tell
the WalletServer where to send the OfferRequest.

2) mixing IOTP with other payment protocols.

Some existing payment protocols like SET or Geldkarte
are pretty difficult to tunnel through IOTP (bridges require
significant implementation effort). At the same time
it would be nice to be able to use IOTP e.g. for retrieving
offer or requesting delivery, which is not (properly) covered
by other protocols. Such a feature would probably increase
the usefulness and thus the acceptance of the IOTP standard.

The IOTP specification should explicitly allow for payment
protocols that are not tunnelled through IOTP. There should
be a way to specify protocols in the IOTP OfferResponse
that are to be used standalone with Merchant's Payment Handler
(ie. not tunnelled through IOTP).

Other modifications might also be necessary on the IOTP protocol
to accomodate such a feature, for example signed PayReceipt
is not possible if the payment was not done via IOTP.

Best regards,
  Andras Varga

----------------------------------------------------------
Andras Varga                    |  Brokat Ag.
E-mail: [email-masked] |  Commerce Division
Phone: +36-1 437-0413           |  Research & Development
Fax:   +36-1 387-3798           |  Kunigunda útja 58.
http://www.brokat.com           |  1037 Budapest, Hungary

---

From: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 24 Aug 2000 18:02:15 +0900 (JST)

>>>>> Tue, 15 Aug 2000 20:34:01 +0900,

> I think that IOTP version 2 should specify the position of ECML version 2.

I agree with you. I think we can simplify the current specification by
collaborating with other related protocols such as ECML.

Additionally we should separate the specification document of IOTP
after it has reflected the implimentation result because the current
specification is too big and hard to progress IOTP.

----
Yoshiaki Kawatsura : E-mail [email-masked]
 Business Solution Systems Development Division, Hitachi,Ltd.
Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721