Identify privacy and security guidelines that merchants and technology companies can
optionally employ to make e-commerce safer for both consumers and merchants.

This document does not define schema or address privacy/security issues associated with
other sensitive data (e.g. medical information, social security number, etc). In
addition, this document does not define ECML -- ECML was developed separately by the
members of the ECML consortium.

This document is a NOTE made available by W3C for discussion only. This work does not
imply endorsement by, or the consensus of, either W3C membership or members of the P3P
Working Groups, nor that W3C has, is, or will be allocating any resources to the issues
addressed by the NOTE. This document is a work in progress and may be updated,
replaced, or rendered obsolete by other documents at any time.

A list of current W3C technical documents can be found at the Technical Reports page.

Background

Internet users and site owners are adopting E-commerce at a rapid pace. A survey
from Odyssey found that 47% of all Internet users completed an online purchase during the
second half of 19983. A more recent survey from Greenfield Online determined that the number
of shoppers increased to 71% of all online users during the second quarter of 19994.
Looking at the numbers from another perspective, Forrester Research forecasts the
US consumer e-commerce marketplace to reach $18 billion in 19995. Yet the
majority of consumers still aren't shopping online, and those that do don't do so very
often.

Forrester estimates that 66% of online shoppers stop short of paying for what they
accumulate in Internet shopping carts. Of the remaining 34% of users that continue
past the shopping cart, Jupiter predicts that 27% of them abandon the order before
completing the checkout form.

These statistics led to the following conclusion in a joint study by Boston Consulting
Group and Shop.org:

While many consumers are visiting online retailers, few are buying. The study
argues that online retailers need to improve convenience and value for consumers and
assist them in overcoming their fears around security.6

Simply put, online shopping is too hard. This is caused by many factors, but one
of the biggest problems is the necessity for users to constantly re-enter the same payment
information (e.g. shipping address, billing address, payment instrument) over and over for
every transaction. Repeatedly entering twenty or more fields for each transaction is
tedious, error prone, and a barrier to market growth.

In addition to the inconvenience of online shopping, the other major barrier to
e-commerce is consumers' lack of trust. A research paper by Hoffman, et al from
Vanderbilt University found:

At its core, the reason online consumers have yet to shop online in large numbers,
or even provide information to Web providers in exchange for access to information offered
onsite, is because of the fundamental lack of faith that currently exists between most
businesses and consumers on the Web today. In essence, consumers simply do not trust most
Web providers enough to engage in relationship exchanges with them.7

This lack of trust is due in large part to the sensitive nature of the data being
collected. It encompasses both physical security (e.g. is the data encrypted when
stored and transferred over the Internet?) and user privacy (e.g. who has access to my
data and will they sell my information to third parties without my knowledge?).

Convenience and Trust -- both need to be improved before e-commerce can
reach its full potential. Fortunately, solutions are starting to emerge.

Digital wallets greatly increase the convenience of online shopping by eliminating the
need to constantly re-enter payment information every time a purchase is made. Users
simply store their payment information once and then send it to the merchant with a click
of the mouse. Unfortunately, adoption of digital wallets has been slow due to lack
of a standard. ECML partially addresses this problem by defining a standard schema
for payment data. A standard schema enables wallets to operate seamlessly across
many different merchant sites, regardless of the wallet vendor.

P3P addresses the trust issue by defining a standard vocabulary and syntax for
expressing privacy preferences for data exchanged between end-user and web site.
This allows users to more easily understand how their data will be used by the web site
owner. Unfortunately, P3P does not currently include a schema for e-commerce data.
In order to build a P3P-compliant digital wallet, we first must define a P3P schema
for ecommerce data.

Incorporating ECML into P3P is a natural choice -- the combination enables convenient
and trusted e-commerce.

E-Commerce Schema

We define two e-commerce schemas for P3P. The first schema is completely
compatible with ECML version 1.0. The
second schema builds on top of the ECML-based schema by adding additional elements not
currently found in ECML 1.0.

Two schemas are presented because we feel it necessary to define a completely compliant
ECML 1.0 schema while at the same time providing an enhanced schema with additional
features, such as receipts, transaction details for user budgeting, fraud control
purposes, and alternative payment instruments. The authors intend to work to
incorporate these additional data elements into a future version of ECML.

Schema 1: An ECML 1.0 Compliant Schema for P3P

As part of developing a standard for the trusted exchange of information between users
and businesses, the W3C's P3P working group has already defined a schema for commonly
required profile attributes -- the P3P
Base Data Set. This schema includes many of the core data attributes needed for
e-commerce, including postal address, name, and date, but it is not sufficient for online
shopping. For instance, it lacks attributes for a payment instrument (e.g. credit
card), shipping address, and billing address.

