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

Hi Joseph,

I got some comments about the "chunks" that we'll want to 
address. I am still trying to catch up with you guys' work
in the P3P working group. :-)

Please let me try to describe a scenario as follows:

A Web services "requestor" (consumer or application) is looking 
for a Web service at the UDDI or even directly consult the WSDL 
document of the Web service. Thus, the Web services "provider" 
should put the Web service's privacy policy in both UDDI and WSDL 
level. After the requestor/service-locator found the Web service, 
the requestor/service-locator would also validate with the Web 
service's privacy policy based on the requestor's preferences and 
check whether the privacy policy is acceptable or not. Once the 
Web service's privacy policy is acceptable, the requestor would 
try to bind to the Web service. At this moment, the only way for 
the provider to understand/know the requestor's privacy policy is 
through the SOAP message. By any mean, the provider has the right 
to accept/reject the SOAP request if the requestor's privacy policy 
is/is-not acceptable with the providor's preferences. 

If we agree such an scenario, the first task for us is to check 
the research issues in the existing UDDI, WSDL, and SOAP. Here
are some of my primitive thoughts...

UDDI
====
I think we should have privacy policies defined in the <businessEntity/>
and/or <businessService/>. If so, we may also have to look into those 
related XML languages for finding the Web services in UDDI, e.g., Web 
Service Inspection Language (WSIL) in the future.
------------------------------------------------------------------------

SOAP
====
Yes, the privacy policy or compact policy file should be specified in 
the SOAP header.
------------------------------------------------------------------------

WSDL
====
A new attribute, say policyref="URI Reference" such as the idea of 
<Policy-Ref/> in P3P, is needed in the <definitions /> element or we 
can propose a new element <privacy/> in the WSDL document. However, 
I would perfer to make it as an attribute. For instance, this 
***policyref*** can be referenced to a P3P policy, a P3P compact policy, 
or even a P3P-based WS-Privacy policy (?) in the future.

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


In particular, we need more thoughts/ideas about the requirement AR020.5
in the "Web Services Architecture Requirements" in an intermediary scenario
or I would like to name it as a loosely coupled Web services execution
scenario.
Beside the S030 Third party intermediary scenario of the Web Services
Architecture 
Usage Scenarios, AR020.6 is strongly related to workflow/business process
integration 
issues. I am currently thinking about it...

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? It may be much
clearer
and useful if there is a few examples to demonstrate the importance of
AR020.6.


There are two typos in the draft:

(1) Referring to the "The Movement of Information" section:
    data propogation 
             ^ -> propagation 
        
    policy propogation 
               ^ -> propagation

    preference propogation 
                   ^ -> propagation

(2) The p3p:RECIPIENT Value and Data/Preference Progrogation
                                                ^^^^^^^^^^^^ -> Propagation?



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

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.

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

Thanks and talk to you soon.

Patrick.

-----Original Message-----
From: Joseph Reagle [mailto:reagle@w3.org]
Sent: Saturday, 26 April 2003 6:29 AM
To: public-p3p-spec@w3.org
Subject: [BH] First (Very Rought) Outline of Beyond HTTP




As stated, I've tried to put together an outline [1] that hopefully gives a 
sense of the goals, the scenario, and the "chunks" that we'll want to 
address.

[1] http://www.w3.org/P3P/2003/p3p-beyond-http/Overview.html

I welcome comments on *anything* including any of the above, or volunteers 
to take a stab at:
1) Feel like writing up an instance of linking a P3P policy with an XFORM 
(xlink?), SOAP message or WSDL definition?
2) Writing text for one of the chunks?

For any examples or schemas that we use, I'd like to accept those as 
discrete self-validating files [1]. I've previously written a python script 
that when given a XML PI (processing instruction) can then take an excerpt 
from a remote XML file and include it in the spec. That way we don't have 
to maintain examples in the spec and as seperate files, with errors 
creaping into each, but particularly those in the spec.

[2] http://lists.w3.org/Archives/Public/spec-prod/2003JanMar/0007.html

Received on Thursday, 1 May 2003 02:34:34 UTC