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

Hi Joseph and Patrick.

* Joseph Reagle <reagle@w3.org> [2003-06-03 17:29-0400]
> > |    [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"?

Let me try to make this concrete.

We could define the P3P feature, which indicates the policy for a
service.

Note that I am not sure that this is what you would want exactly since
one could imagine:
- the service pointing out where the policy reference file is for its
  different interfaces.
- the requester giving a URI of the agreed upon policy for a request:
  this probably is useful in a delegation scenario (in your example,
  the registrar telling the registry what he agreed to) or if one
  could negotiate a privacy policy (the registrant is proposed 2
  choices by the registrar: a 10% discount if he agrees to be
  spammed).
- a policy reference document instead of a URI.
- a privacy policy instead of a URI.

So, anyway, in order to make things concrete, let's try to address the
second case: expressing a URI to a P3P policy document. I think that
it is more useful than expressing the URI to a policy reference since
a WSDL description would already give a list of policies for each
service. Again, this would probably be up for discussion.

--8<----

P3P feature

- Name

	http://example.org/2003/06/16-p3pf/

- Description

The P3P feature is used to indicate the P3P policy governing the use
of a service.

- Properties

The P3P feature defines a single property:

  Property name:

	http://example.org/2003/06/16-p3pf/id

  Property type:

  	xsd:anyURI

The value of the http://www.w3.org/2003/06/16-p3pf/id property is the
identifier for the P3P policy governing the use of the service.

- Expressing the P3P feature

When using the http://www.w3.org/2003/05/soap/bindings/HTTP/ SOAP
HTTP/1.1 binding, the P3P feature is expressed as an HTTP header as
follows:

  P3P: policy=" URI-Reference "

In this case the value of URI-Reference is the value of the
http://example.org/2003/06/16-p3pf/id property.

Other bindings may define alternative ways of expressing the P3P
Reference feature.

If no alternative way has been defined, the feature and its property
are expressed in the form of a SOAP header.

[ Insert here the description of a SOAP header in the spirit of the
one you used for a policy reference file. ]

-->8----

Does it make things clearer?

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

I think so.

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

Well, I don't think that UDDI knows about features.

Let's take the P3P feature again.

A WSDL 1.2 description of a service with such a feature could be (this
may be slightly inaccurate, but you will get the idea):

  <feature
     uri='http://example.org/2003/06/16-p3pf/'>
  <property
     uri='http://example.org/2003/06/16-p3pf/id'>
    <value>http://registry.example.com/P3P/Policy.xml</value>
  </property>
  </feature>

With such a generic feature & property mechanism, a registry would be
able to express that the service has the following features, and if
your implementation knows what the P3P feature is, it will be able to
make good use of it.

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

Hmmm... I think that I was confused. I think that a policy reference
file is fine as a child of wsdl:definitions, but a reference to a
policy file, i.e. a policy which would apply to an operation, would be
more specific.

Which makes me wonder: are policy reference file useful to Web
services? With WSDL and something like a P3P feature, wouldn't the
problem addressed by policy reference files taken care of?

* Patrick.Hung@csiro.au <Patrick.Hung@csiro.au> [2003-06-07 01:32+1000]
> > > |    [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.) 
> 
> I also checked [55] and [56]. Based on my understanding, if we can describe
> the proposed privacy assertions for SOAP messages in the context of MEP and
> also
> describe the proposed privacy assertions' properties in the context of SOAP 
> Processing Model and the SOAP Protocol Binding Framework. Then, the proposed
> 
> privacy assertions can become a "feature" or I should say a new "feature" in
> 
> the SOAP framework. From the other aspect, we also have to define the 
> event-condition-rules for the proposed privacy scenrio in the context of
> MEP.
> Is my interpretation correct? 
> 
> Any illustrative example? Or is there any standard graphical representation
> to 
> depict MEP such as Petri-Net? It sounds that this topic is very interesting.
[..]

See my above example. I must admit that I am a bit fuzzy around the
relationship with MEPs.

> > > |    [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?
> 
> I would believe that the URI should be the URI of the ultimateReceiver's
> privacy policy. For those intermediaries, that's why we may have to define
> some new roles or "features" for them.

I think that there are different level of abstractions.

A service could be offered through different bindings and therefore
endpoints. This is why I am wondering whether using references to
privacy policies in WSDL documents isn't the most adequate way to do
this. The P3P feature I gave an example of wouldn't have this problem,
I think.

Regards,

Hugo

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Monday, 16 June 2003 05:14:42 UTC