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

Hi Joseph and 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.) 

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.

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

Does Hugo mean that we should have a generic MEP for the proposed privacy
assertions in SOAP messages? Not tie up with any domain specific
application.

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

Yes, we should have this assumption and I do believe some related research 
should have been done (though I haven't checked it). :-)
However, you can only see those unautomatic UDDI at
http://www-3.ibm.com/services/uddi/
or http://uddi.microsoft.com

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

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

I would believe that we may have to provide two levels (service and
operation)
for optional privacy policies. The operation level's privacy policy can
overwhelm 
the service level's once there exist any contradiction? In the normal case,
the privacy policy should be the union of both for each operaiton? If there
is no operation level so that it is inherited from the servce level.

However, this may cause more thoughts about UDDI as UDDI has three levels:
Business Entity, Business Service and tModel.

Lastly, just a very little typo found at
http://www.w3.org/P3P/2003/p3p-beyond-http/Overview.html:
"Our scenario is not intended to be a completely accurate 
representation of real world requirements, nor does our 
document necessarily provide a satisfactory solution. 
Instead, this scenario is intended to be sufficiently 
represenative ..."
^^^^^^^^^^^^^

Talk to you later. Have a nice weekend!

Patrick.

Received on Friday, 6 June 2003 11:33:12 UTC