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

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

From: <Patrick.Hung@csiro.au>
Date: Thu, 29 May 2003 01:56:57 +1000
Message-ID: <754324CDE8E4EE4498D8E0357D9136850160113D@saab-bt.act.cmis.CSIRO.AU>
To: reagle@w3.org, public-p3p-spec@w3.org

Hi Joseph,

> 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.

I agree. :-)

> 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

I have a bit concern about your statement "with an explicit understanding 
that various intermediaries will be relevant." Do you mean that both SOAP
sender 
and receiver realize that there exist some intermediaries but both SOAP
sender
and receiver do not have explicit knowledge of who and where the
intermediaries are
on the Web?
 
> 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.

I totally agree with you.

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

Yes, it is fine.

> (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?

Yes, I mean the intermediaries. It is because there is no such serious
concern 
at the SOAP sender side and also the ultimate receiver should respect its 
own privacy policy (or I can name it as the SOAP receiver's promise to the
sender).

For the UDDI, here are my suggestions (very rought and have to check the
syntax
carefully) to put privacy policies at two levels:

(1) "businessEntity: Describes a business or other organization that
typically 
    provides Web services." [1] For example:

<businessDetail generic="2.0" operator="Microsoft UDDI Services"
truncated="false" xmlns="urn:uddi-org:api_v2">
<businessEntity businessKey="186a3421-0c20-45d1-b81d-efb9f61b0b15"
operator="sample" authorizedName="sample">
<discoveryURLs>
<discoveryURL useType="businessEntity">
http://uddi.example.com/uddipublic/discovery.ashx?businessKey=186a3421-0c20-
45d1-b81d-efb9f61b0b15
</discoveryURL>
</discoveryURLs>
<Privacy href='http://registry.example.com/P3P/PolicyReferences.xml'
rel='P3Pv1'/>
<name>Registry</name>
<description xml:lang="en" />
<contacts/>
</businessEntity>
</businessDetail>

(2) "businessService: Describes a collection of related Web services offered
by an
organization described by a businessEntity." [1] For example, 

<businessServices>
<businessService>
<name>Register</name>
<description xml:lang="en">
Register Domain Name
</description>
<Privacy href='http://registry.example.com/P3P/PolicyReferences.xml'
rel='P3Pv1'/>
<bindingTemplates>
<bindingTemplate>
<accessPoint useType="endpoint">
http://registry.example.com/register
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo
tModelKey="uddi:ubr.uddi.org:transport:http">
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
</bindingTemplates>
<categoryBag>
<keyedReference
tModelKey="uddi:uddi.org:categorization:general_keywords"
keyName="registry.example:categorization:domainname"
keyValue="a"/>
<keyedReference
tModelKey="uddi:ubr.uddi.org:categorization:unspsc"
keyName="UNSPSC: Domainname" keyValue="102025"/>
</categoryBag>
</businessService>
<businessServices>

If we really want to mention UDDI in the working draft, as you know, we have
to play with the 
UDDI schema.

Let me try to go far here... This may be an interesting research topics in
the future:

"subscription: Describes a standing request to keep track of changes to the
entities
described by the subscription." [1]

Should we also have a function to keep track of the changes in privacy
policies?
Anyway, we can forget this point in this task force working draft.


[1] http://uddi.org/pubs/uddi-v3.00-published-20020719.pdf

Just stop here. Talk to you later.

Patrick.
Received on Wednesday, 28 May 2003 11:57:14 EDT

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