W3C

Using P3P for E-Commerce

W3C Note, 29 November 1999

This version:
http://www.w3.org/TR/1999/NOTE-P3P-ecommerce-19991129
Latest version:
http://www.w3.org/TR/P3P-for-ecommerce
Previous Version:
None
Authors:
Joe Coco <joecoco@microsoft.com>, Microsoft
Saul Klein <saul_klein@hotmail.com>
Dan Schutzer <dan.schutzer@citicorp.com>, Citigroup
San-Yuan Yen <san-yuan.yen@citicorp.com>, Citigroup
Alan Slater <alan.slater@citicorp.com>, Citigroup

Abstract

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

  1. Define how the Ecommerce Modeling Language (ECML)2 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 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.
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 "                "

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.

Ecom
Attribute Name Data Type
ConsumerOrderID Text*
SchemaVersion URI*
TransactionComplete Boolean*
Payment Payment.
BillTo Contact.*
ShipTo Contact.*
ReceiptTo Contact.*

Payment
Attribute Name Data Type
Card Card.

Card
Attribute Name Data Type
Type Text*
Number Text*
Verification Text*
ExpDate Date.*
Name Text.*$

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

Ecom
Attribute Name Data Type Description
ConsumerOrderID Text*  
SchemaVersion URI*  
TransactionComplete Boolean*  
Payment Payment. Extended to include Bank payments/transfers such as ACH debit, ACH credit, eCheck, etc.  See Payment data type below.
BillTo Contact.*  
ShipTo Contact.*  
ReceiptTo Contact.* The address to which a receipt is sent (can be email address or fax)
Cost Cost. 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
ShipTo Contact.* The shipping address to which the product/service is being delivered

Bank
Attribute Name Data Type Description
Method Text* Type of transaction, such as ACH debit, NACHA credit push, FSTC e-check, FSTC z-flow, etc. 
PayerAccountNumber Text* 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 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:

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

Privacy

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

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)