W3C home > Mailing lists > Public > public-p3p-spec@w3.org > May 2004

Re: P3P Generic Attribute for XML Applications

From: Rigo Wenning <rigo@w3.org>
Date: Tue, 4 May 2004 18:54:58 +0200
To: public-p3p-spec@w3.org
Cc: Mark Nottingham <mark.nottingham@bea.com>, Lorrie Cranor <lorrie@cs.cmu.edu>
Message-Id: <200405041854.58488.rigo@w3.org>
Am Tuesday 04 May 2004 00:51 verlautbarte Mark Nottingham :
> >> I think you also need to require people who use this attribute in 
> >> their formats to explicitly identify who is required to conform to 
> >> the policy (#1).
> >
> > Wouldn't that be covered by the ENTITY element? Or are you thinking of 
> > something beyond that?
> Ah, yes; that should do it. Does ENTITY have some mechanism for 
> identifying an anonymous party (e.g., "Anyone I send THIS message to me 
> MUST conform to this privacy policy)? I'd imagine there are cases where 
> people using this attribute won't want to explicitly enumerate the 
> entity responsible for conforming to the policy.

Mark, here you fall exactly into the trap of the wrong protocol. 
You send PREFERENCES instead of POLICY in your example ;)
You don't go to the supermarket to impose your conditions. You 
accept their conditions. 

In data protection, you need the ENTITY element to be able 
to get to your rights as you can't force your rights against 
anonymous. In a web-service scenario, this is tricky as the 
WS interacting can be a privacy client in one second and a 
data controller in the next second. 

Imagine WS1 discovering WS2. WS1 is requesting something to 
WS2 and finds the P3P Policy in the WSDL. The PP is good and 
WS1 makes its request. If there is need for feedback and WS2 
makes a request to WS1, WS2 would have to check the P3P Policy 
of WS1 first.

(Note that this only applies if _personal_ data is involved, means 
some end-user or request on behalf of an end-user)

Sending Policies forward and saying SOAP "must understand" 
can't be solved with P3P, it needs EPAL.



Received on Tuesday, 4 May 2004 13:23:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:18 UTC