Last modified: $Date: 2003/12/09 15:40:45 $
Privacy information can be expressed in several places in the Web services architecture
Need to indicate privacy policy for an interaction.
Problem with the current solution in P3P Beyond HTTP: it isn't clear what my:Privacy applies to, since a WSDL document isn't necessarily a unique, complete and coherent, service description.
Not all the message may require the same privacy treatment (expressed in "3.2 XForms and More Granular Specification")
Can use message parts to differentiates them. WSDL 2.0 has deprecated them IIRC; we could mark the type definitions or the element declarations.
One could apply different privacy policies to different:
We could also consider marking the interface with a privacy policy.
Issue: resolving conflicts when interface I has policy Pi, binding B has policy Pb, and end point E has policy Pe, and one is trying to override the other.
Reusing idea from Steven after discussing with Philippe
Use an attribute than can be put on different constructs indicating that a policy applies to what the construct defines
Need to figure out semantics and resolution of conflicts when several policies are being applied at several different levels
Why would we want to put privacy information in a SOAP message? One can imagine an information flow different from P3P with the service consumer specifying its preferences, and asking the server to either agree and process or do nothing (with mustUnderstand)
Problem: how to do policy compatibility matching? can P3P do that?
Other uses? Didn't get the example in the document quite well about bindings and layers
WSDL 2.0 allows description of Web services according to the following model:
In such a model, different components may have different privacy policies applied to them.
First, as pointed out in section 3.2, a message may contain information for which different policies apply (e.g. a domain name versus a physical address versus a credit card number).
Second, the implementation of a service might be done with different privacy policies. An endpoint might be collecting private information, while another, implementing the same interface with the exact same binding, might be logging access for audit purposes, while a third one, still providing the same service, may not be keeping any kind of record of the transactions processed.
Also, one might want to default the privacy policy of a particular binding to certain values, e.g. because of some characteristics of the implementation used by all the endpoints.
Therefore, for each component, one might want to associate a privacy policy for this component.
Taken to a larger scale, for arbitrary XML vocabularies, one may want to attach a policy with an arbitrary XML element in order to associate a policy to the concept it represents.
A solution to this is to define a myns:p3pPolicy attribute which could be put on any element. This raises two issues:
for example, what does it mean to have such an attribute on a wsdl2:interface element?
if b is a child element of a and both a and b have a myns:p3pPolicy attribute with conflicting values, how can this be resolved?
In the case of WSDL 2.0, the myns:p3pPolicy has the following meaning:
@@@ Resolving conflicts might be hairy... we would have to think about that carefully, and maybe limit where one can put such an attribute; a much simpler solution is to only allow such an element on endpoint; one loses granularity, but it becomes simpler.
Assuming that the service requester could specify a desired P3P policy to the service, which is contrary to the current flow of information in P3P, one could consider the following P3P extension to SOAP 1.2.
A SOAP header contains a P3P policy (either with a URL or enclosed) in the SOAP message, and marked as mustUnderstand. The semantics of the header is as follows: either the SOAP recipient has a compatible privacy policy (@@@ I am not sure if such a concept exists in P3P), in which case the processing can continue, or the SOAP recipient doesn't and processing stops as the privacy terms are unacceptable to the SOAP sender. Because of mustUnderstand="true", if the SOAP recipient doesn't understand this extension and therefore cannot provide any privacy guaranties, processing stops.