ECML on the other hand, defines a payment schema sufficient for online commerce.
ECML is a new industry standard payment schema endorsed by many leading technology
companies including Microsoft, IBM, AOL, Dell, FSTC, Mastercard, Visa, Discover, and
American Express. Refer to http://www.ecml.org for
more information on ECML.

Fortunately, due to the authors' participation in both ECML and P3P, ECML was designed
from the beginning to be consistent with the P3P base data set.

The ECML schema is defined as follows:

Attribute Name

Notes

Ecom_ConsumerOrderID

A unique order ID generated by the consumer software.

Ecom_SchemaVersion

URI indicating version of this set of fields. Usually a hidden
field. Equal to "http://www.ecml.org/version/1.0" for this version.

Ecom_TransactionComplete

A flag to indicate that this web-page/aggregate is the final one
for this transaction. Usually a hidden field.

Payment Component

Payment Instrument

Ecom_Payment_Card_Name

The name of the cardholder.

Ecom_Payment_Card_Type

Use the first 4 letters of the association name: American
Express=AMER; Diners Club=DINE; Discover=DISC; JCB=JCB; Mastercard=MAST; Visa=VISA.

Ecom_Payment_Card_Number

Includes the check digit at end but no spaces or hyphens [ISO
7812]. The Min given, 19, is the longest number permitted under the standard.

Ecom_Payment_Card_Verification

An additional cardholder verification number printed on the card
(but not embossed or recorded on the magnetic stripe) such as American Express' CIV,
MasterCard's CVC2, and Visa's CVV2 values.

A space separated list of protocols available in connection with
the specified card. Initial list of case insensitive tokens: none, set, & setcert.
"Set" indicates usable with SET protocol (i.e., is in a SET wallet) but does not
have a SET certificate. "Setcert" indicates same but does have a set
certificate. "None" indicates that automatic field fill is operating but there
is no SET wallet or the card is not entered in any SET wallet.

ShipTo Component

Address to which the
purchased product or service is to be sent.

Ecom_ShipTo_Postal_Name_Prefix

For example: Mr., Mrs., Ms., 3rd. This field is commonly not used.

Ecom_ShipTo_Postal_Name_First

Ecom_ShipTo_Postal_Name_Middle

May also be used for middle initial

Ecom_ShipTo_Postal_Name_Last

Ecom_ShipTo_Postal_Name_Suffix

For example: Ph.D., Jr. (Junior), Esq. (Esquire). This field is
commonly not used.

Ecom_ShipTo_Postal_Street_Line1

Address lines must be filled in the order line1, then line2, last
line3.

Ecom_ShipTo_Postal_Street_Line2

Address lines must be filled in the order line1, then line2, last
line3.

Ecom_ShipTo_Postal_Street_Line3

Address lines must be filled in the order line1, then line2, last
line3.

Ecom_ShipTo_Postal_City

Ecom_ShipTo_Postal_StateProv

2 characters are the minimum for the US and Canada, other countries
may require longer fields. For the US use 2 character US Postal state abbreviation.

Ecom_ShipTo_Postal_PostalCode

Minimum field lengths for Postal Code will vary based on
international market served. Use 5 character or 5+4 ZIP for the US and 6 character postal
code for Canada. The size given, 14, is believed to be the maximum required anywhere in
the world.

10 digits are the minimum for numbers local to the North American
Numbering Plan (US, Canada and a number of smaller Caribbean and Pacific nations (but not
Cuba)), other countries may require longer fields. Telephone numbers are complicated by
differing international access codes, variant punctuation of area/city codes within
countries, confusion caused by the fact that the international access code in the NANP
region is usually the same as the "country code" for that area (1), etc. It will
probably be necessary to use heuristics or human examination based on the telephone number
and addresses given to figure out how to actually call a customer. It is recommend that an
"x" be placed before extension numbers.

Address to which a purchase receipt should be
sent, if different from billing address

Ecom_ReceiptTo_Postal_Name_Prefix

See BillTo

Ecom_ReceiptTo_Postal_Name_First

"
"

Ecom_ReceiptTo_Postal_Name_Middle

"
"

Ecom_ReceiptTo_Postal_Name_Last

"
"

Ecom_ReceiptTo_Postal_Name_Suffix

"
"

Ecom_ReceiptTo_Postal_Street_Line1

"
"

Ecom_ReceiptTo_Postal_Street_Line2

"
"

Ecom_ReceiptTo_Postal_Street_Line3

"
"

Ecom_ReceiptTo_Postal_City

"
"

Ecom_ReceiptTo_Postal_StateProv

"
"

Ecom_ReceiptTo_Postal_PostalCode

"
"

Ecom_ReceiptTo_Postal_CountryCode

"
"

Ecom_ReceiptTo_Telecom_Phone_Number

