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

Hi Joseph,

I may not be clearly describing my message in the previous e-mail.
 
> I'd disagree, because you're scenario ALWAYS presumes that I will check
the 
> WSDL before I interact via SOAP. What happens if I already know the
service 
> and plan on using them? I have to check the WSDL every time just to make 
> sure the policy hasn't changed. I'm presently thinking:
> 1. The policy needs to be bound to the layer (application) of the data 
> solicitation and transport as closely as possible.

Let me refresh my mind: the user has its privacy preferences and the
registrar has its privacy policy. Before the user trys to bind to the
registrar's service, the user has to validate the registrar's privacy
policy by the user's privacy preferences.

If the user (registrant) knows the registrar's service well and the user
is strictly go ahead to bind to the registrar's service via SOAP, that's
fine without re-visit the registrar's WSDL document or even UDDI. I agree
with it. So now, let's forget the WSDL document.

In the existing Web services practices, the first step is the *user*
be the active body who sends the SOAP message to trigger the passive body 
*registrar* for response via the HTTP carrier. For illustration, here
is a simplified SOAP message that the user is trying to bind the registrar's
service "register."

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
 <env:Header>
 </env:Header>
 <env:Body>
  <m:register xmlns:m="http://registrar.com/register">
   <m:msg> Please register www.p3pbeyondhttp.com for Joseph </m:msg>
  </m:register>
 </env:Body>
</env:Envelope>

Let's also focus on the application layer of the data solicitation and
transport: 
SOAP messages. Let's assume that the user is going to send this SOAP message
to 
the registrar's service: you can see the *data* that have to be protected
under 
the user's privacy preferences should be "Please register
www.p3pbeyondhttp.com 
for Joseph" Then, the steps should be something like:

Step 1: User ---> SOAP Message 1: Please register www.p3pbeyondhttp.com for
Joseph ---> Registrar's servce
Step 2: Registrar's service ---> SOAP Message 2: Results(OK/Not OK) --->
User

Then, the user should validate its privacy preferences with the registrar's
privacy 
policy before sending the SOAP message 1. Agree? Then, we need to have more
steps like:

Step 0.1: User ---> SOAP Message 0.1: What is your privacy policy --->
Registrar's service
Step 0.2: Registrar's service ---> SOAP Message 0.2: Here is our WS-P3P
Policy ---> User
Step 0.3: The user (or the user agent) validates the WS-P3P policy with its
privacy preferences 
          before the user really proceeds to Step 1 or abandon its
operation.

If so, I would believe that we have to think about whether we should have
another mechanism for 
Step 0.1, 0.2, and 0.3, or embed them into Step 1? No matter where should we
go, or you have 
other scenarios, we have to think what should we put into the SOAP header or
body and when
do we need them?

I read an interesting paper recently:

    Tumer, A., Dogac. A., Toroslu. H., "A semantic based privacy framework
for web
    services" WWW'03 workshop on E-Services and the Semantic Web (ESSW 03),
Budapest, 
    Hungary, May 2003.
    
Let me try to ask Dogac for her permission before I send it to you for your
reference.

> 2. Other "layers" may have restatements of the policies. So if I'm
searching 
> for a service, I might look at the policies via UDDI or WSDL.
> 3. Any policy that is discovered must be honored. Before I was taking the 
> "higher layers trump lower layers", but I'm reconsidering that after 
> rereading [1,2] and finding those heuristics to be very elegant. (And of 
> course, what I'm presuming with respect to the WSDL/UDDI case is that
these 
> aren't different policies, just a "restatement". The WSDL description uses

> the same URI to the policy that is found in the subsequent SOAP header.)

For these two points, I don't have any problem on them as they are more on
the 
management level. They all sound reasonable and practical.

Thanks,

Patrick.

Received on Wednesday, 7 May 2003 22:39:39 UTC