RE: [BH] First (Very Rought) Outline of Beyond HTTP

Hi Joseph,

Do you want to say something?

Patrick.

-----Original Message-----
From: Joseph Reagle [mailto:reagle@w3.org]
Sent: Friday, 2 May 2003 6:33 AM
To: Patrick.Hung@csiro.au; public-p3p-spec@w3.org
Subject: Re: [BH] First (Very Rought) Outline of Beyond HTTP



On Thursday 01 May 2003 02:34, Patrick.Hung@csiro.au wrote:
> Please let me try to describe a scenario as follows:

Hi Patrick, I think I have the gist of your scenario though I'm a little 
confused by some of the terminology. For example, I would think that the 
"requestor" would have privacy *preferences" and the others would have 
*policies*. This has caused me to work some more on the definitions 
(including looking at [1]) and perhaps we could speak in terms of User 
(registrant), Soliciting Service (registrar), and a Recipeint Service 
(registry)?

[1] http://www.w3.org/TR/2002/WD-ws-gloss-20021114/

I think the difference is you also included the UDDI component to the 
scenario.

> UDDI

I think a UDDI scenario is useful, but it's not my top priority and I'm not 
quite sure how to include with sensible motivation in our present DNS 
registry scenario. But that can change!

> Referring to the WSDL specification, "WSDL has four transmission
> primitives that an endpoint can support:
>
> (1) One-way. The endpoint receives a message.
> (2) Request-response. The endpoint receives a message, and sends a
>                       correlated message.
> (3) Solicit-response. The endpoint sends a message, and receives a
>                       correlated message.
> (4) Notification. The endpoint sends a message."
>
> Referring to the scenario described above, does it mean that the WSDL can
> not
> support (1) because the requestor has no way to know whether the provider
> is
> happy or not about the requestor's privacy policy based on the provider's
> preferences? If so, what should we do?

If an endpoint can advertise its privacy policy and presume any message 
transmitted to it will have seen that policy, I presume it could accept 
such a message without sending a response. (This is akin to earlier debates 
in P3P as to whether a unique policy identifier could be associated with a 
request in order to avoid a round trip I think...) 

> However, I have some trouble with the requirement "AR020.6: Web Services
> must not be precluded from supporting interactions where one or more
> parties of the interaction are anonymous." This may work in some 
> cases. However, those security tokens WS-Security and SAML are 
> mainly designed for authentication. Thus, is there any conflict between
> AR020.6 and Web services security?

No. I'm a big fan of "not precluded"; it means that while authenticated 
interactions are possible, and even encouraged, it should be *possible* 
architecturally for someone to not be authenticated.

> There are two typos in the draft:

Fixed.


> Referring to the "Scope and Bindings (HTTP and SOAP)" section, it would
> be more precise to say that "For example, a browser-interfaced
> application that transfers data with SOAP over HTTP that uses
> cookies,..." instead of "For example, an application that transfers data
> with SOAP over HTTP that uses cookies, ..."

What do you mean by "browser-interfaced" and why is that necessary?

> Further, I would believe that "there are distinct P3P policies associated
> with the SOAP and HTTP layers." because these are belonging to two
> layers: the SOAP message is on the application layer and the HTTP
> protocol is on the transport layer.

Yes, but the adopting application (e.g., DNS registration) has the ability 
to profile it's dependencies. So it could say, "the only normative P3P 
semantics associated with *this* application (DNS registration web service) 
are those associated with the SOAP binding." 
One might be able to say a number of things:
1. the SOAP transport MUST be HTTP "origin server" and the SOAP "ultimate 
receiver" (the service receiving the data) are one and the same so:
a. the P3P policy must only be bound to the SOAP message.
b. a P3P policy will be bound to the message and its transport and both are 
normative policies on behalf of the "origin server"/"ultimate receiver"
2. the SOAP transport is unspecified (HTTP or SMTP)
a ...
b ...
...

Regardless, we're now in the complex space of "choreography" nearly, which 
will be incomprehensible to users, and difficult for engineers even. (P3P 
never took on the fact that my HTTP requests might be going through a proxy 
server and how do I distinguish between the proxy server policies and the 
origin server policies?) So my sense continues to be that we should 
identify some of the issues, but otherwise argue that it's an application's 
specification that must specify how policies are associated with the 
interactions of that application and we recommend they keep it simple and 
"higher up."

> Anyway, please tell me what do you think about them? In particular, I am
> interested in writing up an instance of linking a P3P policy with SOAP
> and WSDL in the sections of "Scope and Bindings (HTTP and SOAP)" and
> "Associating
> with a WSDL Description."

Please do! I'm going to try to put together an XML instance/example of 
associating a the P3P policy with the actual user solicitation via  XForms.

Received on Sunday, 4 May 2003 07:30:49 UTC