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

Andras Varga <andras@metechnology.com> Wed, 16 August 2000 16:23 UTC

Return-Path: <ietf-trade-errors@lists.eListX.com>
Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-33 #43584) id <0FZE00G0187U0D@eListX.com>; Wed, 16 Aug 2000 12:23:54 -0400 (EDT)
Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-33 #43584) id <0FZE00G0187U0C@eListX.com> (original mail from andras@metechnology.com) ; Wed, 16 Aug 2000 12:23:54 -0400 (EDT)
Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-33 #43584) id <0FZE00G0387T0A@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822; ietf-trade@lists.elistx.com); Wed, 16 Aug 2000 12:23:53 -0400 (EDT)
Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-33 #43584) id <0FZE00G0187S09@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822; ietf-trade@lists.elistx.com); Wed, 16 Aug 2000 12:23:52 -0400 (EDT)
Received: from mail.elender.hu (bendeguz.elender.hu [212.108.200.75]) by eListX.com (PMDF V5.2-33 #43584) with ESMTP id <0FZE00F1S87RTS@eListX.com> for ietf-trade@lists.eListX.com; Wed, 16 Aug 2000 12:23:52 -0400 (EDT)
Received: from apps (mail.metechnology.hu [212.108.229.233]) by mail.elender.hu with ESMTP id SAA24901 for <ietf-trade@lists.elistx.com>; Wed, 16 Aug 2000 18:21:16 +0200 (MET DST)
Received: from 10.0.0.11 by apps ([10.0.0.1] running VPOP3) with SMTP for <ietf-trade@lists.elistx.com>; Wed, 16 Aug 2000 17:43:34 +0200
Date: Wed, 16 Aug 2000 17:48:29 +0200
From: Andras Varga <andras@metechnology.com>
Subject: RE: Draft new TRADE WG Charter, two week comment period
In-reply-to: <642F9A357902D411BA5F0008C79197562591AE@ma07exm1.corp.isg.mot.com>
To: ietf-trade@lists.eListX.com
Reply-to: andras@metechnology.com
Message-id: <000901c00799$6cefcee0$0b00000a@andras>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2014.211
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 8bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Server: VPOP3 V1.3.0b - Registered to: Me Technology
List-Owner: <mailto:ietf-trade-help@lists.elistx.com>
List-Post: <mailto:ietf-trade@lists.elistx.com>
List-Subscribe: <mailto:ietf-trade-request@lists.elistx.com?body=subscribe>
List-Unsubscribe: <mailto:ietf-trade-request@lists.elistx.com?body=unsubscribe>
List-Archive: <http://lists.elistx.com/archives/ietf-trade>
List-Help: <http://lists.elistx.com/doc/email-manage.html>, <mailto:ietf-trade-request@lists.elistx.com?body=help>

Donald Eastlake wrote:
[...]
> 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

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: andras.varga@brokat.com |  Commerce Division
Phone: +36-1 437-0413           |  Research & Development
Fax:   +36-1 387-3798           |  Kunigunda útja 58.
http://www.brokat.com           |  1037 Budapest, Hungary