"
"

Ecom_ReceiptTo_Online_Email

"
"

The compatibility of ECML with the P3P base data set can be clearly seen in the Ecom_ShipTo, Ecom_BillTo, and Ecom_ReceiptTo attributes, which are essentially instances of P3P's Contact data type. Furthermore, while not formally specified,
the Ecom_Payment_Card_ExpDate is an instance of the P3P Date data type.

ECML also has a hierarchical structure consistent with the hierarchy of the P3P base
data set. The gray italicized rows in the table above separate the major top level
components of ECML. The underscore ("_") character delineates the
different levels within each component. This is the same delineator used by P3P when
data is solicited via an HTML form (refer to the P3P syntax spec).

The hierarchy of ECML can be more easily visualized using a tree representation:

While compatibility with the P3P base data set is a necessary step in incorporating
ECML into P3P, it is not sufficient. Inclusion of ECML into P3P also requires each
ECML attribute to have an associated P3P data type and requires the schema to be
represented using the P3P XML schema definition notation (which is a special form of a P3P
"proposal") as defined in section 4 of the P3P Syntax Specification.

Defining P3P Data Types for ECML

The following tables represent the individual attributes of ECML as a series of
components with associated data types.

$Ecom_Payment_Card_Name
is of type Text not PersonName
because the name associated with the card is the string exactly as it appears on the card
and card processing systems expect it to be a single string.

Expressing ECML using the P3P XML Schema Notation

Now that we have associated data types with the individual ECML elements, we can define
the schema using the formal P3P XML schema definition notation. This notation uses a
special form of a P3P proposal. It is stored in a file and referenced by regular P3P
proposals using the xmlns:Data attribute. Note:
if P3P user agents store the e-commerce data in a repository they should do so following
the security guidelines described later in this document.

It is unnecessary to specify DATA:REF's for all of the data elements of BillTo, ShipTo, and ReceiptTo
because they are instances of the Contact data type, which is
already defined in the P3P base data schema. The same is true for Card.ExpDate and Card.Name.

Also note the use of the dot (".") notation for delineating the different
components of the schema. This is P3P's native notation (as opposed "_",
which ECML uses). However, as mentioned previously, P3P uses the "_"
character to name HTML form fields because the "." cannot easily be used within
client-side Javascript.

The preceding P3P schema definition is all that is needed to use ECML within
P3P!

Simply create P3P proposals that reference this XML schema definition using the xmlns:data attribute and in the body of the proposal use the
elements defined by the schema.

Example

Assume the P3P ecommerce schema defined above was stored at http://www.w3.org/TR/WD-P3P/ecommerce-data.
A merchant named "Expedition Gear" could request that a user making a
purchase provide his/her credit card, billing address, and shipping address using the
following P3P proposal:

Schema 2: An ECML-Extended Schema for P3P

Web site developers wishing to use ECML within P3P can simply use the P3P/ECML schema
definition defined in the section above. However, we also define a P3P e-commerce
schema definition extension that is based upon the ECML one defined above, but extended to
include additional elements for data sent from the merchant to the user, and for other
payment instruments. In other words, we are creating an alternative schema that is a
superset of the one defined above. Our hope is that the members of the ECML steering
committee will incorporate these extensions in a future version of ECML.

ECML 1.0 is focused on using the existing web infrastructure to transfer payment data
from the user to the merchant. Given that focus, the 1.0 version of ECML does not
include schema for data sent from the merchant to the user. Unfortunately, this
leaves some significant data elements undefined by ECML. For example, a purchase
receipt (see Ecom_Receipt below) is a very important piece of
information that needs to be sent to the user after the transaction. Other
transaction details are needed to limit fraud, resolve disputes, and by the consumer to
support budgeting.

Another issue is that ECML version 1.0 only specifies two payment instruments: credit
card and PIN-less offline debit card. But a number of additional payment instruments
have recently started to be used online. We therefore extend the Ecom_Payment_Card element to include ATM PIN-based debit
cards. We also add a new payment instrument for additional bank payments such as ACH
debit, ACH credit, and FSTC eCheck (see the Ecom_Payment_Bank element below). ACH credit is a debit from
the payer's account and a corresponding credit to the payee's account. ACH debit is
an instruction from the payer to debit his/her account sent to the payee for deposit.
ACH is currently most frequently used for direct deposit and bill payment.

The tables below define this extended ecommerce schema. New elements are
highlighted in yellow
bold:

The cost of the
transaction, including all taxes, shipping charges, and any other fees. This is
could be part of a receipt (see Receipt element below) -- but it could also simply be
information sent between buyer and seller, usually prior to the transaction being
completed.

Receipt

Receipt.

The receipt sent to the
consumer after the transaction completes

Payment

Attribute Name

Data Type

Description

