Alternative to the Common Markup for Web Micropayment Systems sp ecification

The XML based "Intenet Open Trading Protocol" (IOTP) is an alternative
approach to the "Common Markup for Web Micropayment Systems" specification
(available at http://www.w3.org/TR/WD-Micropayment-Markup).

IOTP is being developed under the auspices of the IETF Trade Working Group.
Copies of the specifications can be downloaded from:

*	http://internet-drafts/draft-ietf-trade-iotp-v1.0-protocol-03.txt -
Internet Open Trading Protocol - IOTP Version 1.0 (the main specification)
(567kb)
*	http://internet-drafts/draft-ietf-trade-iotp-http-01.txt -  Internet
Open Trading Protocol (IOTP) HTTP Supplement (13kb)
*	http://internet-drafts/draft-ietf-trade-iotp-v1.0-dsig-00.txt -
Digital Signatures for the Internet Open Trading Protocol (38kb)
*	ftp://ftp.pothole.com/pub/ietf-trade/iotp-v1.0-protocol-03.dtd -
IOTP v 1.0 XML Data Type Definition (19kb)
*	ftp://ftp.pothole.com/pub/ietf-trade/iotpar101current.zip - IOTP
architecture document (includes payment API) (863kb)

As can be seen from the above specification list, IOTP already includes a
fully defined XML DTD and a payment API which are planned future work
products of the W3C Electronic Commerce group. 

Moreover, IOTP was designed to be used in a simple way to support
micropayments. Specifically:
*	use of digital signatures, although fully specified, is entirely
optional. Therefore their cost can be avoided when they are not justified -
such as for micropayments. In this sense IOTP can provide a good "ratio of
security cost to protected value" 
*	IOTP can work in a way where no additional messages are sent over
the net above those required for the payment protocol. This is as minimal as
you can get and lends itself to the situations where micropayments are
likely to be used.

In addition development projects are underway for IOTP to be used for
several micropayment systems and pilots including: Mondex, GeldKarte
(Germany) and NTT Cash (Japan) as well as projects to support more complex
payment protocols such as SET.

I honestly believe that we, as developers of internet standards should not
develop two alternative standards for micropayments on the net without
looking, very closely to see if they can converge. In my personal view, I
think it would be a good idea if the IETF and W3C worked jointly on how
micropayments on the net should operate. There is already a precedence for
joint IETF/W3C working in the work that is being done on digital signatures
for XML.

I would appreciate that any reply to this email is also copied to the IETF
Trade WG at ietf-trade@elistx.com. Archives of this mailing list are
available at http://www.elistx.com/archives/ietf-trade/ and you can
subscribe to the list by sending an email with "subscribe" in the body to:
ietf-trade-request@lists.elistx.com.

Regards

David Burdett
PS Below are some more detailed comments on the w3C specification as it
currently stands.

DETAILED COMMENTS ON CURRENT SPECIFICATION
1. Some payment methods, e.g. Mondex, require multiple exchange of messages
between the consumer and merchant. It is not clear how this type of payment
method would be supported. Is it assumed that this would be managed by the
underlying payment wallet?

2. How is the security of the payment managed? You need to make sure that it
is hard for a payment to be made by a consumer unless it is authorized by
the consumer and that appropriate levels of privacy are considered. Security
and privacy of the payment does seem to be covered by the specification in
its current form.

3. How are errors handled?  Ideally any problems should be handled
gracefully, especially for the consumer, with the opportunity for real bugs
in the system to be properly recorded and identified and so more easily
fixed. What happens if, for example:
*	the same request is received twice
*	there is an error in the request, what should the client (or server)
do?
*	the consumer is expecting a payment request but none arrives?

4. Once a payment has been made, how does the merchant get informed that
payment is complete and therefore delivery of the digital (or other goods)
should occur? I could not see how this is covered.

5. There is a need to support multiple currencies (e.g. Deutschmarks and
Euros, or US and Canadian Dollars) otherwise a merchant's opportunity to
sell will be restricted.

6. There is a need to support multiple versions of payment protocols (be
they micropayment or not). I don't think the current specification supports
this without the consumer knowing which version of the payment protocol they
are using and selecting the correct one. This is not "user friendly".

7. As far as I can see, there is no facility to provide the consumer with a
list of payment brand logos which is the way consumers select the payment
method to use in the real world.

PLEASE NOTE THAT THIS EMAIL IS DESIGNED FOR UNLIMITED AND UNRESTRICTED
DISTRIBUTION.

> mailto:<david.burdett@mondex.com>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> 

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

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 postmaster@mondex.com 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:          postmaster@mondex.com
WebSite:        http://www.mondexinternational.com

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

Received on Monday, 3 May 1999 15:51:32 UTC