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.
Note: Since working drafts are subject to frequent change, you are
advised to reference the above URL, rather than the URLs for working drafts
themselves.
This work is part of the
W3C
Micropayment Activity
Note: Text with yellow background was last
modified
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 wallet to coexist
in a interoperable manner.
Currently, there is no clear definition of a "Web micropayment" that encompasses
all systems claiming to be micropayment systems.
Though disparate, they all share the goal of minimizing the cost overhead
of a single transaction.
Micropayments provide an alternative source of revenues beyond advertising
and subscriptions for content providers (initially text and pictures, presumably
later multimedia streams). They may also provide revenue streams for service
providers (database lookup, proxy services etc.).
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 Web pages 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.
One requirement common to all micropayment system is to attach payment information to transaction(e.g. pricing), be they based on :
Today, a merchant willing to support multiple payment system needs to embed
in Web page all these specific payment information, using for each system
proprietary encodings .
These proprietary encodings introduce redundancy of information and over
work for Merchant to author Web pages.
The need for a common markup to support multiple payment system is crucial.
Today all the above systems are all in various stages between final design,
pilots and early adopter phase.
Therefore, specifying a common markup for multiple payment system will
not bother the market, while no huge installed base is to migrate. This 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 :
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 specifies requirements for interoperability among micropayment systems.
Requirements for embedding micropayment information in Web pages are :
The following key words are used throughout the document and should be read
as interoperability requirements. The words are used as defined in RFC2119
[KEY] for defining the significance of each particular
requirement.
These words are:
MUST
This word or the adjective "required" means that the item is an absolute
requirement of the specification.
SHOULD
This word or the adjective "recommended" means that there may exist valid
reasons in particular circumstances to ignore this item, but the full
implications should be understood and the case carefully weighed before choosing
a different course for an implementation.
MAY
This word or the adjective "optional" means that this item is truly optional.
One merchant may choose to include the item because a particular micropayment
system requires it.
An implementation is not compliant and interoperable with any other micropayment system if it fails to satisfy one or more of the MUST requirements it implements.
All the following parameters MUST be provided for conformance.
Name : merchantID
Type: URI.
Definition: This parameter identifies the merchant site where the purchase
is to occur.
These two parameters buyurl and buycode are mandatory .
Name : buyurl
Type: URI.
Definition: This parameter identifies what the client is buying. It does
not mention the site of the merchant.
Name : buycode
Type: Character string.
Definition: This parameter allows a code naming a product code designation.
Name : requesturl
Type: URI.
Definition: This parameter identifies what the client is actually requesting.
It does not mention the site of the merchant.
requesturl can be identical to the buyurl parameter. But
it can be different if for example the client bought a collection
of pages, he can request only one of these pages, and in this case
buyurl is larger than requesturl parameter.
One of these two parameters textlink and imagelink is mandatory ; a text and/or an image MUST be provided.
Name : textlink
Type: Character string.
Definition: This parameter specifies the linked text to be displayed to the
Custumer.
Name : imagelink
Type: URI.
Definition: This parameter identifies the linked image to be displayed
to the Custumer.
When linking an image with the imagelink parameter, an image alternative text MUST be provided to insure accessibility.
Name : imagealt
Type: Character string.
Definition: This parameter describes the linked image for accessibility.
A price must be provided by the merchant in order to be displayed to the
Custumer.
Name : price
Type: Character string.
Definition: This parameter MUST include amount and currency, encoded as character
strings consisting of a number followed by a currency code :
Name : text
Type: Character string
Definition: This parameter describes content of what the client is buying
for display.
Name : duration
Type: Integer. This number is a quantity of minutes.
Definition: This parameter indicates the time after purchase any URI can
be retrieved with payment.
Name : expiration
Type: Date.
Definition: This parameter indicates a date until which the offer from the
merchant is valid. After this given date offer is out of date.
The current specification uses one of the formats described in the profile
[DATETIME] for its definition of legal date/time
strings. The date format is as follows, the components shown here must be
present, with exactly this punctuation.
Complete date plus hours, minutes and seconds:
YYYY-MM-DDThh:mm:ssTZD (e.g. 1999-07-16T19:20:30+01:00)
where:
YYYY = four-digit year
MM = two-digit month (01=January, etc.) DD = two-digit day of month (01 through 31) hh = two digits of hour (00 through 23) (am/pm NOT allowed) mm = two digits of minute (00 through 59) ss = two digits of second (00 through 59) TZD = time zone designator (Z or +hh:mm or -hh:mm)
Note that the "T" appears literally in the string, to indicate the beginning of the time element, as specified in ISO 8601.
This profile defines two ways of handling time zone offsets:
For coexistence issues among the different payment systems, there is a need for a specific field to handle each payment specific information.
Name : URI identifying uniquely the payment system
name
Type: Character string.
Definition: This specific field specifies the payment system name, identified
by a URI and provides all the required information needed by this payment
system.
Due to Requirements expressed above, embedding micropayment information has to be compliant to all browsers.
We will cite as example embedding using Resource Description Framework [RDF] for RDF compliant browsers and embedding using Plug in or JAVA Applet for current non-RDF-aware browsers.
All requested information needed to start micropayment must be present in
the HTML page sent from the merchant server.
For [RDF] non compliant Browser, embedding information
in HTML pages can be done using a Per Fee Link Handler possibly a Plug
in or JAVA Applet.
In order to allows the Per Fee Link Handler to process these 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 can use the
<APPLET> or <EMBED> element.
In general, authors should use the <OBJECT> element.
HTML 4.0 introduces the <OBJECT> element, which allows 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>" is used to describe 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>>
Attribute definitions:
classid = URL
This attribute may be used to specify the location of an <OBJECT>'s
implementation via a URL. It may be used together with, or as an alternative
to the data attribute, depending on the type of <OBJECT> involved.
codetype = content-type
This attribute specifies the content type of data expected when downloading
the <OBJECT> specified by classid. This attribute is optional but
recommended when classid is specified since it allows the user agent to avoid
loading information for unsupported content types.
PARAM elements within <OBJECT> element will be used to pass named
parameters required by the <OBJECT> at run-time.
name = applet parameter name
value = parameter value
For User agents that do not support the <OBJECT> element and for reasons of backward compatibility, authors can use the APPLET element.
HTML 3.2 has introduces 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>
Attribute definitions:
codebase = codebaseURL
This optional attribute specifies the base URL of the applet -- the directory
or folder that contains the applet's code. If this attribute is not specified,
then the document's URL is used.
code = appletFile
This required attribute specifies the name of the file that contains the
applet's compiled Applet subclass. This file is relative to the base URL
of the applet. It cannot be absolute.
archive = uri-list
It is a new attribute introduced in JDK1.1 Its value is a comma seperated
list of archives containing classes and other resources.
The classes in the archives are preloaded relative to the applet's codebase.
It allows to load a signed (trusted) code like a PFLH for instance.
PARAM elements within APPLET element will be used to pass named parameters
required by the applet at run-time. Applets read user-specified values for
parameters with the get Parameter() method.
name = applet parameter name
value = parameter value
For User agents that do not support the <OBJECT> element and for reasons of backward compatibility, authors can use EMBED element.
This EMBED element, supported by all Plugin-enabled browsers, allows designers
to embed a Plugin in an HTML document.
EMBED
element is not a standard HTML element, it was introduced by Netscape.
HTML 4.0 introduces the
<OBJECT>
element to replace this element.
<EMBED SRC="http://www.miamachina.org/applet/micropayment.class" duration="60">
A Per Fee Link that needs a plugin for rendering.
</EMBED>
Optional parameters within EMBED element will be used to pass required information by the plugin 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 plugin.
The Per Fee Link Handler (PFLH) functionalities will be addressed in a specific Working Draft.
The merchantID data field :
for <OBJECT> and APPLET element : <PARAM name="merchantID" value="http://www.merchant.org/shop" valuetype="ref">
for EMBED element :
merchantID="http://www.merchant.org/shop"
The ClientBuy data field :
for <OBJECT> and APPLET element :
<PARAM name="buyurl" value="catalog.html" valuetype="ref"> <PARAM name="buycode" value="a254df10" valuetype="data">
for EMBED element :
buyurl="catalog.html" buycode="a254df10"
The ClientRequest data field :
for <OBJECT> and APPLET element :
<PARAM name="requesturl" value="page.html" valuetype="ref">
for EMBED element :
requesturl="page.html"
The Textlink and imagelink data field
:
for <OBJECT> and APPLET element :
<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 element :
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 element :
<PARAM name="price" value="0.01USD" valuetype="data"> statement for one cent of a US dollar.
price="1E-2FRF" statement for one cent of a french franc.
The Text data field :
for <OBJECT> and APPLET element :
<PARAM name="text" value="this is what you are actually buying" valuetype="data">
for EMBED element :
text="this is what you are actually buying"
The Duration data field
for <OBJECT> and APPLET element :
<PARAM name="duration" value="60" valuetype="data">
for EMBED element :
duration="60"
The Expiration date data field :
for <OBJECT> and APPLET element :
<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> element :
expiration="1999-11-05T13:15:30Z" corresponds to the same instant as above.
The Specific data field :
for <OBJECT> and <APPLET> element :
<PARAM name="http://www.foo.it/micropay1" value="xxxxxxxxxxxxxxxxxx" valuetype="data">
<PARAM name="http://www.foo.it/micropay2" value="yyyyyyyyyyyyyyyyyy" valuetype="data">
for <EMBED> element :
P1-name="http://www.foo.it/micropay1"
P1-value="xxxxxxxxxxxxxxxxxx"
P2-name="http://www.foo.it/micropay2"
P2-value="yyyyyyyyyyyyyyyyyy"
5.b.1 Benefits with RDF encoding :
For RDF compliant browsers, micropayment information can be embedded in HTML
pages using RDF.
Micropayment information are statements that are properly expressed according
to the Resource Description Framework
(RDF) Model and Syntax
Specification, now a W3C Recommendation.
The arguments for using RDF as data format for micropayments result obviously
from the generic benefits of RDF.
In particular, they are :
The information for micropayments can therewith become part of the World Wide Web itself, through being meta-data.
5.b.2 RDF Transport:
In order to fully exploit these benefits, it is suggested that the necessary parameters for micropayments are encoded in RDF and shipped by either or more of the following ways:
These parameters can then be read by a standard RDF engine and passed on to the API to the electronic wallet (to be defined by the Micropayments API Working Draft).
The recommended technique for embedding RDF expressions in an HTML document is simply to insert the RDF in-line. This will make the resulting document non-conformant to HTML specifications up to and including HTML 4.0 but the W3C expects that the HTML specification will evolve to support this.
Note: Transition to full integration :
In order to transit from the existing software population of the Web to one
where micropayments and RDF are day-to-day data formats, an interim
implementation should be foreseen. An interim implementation can be provided
through a proxy until the API is available from the browser directly.
Therefore API Working Draft should consider the assumption of a browser API
in the future.
5.b.2 Same Example (5.a.5) as above of Fee Link using RDF encoding :
Linking text to a fee Web page :
The Fee Link is specified with the <A> element the from
HTML 4.0.
The textlink parameter is in this case the
content of the <A> element.
The ID attribute is used to assign a unique identifier to the
<A> element and the HREF attribute is used to provide the
source anchor.
<BODY> <A href="http://www.miamachina.org/page.html" id="myfeelink"> Buy the page through this link</A> </BODY>
Following RDF statements describing this Fee link are mentioned in the <HEAD> section of the HTML document as following:
<HEAD>
<rdf:RDF xmlns:rdf="http://www.w3.org/TR/REC-rdf-syntax#" xmlns:rdfs="http://www.w3.org/TR/PR-rdf-schema#" xmlns:mp="http://www.w3.org/schema/micropay#"> <rdf:Description about="#myfeelink"> <mp:Price>1E-2FRF</mp:Price> <mp:merchantID ressource="http://www.merchant.org/shop"/> <mp:buyurl ressource="catalog.html"/> <mp:buycode>a254df10</mp:buycode> <mp:requesturl ressource="page.html"/> <mp:text>this is what you are actually buying</mp:text>
<mp:duration>60</mp:duration> <mp:expiration>1999-11-05T13:15:30Z</mp:expiration> <mp:Paymentsystem> <rdf:Alt> <rdf:li> <mp:Paymentoption system="http://www.foo.it/micropay1" value="xxxxxxxxxxxxxxxxxx"/> </rdf:li> <rdf:li> <mp:Paymentoption system="http://www.foo.it/micropay2" value="yyyyyyyyyyyyyyyyyy"/> </rdf:li> </rdf:Alt> </mp:Paymentsystem> </rdf:Description> </rdf:RDF> </HEAD>
If these RDF statements were embedded into an HTML document then the default behavior of a non-RDF-aware browser would display the values of the properties.
To distinguish this Fee link from a free link, Cascading Style Sheets
[CSS1] can be used to add a particular layout to this
fee link.
e.g.
This fee link
is enclosed into a green box
<HEAD>
<STYLE TYPE="text/css">
#myfeelink { border-width: 1 ; background: green}
</STYLE>
</HEAD>
<BODY>
<A href="http://www.miamachina.org/page.html" id="myfeelink">
Buy the page through this fee link</A>
</BODY>
</HTML>
Note : A user personal Style Sheet may override this given Fee link layout.
Linking an image to a fee Web page :
The Fee Link is specified using the <A> and the <IMG> element from HTML 4.0.
The imagelink parameter is the value of
the SRC attribute element.
The imagealt parameter is the value of the
ALT attribute element.
<BODY> <A href="http://www.miamachina.org/page.html">
<IMG src="http://www.merchant.org/product.gif"
alt="description of the image" </A> </BODY>
The RDF statements describing this image Fee link are mentioned in the <HEAD> of the HTML document, same as mentioned above.
5.c.1 The Embedding of micropayment information in XML will be addressed soon.
5.c.2 Same Example (5.a.5) as above of Fee Link using XML encoding :
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE micropayment SYSTEM "/XML/micropayment.dtd">
..........
This specification was prepared and approved for publication by the W3C Micropayment Markup Working Group (WG). WG approval of this specification does not necessarily imply that all WG members voted for its approval. The current and former members of the Micropayment Markup WG are:
Amir Herzberg, IBM (Co-Chair); Mark Manase, Compaq (Co-Chair); Jean Claudes Pailles, France Telecom ; Thierry Michel, W3C (Editor); Phillipe Michon, France Telecom; Jon Ziegler, Sun; Liza Ezrol,citibank.