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:  <mailto:sergey.beryozkin@iona.com> Sergey Beryozkin

To:  <mailto:william.henry@iona.com> William Henry

Cc:  <mailto:mhondo@us.ibm.com> Maryann Hondo ;
<mailto:drsecure@us.ibm.com> Anthony Nadalin ;
<mailto:public-ws-policy@w3.org> public-ws-policy@w3.org ;
<mailto:public-ws-policy-request@w3.org> 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:  <mailto:mhondo@us.ibm.com> Maryann Hondo

To:  <mailto:sergey.beryozkin@iona.com> Sergey Beryozkin

Cc:  <mailto:drsecure@us.ibm.com> Anthony Nadalin ;
<mailto:public-ws-policy@w3.org> public-ws-policy@w3.org ;
<mailto:public-ws-policy-request@w3.org> public-ws-policy-request@w3.org ;
<mailto:sergey.beryozkin@iona.com> Sergey Beryozkin

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" < <mailto:sergey.beryozkin@iona.com>
sergey.beryozkin@iona.com> 
Sent by:  <mailto:public-ws-policy-request@w3.org>
public-ws-policy-request@w3.org

09/20/2006 05:35 AM


To

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


cc

< <mailto:public-ws-policy@w3.org> public-ws-policy@w3.org>, <
<mailto:public-ws-policy-request@w3.org> 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