RE: Policy expressions with no wire manifestation

I agree with Maryann that "... whether or not (assertion) is required on
the wire is a facet of the behavior associated with the assertion...",
and that "...the assertion authors will need to define the semantic of
the behavior..."  I agree with Tony that "require [policy assertions] to
use wsp:optional is ... wrong" and with Prasad that "...in any case
marking assertions with no wire manifestation 'optional', is not correct
as optional is reserved for behaviors that are optional to engage..." 

 

At the same time, I don't think it is correct to consider the optional
policy assertions "... from the perspective of the provider (Prasad)". I
don't think that the specification should separate policy semantics with
regard to requester and provider; nor do I think that the specification
should attempt to cover specific requester/provider behaviors such as
"requester knows about provider policy", "provider advertises a policy",
etc. In my opinion, the specification should be dealing (as it does now)
strictly with policy subjects, behaviors and resultant policies, and
doing so irrespective of how these policies can be used/enforced/applied
by entities. 

 

One reason for this is that both requester and provider may be
represented by multiple entities, as I indicated in the use case
attached to the CQ 3672. Let's look at the provider in the scope of the
specification. In the fairly typical scenario for a web service message
processing in an enterprise, the following eight logical entities may
constitute a provider:

1.       Some gateway functioning as a reverse proxy

2.       Web server

3.       PEP running in the web server process space

4.       Application server plugin also running in the web server
process space (forwarding request to the application server)

5.       Application server

6.       PEP running as a plugin in the application server process space
(WebSphere TAI, for example)

7.       Servlet/bean, which actually implements web service  

8.       PDP/policy processor may also belong to the "Provider" category

 

There may be arbitrary combinations of policy/subject/entity for
different policy domains in this scenario. The same policy/subject may
be applicable to more than one entity. An entity itself may represent a
policy subject, and an entity may have policies with different subjects
associated with it. During this interaction, a policy may be enforced
and/or applied by any provider entity above - potentially by more than
one. If any transport translation is involved (as in the Ashok's JMS use
case), the number of provider entities may change.

 

I think the specification in its current state covers this and other use
cases by focusing on the policy subject and the behavior, indicated by
an (optional) policy assertion. 

 

In no way am I advocating a "ban" on the usage of the "requester" and
"provider" terms:-) I just think that for some policy domains, such as
authentication and RM, these terms are necessary. For other domains,
such as authorization and privacy, the requester/provider paradigm may
have some limited usage; for threat and audit domains, it may be
irrelevant and/or inapplicable. Policy domain authors are free to define
any requester/provider semantics, which are specific for a particular
domain. That's how the specific and legitimate issues brought up by
Prasad, Sergey and William can be addressed.

 

The Primer may provide some non-normative information about different
use cases and possible policy enforcement implications.

 

Regards,

 

Yakov Sverdlov

CA

 

________________________________

From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Maryann Hondo
Sent: Friday, September 22, 2006 12:22 PM
To: Prasad Yendluri
Cc: Anthony Nadalin; Mark Little; public-ws-policy@w3.org;
public-ws-policy-request@w3.org; Sergey Beryozkin; William Henry
Subject: RE: Policy expressions with no wire manifestation

 


I hope that all of you will review and comment on the guidelines
document, as this is the kind of thing Umit and I were trying to 
address with our proposal.  In my opinion, the normative text in the
specifications gives the syntax for optional, and its role in
normalization. 
The assertion authors will need to define the semantic of the behavior. 

Maryann 



Prasad Yendluri <prasad.yendluri@webmethods.com> 

09/22/2006 11:46 AM 

To

Sergey Beryozkin <sergey.beryozkin@iona.com> 

cc

William Henry <william.henry@iona.com>, Maryann Hondo/Austin/IBM@IBMUS,
Anthony Nadalin/Austin/IBM@IBMUS, public-ws-policy@w3.org,
public-ws-policy-request@w3.org, Mark Little <mark.little@jboss.com> 

Subject

RE: Policy expressions with no wire manifestation

 

 

 




Fundamentally we need to distinguish between (i) capabilities that a
provider advertises and (ii) the requirements on the clients the
provider specifies. The optional nature really applies to the latter
(viz. requirements). Just because a requirement does not have wire
manifestation, it cannot be marked "optional". What if a provider has a
requirement to store the records of the interaction (audit log) for a
specified amount of time, by the client (and the provider). This is not
"optional" and is "required" by the provider, as a clause for resolution
of a dispute, should one arise later.  This does not result in any wire
manifestation but it is not an optional behavior. 
  
