Using P3P for E-Commerce

Abstract

This document describes how P3P¹ can be extended to support e-commerce.  Specifically, we:

1. Define how the Ecommerce Modeling Language (ECML)² can be used within P3P
2. Define schema for additional elements that are not part of ECML 1.0
3. 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.

Status of This Document

This document is a submission to the World Wide Web Consortium from Microsoft and Citibank, N.A. ("Citibank") (see Submission Request, W3C Staff Comment). For a full lost of all acknowledged Submission, please see Acknowledged Submissions to W3C.

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 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:

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:

Ecom
   ConsumerOrderID
   SchemaVersion
   TransactionComplete
   Payment
      Card
         Name
         Type
         Number
         Verification
         ExpDate
            Day
            Month
            Year
         Protocols
   ShipTo
      Postal
         Name
            Prefix
            First
            Last
            Suffix
         Street
            Line1
            Line2
            Line3
         City
         StateProv
         PostalCode
         CountryCode
      Telecom
         Phone
            Number
      Online
         Email
   BillTo
      Postal
         Name
            Prefix
            First
            Last
            Suffix
         Street
            Line1
            Line2
            Line3
         City
         StateProv
         PostalCode
         CountryCode
      Telecom
         Phone
            Number
      Online
         Email
   ReceiptTo
      Postal
         Name
            Prefix
            First
            Last
            Suffix
         Street
            Line1
            Line2
            Line3
         City
         StateProv
         PostalCode
         CountryCode
      Telecom
         Phone
            Number
      Online
         Email

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.

^*The Text, Boolean, Date, Contact, and PersonName data types referenced in the tables above are already defined by the P3P base data schema.

^$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.

The following formally defines an ECML-compliant schema for P3P:

<P3P xmlns="http://www.w3.org/TR/1998/WD-P3P-19981109/syntax" 
 xmlns:VOC="http://www.w3.org/TR/1998/WD-P3P-19981109/vocab"
 xmlns:DATA="http://www.w3.org/TR/1998/WD-P3P-19981109/basedata">
<PROP><USES><STATEMENT>

<DATA:REF name="Ecom.ConsumerOrderID" type="Text" short="User's Order ID" VOC:category="computer" />
<DATA:REF name="Ecom.SchemaVersion" type="URI" short="Schema Version" VOC:category="computer" />
<DATA:REF name="Ecom.TransactionComplete" type="Boolean" short="Transaction Status" VOC:category="computer" />
<DATA:REF name="Ecom.Payment." type="Payment." short="Payment Instrument" VOC:category="financial" />
<DATA:REF name="Ecom.BillTo." type="Contact." short="Billing Address" VOC:category="physical,online" />
<DATA:REF name="Ecom.ShipTo." type="Contact." short="Shipping Address" VOC:category="physical,online" />
<DATA:REF name="Ecom.ReceiptTo." type="Contact." short="Receipt Address" VOC:category="physical,online" />

<DATA:REF name="Payment.Card." type="Card." short="Credit Card" VOC:category="financial" />

<DATA:REF name="Card.Type" type="Text" short="Card Type" VOC:category="financial" />
<DATA:REF name="Card.Number" type="Text" short="Card Number" VOC:category="financial" />
<DATA:REF name="Card.Verification" type="Text" short="Card Holder Verification Number" VOC:category="financial" />
<DATA:REF name="Card.ExpDate." type="Date." short="Card Expiration Date" VOC:category="financial" />
<DATA:REF name="Card.Name." type="Text." short="Name on Card" VOC:category="physical,financial" />
<DATA:REF name="Card.Protocols." type="Text" short="Payment Protocols Available" VOC:category="computer" />

</USES></STATEMENT></PROP>

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:

