Re: Comments on "[P3P]: Beyond HTTP"

On Monday 02 June 2003 14:34, Hugo Haas wrote:
> Please find below some comments regarding:

Thanks for the comments Hugo!

> |    [37]Adopting applications that rely upon a data format other than
> |    [XHTML] to solicit information SHOULD support the first (well known
> |    location) and fourth (HTTP header) mechanisms; [38]adopting
> |    applications MUST NOT ever (mistakenly) release information to an
> |    application it is not familiar with on the basis of [P3P] mechanisms
> |    that it is familiar with. [39]Adopting applications MAY provide a
> |    means of associating a policy reference file with their own format.
>
> I think that for Web services, the policy (or the link to a policy
> reference file) should be expressed as a feature. Features are the
> extensibility mechanism of SOAP 1.2[55]. The Web Services Description
> WG is working on their description and the Web Services Architecture
> WG is evaluating their role in the overall architecture.

How is this done? I've read [55] and it's written in the abstract, and I've 
also looked at [56], but I'm not sure how to apply it. (Also, while we've 
been exploring various options, we also having been avoiding the "exotic" 
features unless there some cause to demonstrate them.) 

> Feature is basically a functionality which can be expressed in
> different ways. In this case, the policy / policy reference would be
> carried by the SOAP message:
> - inside the envelope.

We've mocked up a header by which a sender can "ask" all intermediary nodes 
to also understand the privacy policies of the carried application data:

<env:Header 
  xmlns='http://registry.example.com/2003/soap-header-p3p-extension.xsd' 
  xmlns:env='http://www.w3.org/2003/05/soap-envelope' >
  <Privacy env:role='http://www.w3.org/2003/05/soap-envelope/role/next'
    env:mustUnderstand='true'>
    <rel>P3Pv1</rel>
    <href>http://registry.example.com/P3P/PolicyReferences.xml</href>
  </Privacy>
</env:Header>

But what does one have to do to represent it as a "feature"? Also, since we 
are not an application ourselves (but expect P3P to be used by "adopting 
applications") we presently can't limit this to any particular MEP. I'd 
expect such a header would be orthogonal to other MEPs and "features".

> Registries would most likely refer to the service description and you
> would get that information for free.

So, for example, a UDDI registry would probably know how to pull information 
for its own puproses and translate it into UDDI syntax?

> |    [49]Adopting applications MUST specify where relevant [P3P]
> | statements can be found. We RECOMMEND that normative association (not
> | including [WSDL] or [UDDI]) be limited to the higher/application layer.
> | We RECOMMEND that a higher/abstract layer MAY include the privacy
> | policy of layers it is dependent upon, but that lower layers SHOULD NOT
> | represent the policies of higher layers. For example, an application
> | that transfers data with SOAP over HTTP that uses cookies, SHOULD
> | specify:
> |     1. the [P3P] policy associated with SOAP is normative and includes
> |        the HTTP policy, or
> |     2. there are distinct [P3P] policies associated with the SOAP and
> |        HTTP layers.
>
> Isn't this already the case with a Web server nowadays? The HTTP
> stack/server may have some logging policies different from the ones a
> CGI has, for example.

There's nothing terribly novel in this case. But in your example, we didn't 
have the HTTP and the CGI presenting you with different policies. The 
policy associated with the HTTP was good for your interactions with the 
specified URI (e.g., the CGI). In SOAP, the recipient of the *transport* 
layer (the SMTP recipient or HTTP server the POST is sent to) might be 
different the the SOAP ultimateReceiver, right? Which brings me to the 
question, in SOAP, how do you identify the "ultimateReceiver"? What URI 
should the PolicyRef file refer to, the URI of its immediate transport 
counterpart (I don't think so), or the "ultimateReceiver" -- if you can 
identify that?

> There is something else which probably needs to be underlined. P3P
> reference policies for resources, whatever the operation on them is.
>
> With Web services, what the resource is is a little fuzzy (a car? the
> application in charge of selling cars? some state about the sale of a
> car?) and WSDL defines the interface to this target resource. The
> level of granularity here is probably the WSDL operation.

I think this relates to my question above, and Patrick has explored this a 
bit. In our example, we associated it with the definition (my:Privacy is a 
child of the wsdl:definitions), are you recommending it be a child of the 
wsdl:operation element?
  http://www.w3.org/P3P/2003/p3p-beyond-http/wsdl-eg.xml

Received on Tuesday, 3 June 2003 17:29:41 UTC