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

[BH] Application Patterns and SOAP (Was: First (Very Rought) Outline of Beyond HTTP)

From: Joseph Reagle <reagle@w3.org>
Date: Tue, 27 May 2003 18:29:21 -0400
To: Patrick.Hung@csiro.au, public-p3p-spec@w3.org
Message-Id: <200305271829.21808.reagle@w3.org>

On Tuesday 27 May 2003 02:02, Patrick.Hung@csiro.au wrote:
> Referring to [1], those three variables are related to the SOAP Message
> Exchange Patterns
> (MEPs) discussed in [2].

Hi Patrick, they might be similar but I believe they are orthogonal. P3P's 
scope of "identity" and "recipient" with respect to flow, decision, and 
aggregation is at the application level, the SOAP MEPs are at the "message 
transport" level. However, I appreciate that SOAP intermediaries 
*themselves* have their own privacy issues  -- just as various network 
intermediaries with simple P3P1.0 do (e.g., proxies) but which that spec 
didn't attempt to take on.

The scenario I have in my mind is that SOAP is being used in an "end-to-end" 
model with an explicit understanding that various intermediaries will be 
relevant. Te request/response is e2e between the user agent and service 
with intermediaries in between. I wouldn't be keen to design a multi-party 
protocol using SOAP -- or anything else, but I still think this is more in 
line with what folks call choreography -- but what do I know. <smile/> This 
is why I'm holding back at the level of "Adopting applications that want to 
ensure the privacy of user information SHOULD take steps to ensure that no 
information is released to a network intermediary that is not covered by 
its P3P policy." and "@@ Do we need to say anything more about forwarding 
and active intermediaries? I would prefer to rely upon the text above 
unless we are further pressed." Absent a compelling case, I prefer not to 
get into multi-party "choreagraphed" transactions.

> Part of these requirements should be very close to the "Table 3: SOAP
> Nodes Forwarding
> behavior" [2]. Should we have to enhance the "next" role with more
> behaviors to handle
> the proposed privacy policy? For example, the privacy policy, say in P3P,
> at the
> SOAP intermediaries with the "next" role must contain "<current/> and
> <admin/> for
> <PURPOSE/> and also <no-retention/> for <RETENTION/>.

This is an interesting point. Again, presently we say, "Adopting 
applications that want to ensure the privacy of user information SHOULD 
take steps to ensure that no information is released to a network 
intermediary that is not covered by its P3P policy." The SOAP header 
example shows that the SOAP header includes the same policyURI that the 
ultimateReceiver will be respecting. We *could*, as you suggest, define a 
"P3P Policy for SOAP intermediaries" policy and recommend it be used for 
non-ultimateReceivers, but I'm not confident. I've captured this issue in 
the "@@" and will link to this thread and perhaps the WS folks will be able 
to comment on it:

[[[Do we need to say anything more about forwarding and active 
intermediaries? Should we define a "P3P Policy for SOAP intermediaries" 
that only permits the data to be used for the "current purpose/admin and no 
retention" that SOAP intermediaries MUST use? Reagle prefers to rely upon 
the text above unless we are further pressed with actual use cases.]]]

> (1) Should we also have to mention the privacy issues of audit trail
> (e.g., log files)
> at each Web service? We assume that all Web services are all seating with
> the Web server
> and so.

How do you mean? The intermediaries?

> (2) In the future, should we also think about the internationalization of
> P3P policies in
> this Web services execution environment? It is bcause there are different
> privacy laws in
> different countries or even between different states.

I don't feel we need to go there yet.

-- 
* I will be travelling May 22/23, and attending OSCOM3 May 28-30. 
I will not be as responsive during these periods but will 
respond to any email as soon as possible upon my return.
Received on Tuesday, 27 May 2003 18:29:29 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 17 March 2004 17:46:24 EST