<PROP
 xmlns="http://www.w3.org/TR/WD-P3P/syntax" 
 xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab"
 xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata"
 xmlns:DATA="http://www.w3.org/TR/WD-P3P/ecommerce-data"
 entity="http://www.ExpeditionGear.com">
   <ASSURANCE org="http://www.PrivacySeal.org" text="third party" image="http://www.PrivacySeal.org/Logo.gif"/>
   <REALM uri="http://www.ExpeditionGear.com/catalog/">
   <VOC:DISCLOSURE discURI="http://www.ExpeditionGear.com/PrivacyPractice.html" access="contact,ident"/>
   <USES>
      <STATEMENT VOC:purp="current" VOC:recpnt="ours" VOC:id="id" consq="Information needed to complete your purchase.">
         <DATA:REF name="Ecom.Payment.Card" VOC:category="financial"/>
         <DATA:REF name="Ecom.Payment.BillTo" VOC:category="physical,online"/>
         <DATA:REF name="Ecom.Payment.ShipTo" VOC:category="physical,online"/>
      </STATEMENT>
   </USES>
</PROP>
 

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 Text, Number, Boolean, Date, Contact, and PersonName data types referenced in the tables above are already defined by the P3P base data schema. 

Note: ATM transactions that require information from the Ecom_Payment_Bank data type can simply use both Ecom_Payment_Card and Ecom_Payment_Bank.

The formal P3P XML schema definition for this extended schema is:

<P3P xmlns="http://www.w3.org/TR/1998/WD-P3P-19981109/syntax" 
 xmlns:VOC="http://www.w3.org/TR/1998/WD-P3P-19981109/vocab"
 xmlns:DATA="http://www.w3.org/TR/1998/WD-P3P-19981109/basedata">
<PROP><USES><STATEMENT>

<DATA:REF name="Ecom.ConsumerOrderID" type="Text" short="User's Order ID" VOC:category="computer" />
<DATA:REF name="Ecom.SchemaVersion" type="URI" short="Schema Version" VOC:category="computer" />
<DATA:REF name="Ecom.TransactionComplete" type="Boolean" short="Transaction Status" VOC:category="computer" />
<DATA:REF name="Ecom.Cost" type="Cost." short="Transaction Cost" VOC:category="financial" />
<DATA:REF name="Ecom.Receipt" type="Receipt." short="Transaction Receipt" VOC:category="financial" />
<DATA:REF name="Ecom.Payment." type="Payment." short="Payment Instrument" VOC:category="financial" />
<DATA:REF name="Ecom.BillTo." type="Contact." short="Billing Address" VOC:category="physical,online" />
<DATA:REF name="Ecom.ShipTo." type="Contact." short="Shipping Address" VOC:category="physical,online" />
<DATA:REF name="Ecom.ReceiptTo." type="Contact." short="Receipt Address" VOC:category="physical,online" />

<DATA:REF name="Payment.Card." type="Card." short="Credit Card" VOC:category="financial" />
<DATA:REF name="Payment.Bank." type="Bank." short="Bank Payment" VOC:category="financial" />

<DATA:REF name="Card.Type" type="Text" short="Card Type" VOC:category="financial" />
<DATA:REF name="Card.Number" type="Text" short="Card Number" VOC:category="financial" />
<DATA:REF name="Card.PIN" type="Text" short="PIN" VOC:category="financial" />
<DATA:REF name="Card.Verification" type="Text" short="Card Holder Verification Number" VOC:category="financial" />
<DATA:REF name="Card.ExpDate." type="Date." short="Card Expiration Date" VOC:category="financial" />
<DATA:REF name="Card.Name." type="Text" short="Name on Card" VOC:category="physical,financial" />
<DATA:REF name="Card.Protocols." type="Text" short="Payment Protocols Available" VOC:category="computer" />

<DATA:REF name="Cost.Subtotal." type="Currency." short="Subtotal" VOC:category="financial" />
<DATA:REF name="Cost.Taxes." type="Currency." short="Taxes" VOC:category="financial" />
<DATA:REF name="Cost.Shipping." type="Currency." short="Shipping Cost" VOC:category="financial" />
<DATA:REF name="Cost.Misc." type="Currency." short="Other Costs" VOC:category="financial" />
<DATA:REF name="Cost.Total." type="Currency." short="Total Cost" VOC:category="financial" />
<DATA:REF name="Cost.Paid." type="Currency." short="Amount Paid" VOC:category="financial" />

<DATA:REF name="Currency.Amount" type="Text" short="Amount" VOC:category="financial" />
<DATA:REF name="Currency.Curcode" type="Text" short="Currency Code" VOC:category="financial" />
<DATA:REF name="Currency.Convertrule" type="Text" short="Party who determined currency" VOC:category="financial" />