The fact that a requirement (assertion) does not result in wire
manifestation should be (is expected to be) available from the
specification of the assertion (type). Similarly if an assertion is a
capability or a requirement should also be part of the specification of
the assertion (type). 
  
In any case marking assertions with no wire manifestation "optional", is
not correct as optional is reserved for behaviors that are optional to
engage, from the perspective of the provider. 
  
Regards, 
Prasad 
  

 

________________________________


From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Mark Little
Sent: Friday, September 22, 2006 5:30 AM
To: Sergey Beryozkin
Cc: William Henry; Maryann Hondo; Anthony Nadalin;
public-ws-policy@w3.org; public-ws-policy-request@w3.org
Subject: Re: Policy expressions with no wire manifestation 
  
Ah, my fault. I thought you were advocating adding <oasis:QOSGuarantee/>
as well! 
  
Mark. 
  
  
On 22 Sep 2006, at 13:15, Sergey Beryozkin wrote: 


Hi 
  
Can you please elaborate a bit more on what you mean. 
I was actually advocating that assertions with no associated behavioural
requirements (to entites which may consume them) should be marked with
wsp:optional so that not to limit services' reach which may be using
such assertions and the only actual proposal was for that guidelines for
policy authors be amended acoordingly. 
  
Have you interpreted my message differently ? If no then what problems
do you see with using wsp:optional in cases like this ? 
  
Thanks, Sergey 
  
I can see some advantages and disadvantages to this. I like and agree
with the intention. However, as William pointed out, this can be
accomplished already, albeit in a slightly skewed way using
wsp:optional. But obviously that should prevent us trying to fix a
perceived deficiency in the specification. Unfortunately I think this
could be a major can-of-worms, worthy of its own specification! 
  
Mark. 
  
  
  
On 22 Sep 2006, at 11:03, Sergey Beryozkin wrote: 


Minor omission : 
  
"Making such policy assertion as <oasis:QOSGuarantee>  would
unnecessarily limit the audience of this service." 
  
I missed a phrase there, should be 
  
"Making such policy assertion as <oasis:QOSGuarantee> *non-optional*
would unnecessarily limit the audience of this service." 
  
Cheers, Sergey Beryozkin 
Iona Technologies 
----- Original Message ----- 
From: Sergey Beryozkin <mailto:sergey.beryozkin@iona.com>  
To: William Henry <mailto:william.henry@iona.com>  
Cc: Maryann Hondo <mailto:mhondo@us.ibm.com>  ; Anthony Nadalin
<mailto:drsecure@us.ibm.com>  ; public-ws-policy@w3.org
<mailto:public-ws-policy@w3.org>  ; public-ws-policy-request@w3.org
<mailto:public-ws-policy-request@w3.org>  
Sent: Friday, September 22, 2006 10:51 AM 
Subject: Re: Policy expressions with no wire manifestation 
  
Hi all, 
  
After thinking a bit more about policies which express capabilities with
no wire manifestations and no associated behaviours expected from a
consumer of such policies, I came to some conclusion. 
  
Here's an example : 
  
wsp:Policy> 
  <wsp:ExactlyOnce> 
      <wsp:All> 
         <!--- security assertion --> 
         <sp:HttpsToken/> 
      </wsp:All> 
      <wsp:All> 
         <!-- capability assertion -->
        <oasis:QOSGuarantee> 
           <NeverEverFails/> 
        </oasis:QOSGuarantee> 
         <!--- security assertion --> 
         <sp:HttpsToken/> 
      </wsp:All>
  <wsp/ExactlyOnce> 
<wsp:Policy> 
  
A policy designer wishes to tell to ws-policy aware entities out there
that they must be able to use HTTPS should they attempt to start
communicating with the service. 
Futhermore, a policy designer wishes to tell that the service has a
well-known capability to never fail, but is careful to ensure that the
entities not aware of what this means but still meeting a key
requirement of being able to use HTTPS can still enjoy communicating
with this service. A policy author achives this by creating two policy
alternatives. 
The reason is simple : <oasis:QOSGuarantee> assertion is not a
requirement but a capability which has no wire manifestations and
behavioural requirements for the entities which can understand what it
means. 
  
