Report for DG Markt and the Internet Task Force of Art 29 WP on Status of recommendations for W3C's P3P Standard

P3P Art. 10 Task Force Report 3 September 2003

This version:
$Revision: 1.3 $ on $Date: 2003/12/17 17:56:37 $ GMT by $Author: lorrie $
Latest version:
Previous version:
Issues around Art. 10 of the European Data Protection Directive from 23 May 2003
Giles Hogben <giles.hogben at jrc.it>
Giles Hogben <giles.hogben at jrc.it>
Rigo Wenning (W3C)
Diana Alonso-Blas (EU-Commission DG Internal Market)


This document specifies guidelines for P3P 1.1 user agents.

Status of this document

This is an editors' draft with no standing. We are proposing that this document be folded into the P3P 1.1 specification in the places as indicated by the section numbers here.

Sept 3th 2003, Giles Hogben, JRC, IPSC

1 Introduction and Summary

This document describes the status of the joint JRC/DG Markt and Art 29 ITF WG's feedback to W3C's P3P standard. The major milestones in this process so far have been:

It is important to note that following the Washington DC workshop, it was decided to divide the P3P standards process into P3P 1.1. (quick win changes without affecting backward compatibility) and P3P 2.0. (substantial changes). This is based on the requirement on the one hand to make some changes quickly without causing major disruption to existing systems and on the other hand to make substantial changes in the long term. The status of our recommendations in P3P 1.1. and P3P 2.0. are summarized in the subsequent chapters. :

Art. 10 of the EU-Directive 95/46/EC

Article 10

Information in cases of collection of data from the data subject Member States shall provide that the controller or his representative must provide a data subject from whom data relating to himself are collected with at least the following information, except where he already has it:

(a) the identity of the controller and of his representative, if any;

(b) the purposes of the processing for which the data are intended;

(c) any further information such as

in so far as such further information is necessary, having regard to the specific circumstances in which the data are collected, to guarantee fair processing in respect of the data subject.

2 P3P 1.1. process: summary of specific proposed changes agreed with W3C working group

Summary of specific proposed changes agreed with W3C working group

P3P 1.1. process

JRC evaluation paper ref

Process Definition

Backward compatibility requirement - Any site or user agent which is written according to P3P1.0 will also be valid according to P3P1.1.


Spring 2004

Issue 1:

Purpose specfication

Guidelines for presentation of purpose specification PRIOR TO data collection


Issue 2:

Jurisdiction specification

Jurisdiction Extension allowing policies to express whether data collected will be taken outside the EU.


Issue 4:Cookies

Note on application of cookies at set time (already effectively required in spec but not made explicit).


Issue 3:

Security Attributes

Validation of controller's security processes via an approved seal


P3P 2.0. process: summary of changes/recommendations

Summary of issues in discussion with W3C working group.

P3P 2.0 process

JRC evaluation paper Ref


Breaks backward compatibility and includes issues which need a longer development period.


2-3 Years

Issue 1.

Preference language:

IBM, Microsoft and W3C have all agreed to start a process of creating a viable, interoperable preference languages. *(Discussions of new working group in Sydney Sept)


Issue 2.

Consent Capture Mechanism (solves article 10 issues but also offers a back channel for feedback to enterprises)


Issue 3.

Removal of compact policies from the specification. This is a new recommendation on the basis of the fact that they effectively invalidate any legal basis for the specification and offer a back-door to controllers wishing to by-pass user preferences. This is our recommendation and is supported by several members of the WG. Microsoft agrees to test performance issues definitively now that browsers have new XML parsers etc…


Issue 4.

Adaptation of P3P language for Enterprise Audit Trails


Full text of recommendations for P3P 1.1.

Full text of P3P 1.1. changes agreed with W3C WG .

Purpose specification:

Include in user agent specifications, a note about requirements for EU. Suggested text:

"For user-agents subject to European Union law, human readable information on purpose of collection should be presented to the user before any information is captured. This can be acheived on 2 levels. First human readable translations of policies for action uri's of forms should be presented along with forms. In its strictest interpretation, information on purposes should be available before any page is loaded. This might be acheived by a privacy tab which is synchronised to display information before pages load, or by including information which is displayed on clicking a link."


Jurisdiction Disclosure:

We suggest that an Jurisdiction extension be added to the recipient element:

Extension name:jurisdiction

allowed values:


US Safe Harbour




Text for specification:

"The jurisdiction extension element allows user agents to make judgements about the trustworthiness of a data recipient based on the regulatory envirnment they are placed in. For example organizations within the European Union can be assumed to comply to European data protection law."

Some jurisdictions prohibit transfer of data to certain other jurisdictions without the explicit consent of the data subject. Therefore declaring a data transfer activity using the P3P jurisdiction extension is not sufficient to guarantee its legality.


Suggested text:

"For browsers operating within European Union Jurisdiction, policies must be evaluated before a cookie is set and not on replay. This is because the storage of cookies on a user's computer is considered by European Data Protection authorities to be an act of data processing because the place of storage being on the user's machine is considered immaterial to the act of processing"

Security issues:

To use the existing disputes attribute which is a placeholder for seals of any type (which can then be included in the browser's list of approved seals, along with a type attribute). Accompanying text:

"In order to assure users of good security practices in handling data captured through their site, policy writers may also use this attribute to specify seals (such as CPA WebTrust and Shop Smart) validating their security practices."