Platform for Privacy Preferences (P3P)

Technical Description
Update of Dr. Miller presentation.

Joseph Reagle, P3P Project Manager
(reagle@w3.org)
World Wide Web Consortium
MIT Lab for Computer Science

http://www.w3.org/Talks/980103-IBM-updated/

Background

• Bonn Declaration, Japan Framework, and Magaziner Framework all concerned with commerce, information exchange, and privacy:
  • "Commerce on the GII will thrive only if the privacy rights of individuals are balanced with the benefits associated with the free flow of information." -- Magaziner Framework.
• Many guidelines (OECD, CSA, ITI, etc.) on privacy, few implementations for the Web.
• User confidence is necessary to exploit the full potential of the Web
  • 53% of people concerned that information "will be linked to their email addresses and disclosed ... without their knowledge or consent." (LH&A and Westin 1997) ~40% of Internet visitors falsify data when asked to register at Web sites. (GIT 7th User Survey).
• By 2001 there will be more Online TVs in use than Online PCs.  (Strategy Analytics).

P3P Scenario

1. A user sets generic preferences, upon which her agent (browser) automatically acts.
   She can now browse the Web seamlessly.
2. She encounters a site with "exceptional" practices outside her generic preferences.
   Perhaps a sports news site wants to collect her favorite teams for a customized news page.
3. The user is prompted if she wishes to consider other alternatives, consent to the exceptional practice, or to go elsewhere.
   She can develop a one-to-one relationship with a site she trusts.

What P3P Is About

• Personal choice and informed decision making/consent.
• Commitment from publisher about use of data.
• Technology to communicate and form an agreement.
• Any subsequent data request must comply with agreement.
• Once agreed to, future requests can happen seamlessly.

P3P Assumptions

• P3P applies to Web (HTTP) information, partial application to HTML forms
• Agreements are end-to-end, and eavesdropping is handled by TLS (SSL) or IPSec
• Uses HTTP1.1 extension mechanism but should working through HTTP1.0 proxies
• XML attributes may be of arbitrary length

P3P Architecture

One needs a:

• A grammar (schema) for making statements (wet-ware)
• Encoding methods for representing proposals/data  (XML/RDF)
• Protocols for exchanging proposal/data (HTTP)

Concepts

AgreementID

A small unit of information that indicates both parties have agreed on a common proposal. An agreementID is the fingerprint of an accepted proposal. The presence of the agreementID in the P3P headers is the definitive declaration of which agreements for a given realm are in effect for a given transaction.

Assuring Party

Within P3P, an assuring party is an entity which makes some statement of assurance about a proposal (e.g. that practices are audited, or are in compliance with certain data collection guidelines).

PUID

PUID := hash(GUID, Realm, AgreementID). The PUID is an optional way for the user to identify herself to a service under a particular agreement. PUIDs correspond directly to a specific realm and agreement. PUIDs are like cookies, but are under P3P control and are simple numberical values.

Example P3P Grammar

Example P3P Proposal

<proposal agreementID="1e3a5d71297d104f"
SCHEMA=http://www.w3.org/P3P10.schema"
 REALM="http://www.CoolCatalog.com/catalogue/"/>
  <uses>
    <statement purpose="2" id="0"
    CONSEQUENCE="customized the site">
    <data>
     <ref NAME="User.PersonName.First"/>
     <ref NAME="Web.PUID"/>
     <ref NAME="FineShoes.Shoesize"
          dataschema="http://www.FineShoes.com/Schema1.0"/>
    </data>
   </statement> </uses>
 <DISCLOSURE text="http://www.CoolCatalog.com/PrivacyPractice.html" 
 ACCESS="3" OTHERDISCLOSURE="0 1"/>
</proposal>

Agreements: The Issues

• Both parties agree on what practices will be applied to what data
• Agreement is independent of mechanism used to convey the data
• Agreement may be made prior to or concurrent with request to transmit data via P3P mechanism
• Agreement may be made in terms of explanatory references (e.g. "contact information", called categories)
• Agreement may be made in terms of names of data elements (e.g. "http://www.w3.org/P3P/StandardDataElements/User.FirstName")

Agreements: The Technology

1. the agreementID: fingerprint of a proposal
2. fingerprints plus digital signatures when they are available.

Technically, this corresponds to a small piece of metadata in RDF (Resource Description Framework) format that may optionally include a DSig 2.0-compliant signature.

Categories and Classes

Convenient ways of specifying sets of data elements, implicitly by attributes (categories) or explicitly by sets of names (classes).

• Categories are used for describing new data sets in assisting GUI configuration. Classes are primarily for transferring groups of related data elements.
• Categories are likely to be the naming system that users see and understand. Classes are primarily of interest to the people running servers.
• Both categories and classes are extensible by both the client and the server (new data elements can be created within existing classes, new classes can be created, new categories can be created, existing data elements can belong to new categories, etc.)

Standardization of Names

Some standardization is mandatory and will be undertaken by the harmonization group:

• Standard classes, whose names are known to all clients and servers.
• Standard categories, whose names are known to all clients and servers.
• Minimal set of standard named data elements that belong to these standard classes, along with their data type and a minimal set of named categories to which each standard data element belongs.

Transferring Data (bi-directional)

• Server requests data transfer, client approves and transmits or stores data
• Request for data (by server) may be accompanied by an existing agreement or a new proposal for agreement
• Requests for data can be made by specifying a name or a category (note that a single name may refer to many elements).
• Some data elements and sets of data elements have universally known names: these are the classes

Universal Negotiation Primitives

1. OK, OK
2. PROP, proposal
3. SRY, (sorry) refusal with reason
4. TXD, transmit data (either direction)

Negotiation Flow

Data Transfer

Transfers occur only occur with user consent. Transfers include the a reason code, agreementID, and the name-value pairs.

<txd r=200 agreementID="94df1293a3e519bb" />
<data NAME="User.PersonName.First" VALUE="Josephine"/>
<data NAME="Web.PUID" VALUE="1528374951607"/>
<data NAME="FineShoes.Shoesize"
  dataschema="http://www.FineShoes.com/Schema1.0" VALUE="7"/>
</txd>

Privacy Protection: Not Just Technology

• P3P is a good technological base
• Existing or new legislation may be needed to handle
  • misrepresenting privacy practices
  • refusal to state privacy practices
• Enforcement requires auditing

Conclusion

• Users have privacy preferences
• Servers have privacy practices
• P3P provides a framework for a market
  • Invisible if practices satisfy preferences
  • Notification or negotiation if not
  • Release of information can be automatic if user has given prior consent

  "P3P a win-win for privacy and commerce."

Some of the Members Working on P3P