Commercial Ad

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 1998³. 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 1999⁴. Looking at the numbers from another perspective, Forrester Research forecasts the US consumer e-commerce marketplace to reach $18 billion in 1999⁵. 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.⁶

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.⁷

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.
Ecom_Payment_Card_ExpDate_Day	The day of the month. Values: 1-31
Ecom_Payment_Card_ExpDate_Month	The month of the year. Jan - 1, Feb - 2, March - 3, etc.; Values: 1-12
Ecom_Payment_Card_ExpDate_Year	Always four digits, e.g., 1999, 2000, 2001, ...
Ecom_Payment_Card_Protocols	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.
Ecom_ShipTo_Postal_CountryCode	Use [ISO 3166] standard two letter codes for country names.
Ecom_ShipTo_Telecom_Phone_Number	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.
Ecom_ShipTo_Online_Email	For example: jsmith@isp.com
BillTo Component	Billing address of the purchaser's payment instrument
Ecom_BillTo_Postal_Name_Prefix	See ShipTo
Ecom_BillTo_Postal_Name_First	" "
Ecom_BillTo_Postal_Name_Middle	" "
Ecom_BillTo_Postal_Name_Last	" "
Ecom_BillTo_Postal_Name_Suffix	" "
Ecom_BillTo_Postal_Street_Line1	" "
Ecom_BillTo_Postal_Street_Line2	" "
Ecom_BillTo_Postal_Street_Line3	" "
Ecom_BillTo_Postal_City	" "
Ecom_BillTo_Postal_StateProv	" "
Ecom_BillTo_Postal_PostalCode	" "
Ecom_BillTo_Postal_CountryCode	" "
Ecom_BillTo_Telecom_Phone_Number	" "
Ecom_BillTo_Online_Email	" "
ReceiptTo Component	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	" "