In fact, the above expression, being in a normal form, is equivalent to
this compact expression : 
  
wsp:Policy> 
  <wsp:ExactlyOnce> 
       <sp:HttpsToken/> 
        <oasis:QOSGuarantee wsp:optional="true"> 
           <NeverEverFails/> 
        </oasis:QOSGuarantee> 
   <wsp/ExactlyOnce> 
<wsp:Policy> 
  
Making such policy assertion as <oasis:QOSGuarantee>  would
unnecessarily limit the audience of this service. A requester entity
should never fail if it does not understand what <oasis:QOSGuarantee>
given the fact the only thing it can ever do with it is to note that
this service posesses the advertised quality and see whether it meets
its selection criteria or not. 
  
For example, if a requester searches for services which are known to
publish its message logging traces to a well known external site it
shoud be sufficient for it to be able to recognize a well known
<common:publishTraces href="..."/> rather than fail due to the fact
<oasis:QOSGuarantee/>  is not recognized. Likewise those searching for
never failing services should be able to consume those who assert it and
not fail should they not recognize <common:publishTraces href="..."/>. 
  
This brings me to a simple conclusion : Policy authors SHOULD be
encouraged to use wsp:optional when using policy asssertions which
advertise capabilities with no associated behavioral requirements and
wire representations in order to widen the service's audience and
improve interoperability. wsp:optional means here that it's a capability
which *may* be used for a service selection. I believe guidelined for
policy authors should be updated. 
  
At the moment the WS-Policy Framework (primer) uses wsp:optional to mark
assertions which identify behaviours which *may* be engaged. It refers
to such assertions as 'capabilities'. IMHO it's not the best/too broad
the definition and it will cause confusions. For ex :
<mtom:OptimizedMimeSerialization wsp:optional="true"/>. I feel it's
better be additionally categorised as an optional requirement. 
  
Any thoughts or objections ? 
  
Likewise an assertion like <sp:MustSupportRefKeyIdentifier />  does not
fall into this category because a policy author *requires* a consuming
entity to understand it, ortherwise the secure processing on either side
will fail. 
  
Thanks, Sergey Beryozkin 
Iona Technologies 
  
  
It is my understanding that people are using the wsp:optional to handle
this. So if the requester (consumer) doesn't know about it they can
ignore it. 
  
This works BUT it is really using wsp:optional in an unintended way. The
truth is that such an assertion is not really optional it's only
optional in the sense that the requester can ignore it however the
provider must be providing this level of service and the requester must
do nothing - so in that sense it really isn't optional it's just a handy
use of the wsp:optional. 
  
This is one of the reasons I think there could be another attribute
missing (like the wsp:local). 
  
Another reason for having such an attribute would be for the generic
engine to be able to handle such a thing consistently in all
implementations. e.g. if I had a wh:local then I'd be forcing the
requester to either know about my namespace or assume that they can't
use this service. I think it can just make things messier than they need
to be. 
  
Having said all that I understand the effort that introducing a new
attribute would mean and seeing as you can get a similar affect using
things like wsp:optional (albeit in an unintended way) I expect push
back on the idea. 
  
Regards, 
William 
  
On Sep 20, 2006, at 11:46 AM, Beryozkin, Sergey wrote: 


Hi Maryann, others 
  
this is most helpful... 
  
"I would note that if you're "using the assertion for selection", it
could 
imply that you know what it is." 
  
Ok, I think I start understanding it (fingers crossed :-)). A requester
runtime may be required to select services which are highly available.
It expects providers to advertize well-known <oasis:HighlyAvailable/>
assertions. If a provider advertizes a policy which have no
<oasis:HighlyAvailable/> assertions then the intersection will fail. I
think it's reasonable. 
  
Now consider a different case. 
A requester runtime has no priori policy requirements. However it
understands all well-known security assertions but no others ones. It
has found a service which requires that a requester supports some
security policies. 
  
Futhermore, a provider wishes to advertize some of its capabilities,
namely that it's the best service around. A requester does not know yet
about such assertions and is not even planning to use assertions like
this for services selection. 
  
How would we do it ? 
  
Like this  ? : 
  