<DATA:REF name="Receipt.Date" type="Date." short="Purchase Date" VOC:category="financial" />
<DATA:REF name="Receipt.MerchantName" type="Text." short="Merchant Name" VOC:category="physical" />
<DATA:REF name="Receipt.MerchantContact" type="Contact." short="Merchant Contact Information" VOC:category="physical,online" />
<DATA:REF name="Receipt.Description" type="Text" short="Purchase Description" VOC:category="financial" />
<DATA:REF name="Receipt.TrackingID" type="Text" short="Purchase Tracking Identifier" VOC:category="financial" />
<DATA:REF name="Receipt.ShippingTrackingID" type="Text" short="Shipping Tracking Identifier" VOC:category="financial" />
<DATA:REF name="Receipt.Cost" type="Cost." short="Purchase Cost" VOC:category="financial" />
<DATA:REF name="Receipt.BillTo" type="Contact." short="Billed To Address" VOC:category="physical,online" />
<DATA:REF name="Receipt.ShipTo" type="Contact." short="Shipped To" VOC:category="physical,online" />

<DATA:REF name="Bank.Type" type="Text" short="Payment Type" VOC:category="financial" />
<DATA:REF name="Bank.PayerAccountNumber" type="Text" short="Payer Account Number" VOC:category="financial" />
<DATA:REF name="Bank.PayeeAccountNumber" type="Text" short="Payee Account Number" VOC:category="financial" />
<DATA:REF name="Bank.PayerAccountType" type="Text" short="Payer Account Type" VOC:category="financial" />
<DATA:REF name="Bank.PayeeAccountType" type="Text" short="Payee Account Type" VOC:category="financial" />
<DATA:REF name="Bank.PayerName" type="Text" short="Payer Name" VOC:category="physical" />
<DATA:REF name="Bank.PayeeName" type="Text" short="Payee Name" VOC:category="physical" />
<DATA:REF name="Bank.Purpose" type="Text" short="Purpose of Payment" VOC:category="financial" />
<DATA:REF name="Bank.Date" type="Date." short="Payment Date" VOC:category="financial" />

</USES></STATEMENT></PROP>

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. 

The following policy mechanisms are available to merchants:

• Privacy Guidelines from the Online Privacy Alliance (OPA), Organization for Economic Cooperation and Development (OECD), and American Bankers Association (ABA)
• Privacy Policies
• Trust Assurance Providers (e.g. TRUSTe, BBBOnline, CPA WebTrust)
• Others...

From a technology perspective, merchants can leverage some or all of the following:

• W3C Platform for Privacy Preferences (P3P)
• SSL
• SET
• eCheck
• Privacy Tools (e.g. MSN/LinkExchange Privacy Policy Wizard)
• Others...

Privacy

The following fair information practices are recommended when conducting electronic commerce:

• Internet site owners/developers should implement and disclose a privacy policy governing the use of the requested e-commerce information. 
• The privacy policy should adhere to guidelines appropriate to its business as outlined by a recognized industry association or non-governmental organization, such as OPA, ABA, or OECD.
• Privacy policies should be implemented in both human and machine readable format.
• Machine readable privacy policies should conform to the P3P XML syntax.
• Web services should abide by appropriate privacy enforcement mechanisms (e.g. TRUSTe, BBBOnline, the EU data directive, or national law).

Security

It is assumed that P3P user agents (e.g. P3P-compliant digital wallets) will either store and transfer all 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. 

Additional privacy and security guidelines can be found in the P3P Guiding Principles Note.

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.  

References

1. World Wide Web Consortium (W3C), Platform for Privacy Preferences (P3P)
2. ECML -- Ecommerce Modeling Language
3. Odyssey Homefront Survey, January 1999
4. The New York Times Online, Technology Section, August 2nd, 1999, "Study Finds Decline in Web Shopping".
5. November 1998 Forrester Research Forecast
6. BCG/Shop.org Research performed between 11/23/98 and 12/20/98
7. Building Consumer Trust in Online Environments: The Case for Information Privacy, Hoffman, D.L, T.P. Novak, and M.A. Peralta, Working Paper (December 1998)