Copyright © 1999 W3C
(MIT,
INRIA,
Keio), All Rights Reserved. W3C
liability,
trademark,
document
use and
software
licensing rules apply.
This specification provides an extensible way to embed in a Web page all the information necessary to initialize a micropayment (amounts and currencies, payment systems, etc). This embedding allows different micropayment electronic wallets to coexist in a interoperable manner.
The
Micropayment
Markup Working Group (W3C Members only), with this 1999 March 15 first
working draft, invites comment on our specification for "Common Markup for
Web Micropayment Systems".
This Working Group is part of the
Micropayment task within
the ECommerce Activity.
The W3C Membership and other interested parties are invited to review this public specification and report implementation experience. Please send comments to the publicly archived list www-micropay-comments@w3.org (public archive).
While we welcome implementation experience reports, the Micropayment Markup Working Group will not allow early implementation to constrain its ability to make changes to this specification prior to final release.
In the current document, open issues remain : Embedding micropayment information using RDF and encoding with XML. Before this specification is submitted as a Proposed Recommendation, all open issues will be resolved.
This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C working drafts can be found at http://www.w3.org/TR.
Micropayments provide an alternative revenue source for content providers (initially of text and pictures, presumably multimedia later on) beyond advertising and subscriptions. Micropayments may also provide revenue streams for service providers (database lookup, proxy services etc.).
Currently, there is no clear definition of a "Web micropayment" that encompasses all systems claiming to be micropayment systems. However, these systems all share the goal of minimizing the cost overhead of a single transaction. Most of these micropayment systems try to save costs, both monetary (bank and transactions) and network (packet round trips). To do so, systems embed vital information in hyperlinks, using proprietary encodings.
This document proposes an extensible and interoperable way to embed in a Web page all the information necessary to initialize a micropayment.
Several types of payment systems exist on the Web today:
All these types of systems share a common requirement: the ability to attach payment information to transaction (e.g., pricing).
Today, a merchant willing to support multiple payment systems needs to embed in each Web page payment information specific to each target system, using a proprietary encoding for each one. Proprietary encodings introduce redundancy of information and extra work for Web page authors. This situation obviates the need for a common markup supported by multiple payment systems.
As the systems listed above are all in various stages between final design, pilots and early adoption phase, it is crucial to specify the common markup as quickly as possible (to not disturb the market and before a large base would need to migrate to a new format). Rapid market development is likely to close this window of opportunity by the end of the year 2000 with the growth of the installed user base.
Obviously, the time for developing a common markup supporting multiple payment system appears well chosen.
Micropayment usually involves three parties, a customer C who makes the payment, a Merchant M who receives the payment and a broker B who keeps accounts for the parties concerned.
This document will mainly consider the two parties Customer (Client) C and Merchant (Server) M, as they are the only ones to be involved in the initialization of a micropayment.
Parties involved in this specification architecture are Client and Merchant.
The Client initiates the micropayment when requesting information from the server.
The basic architecture consist of:
[1] Merchant HTTP Server to Per Fee Link Handler flow
[2] Per Fee Link Handler to Wallet and Wallet to Per Fee Link Handler flows
This document focuses on the Merchant server to Per Fee Link Handler-Browser flow and specifies the payment markup information.
This document does not handle:
Note. The API from Per Fee Link Handler (PFLH) to Wallet will be addressed in another specific API Working Draft. The PFLH functionalities will also be addressed in another specific PFLH Working Draft.
This document section specifies requirements for interoperability among micropayment systems.
Requirements for embedding micropayment information in Web pages are:
The words "MUST" (or "required"), "SHOULD" (or "recommended"), and "MAY" (or "optional") are used throughout the document and should be read as interoperability requirements. The words are used as defined in RFC2119 [RFC2119] for defining the significance of each particular requirement.
An implementation conforms to this specification if it satisfies all of the normative statements ("MUST" or "required") in this document.
All the following parameters MUST be provided for conformance: merchantID, buyurl, buycode, requesturl, one of textlink or imagelink plus imagealt, price, longdesc, duration, and expiration.
In addition, there may be information that a specific payment system requires.
The merchantID parameter, which takes a URI, identifies the merchant site where the purchase is to occur.
The buyurl parameter, which takes a URI, identifies what the client is buying. It does not mention the site of the merchant.
The buycode parameter, which takes a character string, allows a code naming a product code designation.
Both parameters MUST be supplied.
The requesturl parameter, which takes a URI,
identifies what the client is actually requesting. It does not mention the
site of the merchant.
This parameter may be identical to the buyurl parameter. It may
be different if, for example, the client has purchased a collection of pages
and requests only one of these pages. In this case, buyurl is larger
than requesturl parameter.
The textlink parameter, which takes a character string, specifies the linked text to be displayed to the Customer.
The imagelink parameter, which takes a URI, identifies the linked image to be displayed to the Customer. When using this parameter, the imagealt parameter MUST also be used. This parameter, which takes a character string, provides a textual equivalent for the image and is necessary for accessibility.
One of these two parameters textlink and/or imagelink is mandatory ; a text and/or an image link MUST be provided to Customer.
The price parameter, which takes a character string, displays the amount and currency to the Customer. The character string MUST be encoded as an amount followed by a currency unit as follows:
The Longdesc parameter, which takes a character string, describes in details the content of what the client is buying and is intended for display.
The duration parameter, which takes an integer number of minutes, indicates the time after purchase any URI can be retrieved with payment.
The expiration parameter, which takes a date, indicates a date until which the offer from the merchant is valid. After this given date offer is out of date.
The value of this parameter, a date/time string, MUST use the following format as described in [DATETIME]:
YYYY-MM-DDThh:mm:ssTZD
This format includes the complete date (YYYY-MM-DD) separated from the time (T), which must include hours (hh), minutes (mm), seconds (ss) and a time zone designator (TZD). An example of such a string is "1999-07-16T19:20:30+01:00" Please consult [DATETIME] for the meaning of each field.
To insure coexistence among the different payment systems, a specific field provides each payment specific information.
When specific payment system requires additional information, a URI MUST be used to refer to a unique payment system name. Additional specific information are provided with a character string.
Due to Requirements expressed above, embedding micropayment information must work with all browsers.
All requested information needed to start micropayment must be present in
the HTML page sent from the merchant server.
For current Browser, embedding information in HTML pages can be done using
a Per Fee Link Handler, which may be a plug-in or JAVA Applet.
In order to allow the Per Fee Link Handler to process this information, it will be stored in an OBJECT element.
For user agents that do not support the OBJECT element, and for reasons of backward compatibility, authors may use the APPLET or EMBED element. Note. The APPLET element is deprecated in HTML 4.0 and should be avoided. The EMBED element is not part of a W3C Recommendation and should be avoided. Authors should use the OBJECT element.
HTML 4.0 introduced the OBJECT element ([HTML40], section 13.3) to allow HTML authors to specify everything required by an object for its presentation by a user agent: source code, initial values, and run-time data. The term "object" refers to applets, plug-ins, media handlers, etc.
<OBJECT codetype="application/java"
classid="http://www.miamachina.org/applet/micropayment.class">
<PARAM name="duration" value="60" valuetype="data">
A Per Fee Link that needs an applet for rendering
</<OBJECT>
The HTML 4.0 specification defines the attributes of the OBJECT element.
The "classid" attribute specifies the location of the OBJECT's implementation
with a URL.
The "codetype" attribute specifies the content type of data to expect when
downloading the OBJECT.
The PARAM element within an OBJECT element specifies values to give to the
object at run-time (as name/value pairs).
For user agents that do not support the OBJECT element and for reasons of backward compatibility, authors may use the APPLET element. HTML 3.2 ([HTML32]) introduced the APPLET element to allow designers to embed a Java applet in an HTML document. It is supported by all Java-enabled browsers, but has been deprecated in HTML 4.0 in favor of the OBJECT element.
<APPLET codebase="http://www.miamachina.org/applet/"
code="micropayment.class"
archive="myclasses.jar,myaudio.jar">
<PARAM name="duration" value="60" valuetype="data">
A Per Fee Link that needs an applet for rendering.
</APPLET>
The HTML 4.0 specification ([HTML40], section 13.4)
defines the attributes of the (deprecated) APPLET element.
The "codebase" attribute specifies the base URL for the applet.
The "code" attribute specifies either the name of the class file that contains
the applet's compiled applet subclass or the path to get the class.
The "archive" attribute specifies a comma-separated list of URIs designated
resources to preload such as signed (trusted) code such as a Per Fee Link
Handler.
The PARAM element within an APPLET element specifies values to give to the
object at run-time (as name/value pairs).
For user agents that do not support the OBJECT element and for reasons of
backward compatibility, authors MAY use EMBED element.
Note. Whenever the OBJECT element can be used, authors SHOULD avoid
EMBED because it is not defined by a W3C Recommendation.
This EMBED element, supported by all plug-in-enabled browsers, allows designers to embed a plug-in in an HTML document.
<EMBED src="http://www.miamachina.org/MicropaymentPlugin.exe"
duration="60">
A Per Fee Link that needs a plug-in for rendering.
</EMBED>
Optional parameters within EMBED element will be used to pass required information by the plug-in at run-time.
PARAMETER_NAME=PARAMETER_VALUE
The PFL Handler is a module that can either be a plug-in or a Java Applet.
It could be implemented in Java 1.2 allowing signed JAVA applets in browsers
supporting it, and otherwise as a plug-in.
The Per Fee Link Handler (PFLH) functionalities will be addressed in a specific Working Draft.
The merchantID data field:
For OBJECT and APPLET:
<PARAM name="merchantID" value="http://www.merchant.org/shop" valuetype="ref">
For EMBED:
merchantID="http://www.merchant.org/shop"
The ClientBuy data field:
For OBJECT and APPLET:
<PARAM name="buyurl" value="catalog.html" valuetype="ref"> <PARAM name="buycode" value="a254df10" valuetype="data">
For EMBED:
buyurl="catalog.html"
buycode="a254df10"
The ClientRequest data field:
For OBJECT and APPLET:
<PARAM name="requesturl" value="page.html" valuetype="ref">
For EMBED:
requesturl="page.html"
The textlink and
imagelink data fields :
For OBJECT and APPLET:
<PARAM name="textlink" value="click here to by the product" valuetype="data"> <PARAM name="imagelink" value="http://www.merchant.org/product.gif" valuetype="ref"> <PARAM name="imagealt" value="text description of the image" valuetype="data">
For EMBED:
textlink="click here to by the product" imagelink="http://www.merchant.org/product.gif" imagealt="text description of the image"
The Price data field:
For OBJECT and APPLET:
<PARAM name="price" value="+0.01USD" valuetype="data"> statement for one cent of a US Dollar.
For EMBED:
price="+1E-2FRF" statement for one cent of a French Franc.
The Longdesc data field:
For OBJECT and APPLET:
<PARAM name="longdesc" value="Description of what you are actually buying" valuetype="data">
For EMBED:
longdesc="Description of what you are actually buying"
The Duration data field
For OBJECT and APPLET:
<PARAM name="duration" value="60" valuetype="data">
For EMBED:
duration="60"
The Expiration date data field:
For OBJECT and APPLET:
<PARAM name="expiration" value="1999-11-05T08:15:30-05:00 " valuetype="data"> corresponds to November 5, 1999, 8:15:30 am, US Eastern Standard Time.
For EMBED:
expiration="1999-11-05T13:15:30Z" corresponds to the same instant as above.
For data fields specific to a micropayment system:
For OBJECT and APPLET:
<PARAM name="http://www.foo.it/micropay1" value="xxxxxxxxxxxxxxxxxx" valuetype="data">
<PARAM name="http://www.foo.it/micropay2" value="yyyyyyyyyyyyyyyyyy" valuetype="data">
For EMBED:
P1-name="http://www.foo.it/micropay1"
P1-value="xxxxxxxxxxxxxxxxxx"
P2-name="http://www.foo.it/micropay2"
P2-value="yyyyyyyyyyyyyyyyyy"
<HTML>
<HEAD> <TITLE>Example of embedded Fee Link for an Java Applet PFLH</TITLE>
</HEAD> <BODY> <OBJECT codetype="application/java" classid="http://www.miamachina.org/applet/micropayment.class"> <PARAM name="merchantID" value="http://www.merchant.org/shop" valuetype="ref"> <PARAM name="buyurl" value="catalog.html" valuetype="ref"> <PARAM name="buycode" value="a254df10" valuetype="data"> <PARAM name="requesturl" value="page.html" valuetype="ref"> <PARAM name="textlink" value="click here to by the product"
valuetype="data"> <PARAM name="price" value="+0.01USD" valuetype="data">
<PARAM name="longdesc" value="Description of what you are actually buying"
valuetype="data"> <PARAM name="duration" value="60" valuetype="data"> <PARAM name="expiration" value="1999-11-05T08:15:30-05:00 "
valuetype="data">
<PARAM name="http://www.foo.it/micropay1" value="xxxxxxxxxxxxxxxxxx"
valuetype="data">
<PARAM name="http://www.foo.it/micropay2" value="yyyyyyyyyyyyyyyyyy"
valuetype="data"> </OBJECT> </BODY></HTML>
5.2.a The Embedding using RDF
[An RDF encoding of the micropayment information is under design within the
Working Group.
Members may refer to the
Micropayment Markup Working
Group home page for status.]
5.3.a The Embedding of micropayment information in XML
[Under construction]
The current and former members of the Micropayment Markup Working Group are:
Amir Herzberg, Chair (IBM); Anat Sarig, (IBM); Mark Manase, (Compaq); Thierry Michel, Editor (W3C); Jean Claudes Pailles (France Telecom); Phillipe Michon (France Telecom); Jon Ziegler (Sun); Liza Ezrol (Citibank).
Last updated: $Date: 1999/03/15 18:42:16 $