Card

Card.

Extended
to include ATM debit -- see Card data type below.

Bank

Bank.

Represents one of
several different types of fund transfers from a consumer's bank account to the merchant
(e.g. including ACH debit, ACH credit, E-check).

Card

Attribute Name

Data Type

Description

Type

Text*

Extended
to include designations for the ATM networks, including NYCE, HONR, STAR, CIRR, PLUS, MAC

Number

Text*

Verification

Text*

PIN

Text*

PIN number for ATM
transactions or any other card payment instrument that requires a PIN. Usually not
required for credit card transactions

ExpDate

Date.*

Name

Text.*

Note that this is intentionally not of type PersonName because it is a single
text string as embossed on the card.

Cost

Attribute
Name

Data Type

Description

Subtotal

Currency.

The
cost of the product/service not including taxes, shipping, or any other fees.

Taxes

Currency.

Cost
of applicable taxes

Shipping

Currency.

Cost
of delivering the product/service

Misc

Currency.

Any
other costs or fees (e.g. extended warranty)

Total

Currency.

Total
cost for product/service including Subtotal, Taxes, Shipping, and Misc

Paid

Currency.

Amount
paid by the payer

Currency

Attribute
Name

Data Type

Description

Amount

Text*

The
amount of currency

Curcode

Text*

The
three letter ISO-4217 standard currency code

Convertrule

Text*

Which
party is determining the currency of transaction. Valid values are
"payer", "payee" and "third party"

Receipt

Attribute
Name

Data Type

Description

Date

Date.*

The
date of the transaction

MerchantName

Text*

Name
of the merchant

MerchantContact

Contact*

Merchant
contact information (address, phone, email, etc). For many types of transactions in
the US, the city, state/prov, and country are required by regulation.

Description

Text*

Description
of product/service purchased

TrackingID

Text*

An
alphanumeric identifier generated by the merchant or third party that uniquely identifies
the transaction

ShippingTrackingID

Text*

An
alphanumeric identifier generated by the merchant or shipping company that uniquely
identifies the shipment of the product

Cost

Cost.

The
cost of the transaction, including all taxes, shipping charges, and any other
miscellaneous fees.

BillTo

Contact.*

The
billing address associated with the payment instrument used for the transaction

Represents
customer account number, such as the bank ABA Routing/Transit number plus account
number. Note -- ATM transfers should use the Number attribute of the Card
data type (defined above) to represent the ATM card number.

PayeeAccountNumber

Text*

Represents
the payee account number, such as the bank ABA Routing/Transit number plus account
number. Note -- ATM transfers should use the Number attribute of the Card
data type (defined above) to represent the ATM card number.

PayerAccountType

Text*

Type
of account referenced by PayerAccountNumber. Values include "checking",
"savings", and "creditline"

PayeeAccountType

Text*

Type
of account referenced by PayeeAccountNumber.

PayerName

PersonName.*

Name
as it appears on the payer account

PayeeName

PersonName.*

Name
as it appears on the Payee account.

Purpose

Text*

Purpose
of payment (required by banking regulations)

Date

Date.*

Date
to effect payment, also known as value date, from customer's perspective this is the
customer order date

The preceding P3P schema definition is a superset of the ECML-compliant schema
definition found earlier in this document. P3P technology providers and P3P
compliant web sites can choose to use either one.

Privacy and Security Guidelines

The guidelines presented here are optional when using P3P for e-commerce. They do
not necessarily represent the complete range of solutions merchants may choose to
employ. However, they do represent existing and emerging Internet standards that can
be adopted, in part or in their entirety, to help provide a safe, convenient, and
consistent e-commerce experience for users and developers. The guidelines leverage
both policy and technology.

Security

It is assumed that P3P user agents (e.g. P3P-compliant digital wallets) will either store
and transferall user data using secure methods (e.g. encryption)
or will selectively secure the storage and transfer of data based upon the
"category" of each data attribute. In the case of selective protection
based upon category, it is strongly suggested that all attributes in the
financial category (category="financial") be secured.

Secure transfer should occur using SSL, SET, eCheck, or a similar well-tested encryption technique
that protects users' personal information with reasonable security safeguards.
Encryption key size, for both transfer and storage, should be large enough to adequately
protect user data, and preferably be the maximum size supported by the user's client
software without violating national law or degrading performance or usability past the
point of user acceptance.

Acknowledgements

The authors would like to thank Lorrie Faith Cranor of AT&T for significant
contributions and editorial suggestions. Jeff Bell of Microsoft Corp's electronic
commerce group provided valuable insights into the payment process and also reviewed the
schema. The authors would also like to recognize members of the P3P Implementation
and Deployment working group for their ideas and suggestions. The ECML schema itself
was developed separately by members of the ECML alliance.