<wsp:Policy> 
  <wsp:ExactlyOnce> 
      <wsp:All> 
         <!--- security assertion --> 
         <sp:HttpsToken/> 
      </wsp:All> 
      <wsp:All> 
         <!-- capability assertion -->
        <oasis:QOSGuarantee> 
           <TheBestServiceInThisCategory verifiedBy="..."/> 
        </oasis:QOSGuarantee> 
         <!--- security assertion --> 
         <sp:HttpsToken/> 
      </wsp:All>
  <wsp/ExactlyOnce> 
<wsp:Policy> 
  
Thanks, 
Sergey Beryozkin 
Iona Technologies 
  
----- Original Message ----- 
From: Maryann Hondo <mailto:mhondo@us.ibm.com>  
To: Sergey Beryozkin <mailto:sergey.beryozkin@iona.com>  
Cc: Anthony Nadalin <mailto:drsecure@us.ibm.com>  ;
public-ws-policy@w3.org <mailto:public-ws-policy@w3.org>  ;
public-ws-policy-request@w3.org <mailto:public-ws-policy-request@w3.org>
; Sergey Beryozkin <mailto:sergey.beryozkin@iona.com>  
Sent: Wednesday, September 20, 2006 2:17 PM 
Subject: Re: Policy expressions with no wire manifestation 
  

Sergey, 
I responded to your other mail ...so this is a bit of a repetition. 

In the guidelines document, Umit and I have attempted to capture
"observations" about the use of optional, and this might 
be a case where it would be useful.  I would note that if you're "using
the assertion for selection", it could 
imply that you know what it is. Whether or not it is required on the
wire is a facet of the behavior associated with the assertion. 
Each set of authors is given a set of tools by the specifications, but
the authors need to craft the assertions. 

Maryann 

"Sergey Beryozkin" <sergey.beryozkin@iona.com
<mailto:sergey.beryozkin@iona.com> > 
Sent by: public-ws-policy-request@w3.org
<mailto:public-ws-policy-request@w3.org>  

09/20/2006 05:35 AM 

 

To

"Sergey Beryozkin" <sergey.beryozkin@iona.com
<mailto:sergey.beryozkin@iona.com> >, Anthony Nadalin/Austin/IBM@IBMUS 

cc

<public-ws-policy@w3.org <mailto:public-ws-policy@w3.org> >,
<public-ws-policy-request@w3.org
<mailto:public-ws-policy-request@w3.org> > 

Subject

Re: Policy expressions with no wire manifestation


  

 

  

 





Hi there 
 
That was a response in a hurry so I take it back. Before flooding the
group concalls with trivial issues I'd rather attempt to make my
question as clear as possible. Note that I may indeed be confused, but
if so then I'd appreciate an answer which would help. 
 
Consider this example : 
 
<wsp:Policy> 
  <wsp:ExactlyOnce> 
        <oasis:QOSGuarantee> 
             <NeverFails/> 
             <TheBestServiceInThisCategory verifiedBy="..."/> 
        <oasis:QOSGuarantee> 
  <wsp/ExactlyOnce> 
<wsp:Policy> 
 
This is an example of a policy with a single alternative. This
alternative contains non-optional assertions 
defined by a policy profile spec published a month ago. These assertions
have no wire manifestations. 
A ws-policy aware (requester) entity whose runtime has not been updated
yet to recognize <oasis:QOSGuarantee> is about to start communicating
with the service which advertizes this policy. 
 
Given the fact that it's likely ws-policy aware requesters will refuse
to start talking to a service should they fail to support the above
policy and that the fact whether this requester supports this policy or
not will have no effect on the actual communication with the service
this policy attached to, my understanding is that such assertions with
no wire manifestations SHOULD be marked as wsp:optional : 
 
<wsp:Policy> 
  <wsp:ExactlyOnce> 
        <oasis:QOSGuarantee wsp:optional="true"> 
             <!-- --> 
        <oasis:QOSGuarantee> 
  <wsp/ExactlyOnce> 
<wsp:Policy> 
 
This means a requester may use this policy for a service selection but
doesn't need to refuse talking to this service should it fail to
recognize the policy. 
 
Does it make sense ? 
What is the group's position on this issue ? 
 
Thanks 
 
Sergey Beryozkin 
Iona Technologies