Re: Simplifying the meaning of assertions and wsp:optional

Hi Frederick

"Having wsp:Optional seems very useful  for allowing compact and understandable (!) policies".

I think that it's the only value of wsp:optional : that is, if you deal with compact expressions, you then can avoid typing 
alternatives and let a compact-to-normal form converter to deal with the rest.

I'd like to clarify one thing though : do you imagine policy authors creating policies manually or using tools ? I'd see tools 
playing the leading role being the dominant editing mechanism. Tool hides the complexity. I can see them editing simkle policies 
manually, but I'm doubtful they'll deal with those security policies manually...

Cheers, Sergey

----- Original Message ----- 
From: "Frederick Hirsch" <frederick.hirsch@nokia.com>
To: "ext Sverdlov, Yakov" <Yakov.Sverdlov@ca.com>
Cc: "Frederick Hirsch" <frederick.hirsch@nokia.com>; "Yalcinalp, Umit" <umit.yalcinalp@sap.com>; "Sergey Beryozkin" 
<sergey.beryozkin@iona.com>; <public-ws-policy@w3.org>
Sent: Monday, October 02, 2006 2:57 PM
Subject: Re: Simplifying the meaning of assertions and wsp:optional


+1

Against removing wsp:Optional

Removing wsp:Optional would not help since it is a shortcut to having
two policy alternatives with and without an assertion. This situation
still needs to be understood. Having wsp:Optional seems very useful
for allowing compact and understandable (!) policies, to indicate
that an assertion is optional (e.g. provider stating "this exchange
does not need to be secured, but it can be")

regards, Frederick

Frederick Hirsch
Nokia


On Oct 2, 2006, at 9:02 AM, ext Sverdlov, Yakov wrote:

> +1 to Umit. I think the optionally should stay.
>
>
>
> Just summarizing the problem and also responding on the different  email threads related to the issue 3564: “Optional Assertions 
> may  not be usable…” I think that trying to interpret the Framework  policies in the context of the requester/provider and 
> requirements/ capabilities, and to separate policy semantics with regard to  requester and provider, seems to be counterproductive 
> because of  the three fundamental problems:
>
> 1. Presence of intermediaries between requester and provider (always)
>
> 2. Multiple entities, requester and provider consist of (almost  always)
>
> 3. Bidirectional nature of messages/transactions (always)
>
>
>
> #1 and #2 were already illustrated by the HTTPS/HTTP example, which  clearly shows that a “requirement” may be imposed on the 
> requester  without taking into account the provider’s “capabilities” http:// 
> lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0179.html
>
>
>
> Let’s look at another typical example (authentication domain) to  show that the provider capabilities may not necessarily impose 
> any  requirements on the requester:
>
> A provider’s policy may specify WS-Security token with the SAML  profile as the only acceptable authentication scheme. Let’s 
> assume  that the client application “knows” about the policy. Does this  mean that the requester must generate the token and 
> attach it to  the request? I don’t think so. Some intermediary may be involved  which would generate the token from credentials 
> provided by the  requester. One can argue that the intermediary becomes the actual  “requester” but not the client app, and after 
> this we can get into  a discussion about whether the intermediary is actually a  “provider” for the client app. Just to make it a 
> little bit more  complicated – in the context of the same scenario we can specify a  second policy for the intermediary to 
> generate the WS-Security  token. So the intermediary definitely becomes the requester and the  provider at the same time.
>
>
>
> As for #3, I think the REST scenario proves the same point – that  trying to resolve these definition issues above just 
> unnecessarily  complicates things.
>
>
>
> In my previous email http://lists.w3.org/Archives/Public/public-ws- policy/2006Sep/0154.html I stated that the requester/provider 
> and  requirements/capabilities paradigm may be applicable to some policy  domains. At this point, I don’t see which policy domain 
> requires  this. The problem with wsp:optional only exists in the “requester/ provider/requirements/capabilities” context. Using 
> the ‘behavior’  and ‘subject’ concepts in conjunction with creating multiple  assertions, alternatives and policies, and using the 
> specification’s merge and intersection mechanisms, should be  sufficient to support the wide variety of use cases. The issue of a 
> policy covering one or more entities (and possible relationship  between the entities) should be (and can be) handled at the 
> policy  domain level and/or by the enterprise architecture.
>
>
>
> Email threads - I apologize in advance if I missed somebody:
>
> http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0198.html
>
> http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0205.html
>
> http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0202.html
>
> http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0172.html
>
> http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0197.html
>
>
>
> Regards,
>
>
>
> Yakov Sverdlov
>
> CA
>
>
>
>
>
> From: public-ws-policy-request@w3.org [mailto:public-ws-policy- request@w3.org] On Behalf Of Yalcinalp, Umit
> Sent: Sunday, October 01, 2006 8:37 PM
> To: Sergey Beryozkin; public-ws-policy@w3.org
> Subject: RE: Simplifying the meaning of assertions and wsp:optional
>
>
>
> A Big -1 to dropping Optionality. It is completely backwards  incompatible with the current practice and existing assertions. Our 
> charter indicates that we should retain backwards compatibility as  a goal.
>
>
>
> Explaination of what it is should not require us to drop the  functionality.
>
>
>
> I will write more about some wording suggestings in a different email.
>
>
>
> --umit
>
>
>
>
>
> From: public-ws-policy-request@w3.org [mailto:public-ws-policy- request@w3.org] On Behalf Of Sergey Beryozkin
> Sent: Friday, Sep 29, 2006 9:05 AM
> To: public-ws-policy@w3.org
> Subject: Simplifying the meaning of assertions and wsp:optional
>
> Hi there
>
>
>
> After reading and reflecting on a lot of interesting messages on  what wsp:optional means, on what is the differences between 
> requirements and capabilities are and what provideres and  requestors should do about various types of assertions, I'd like to 
> offer to your attention a modest proposal on simplifying the way  assertions and wsp:optional are covered in the WS-Policy 
> Framework  and primer/policy guidelines. This is all really based on what I've  learnt form the others while reading those emails 
> and from the spec...
>
>
>
> The following is how (in a simplistic way) we might want to talk  about assertions and wsp:optional.
>
>
>
> 1. Any policy assertion, either marked as optional or not, is first  and foremost is a requirement. It's a requirement to a 
> requester to  understand it and do something about it. What is it that a  requester should do is part of a policy assertion 
> documentation/spec.
>
> In many cases a requirement would require a requester to make a  commitment to engage in some kind of activity (direct or out-of- 
> band) during the interaction.
>
> Alternatively, a requirement can simply be "to understand it and  use it for choosing a given provider among other providers". In 
> a  sense, a requester should do nothing here but use it during the  selection process, and this in itself encapsulates a 
> requirement :  an ability to use it during the selction process.
>
>
>
> Requirement is a capability and should be used interchangeably.  It's a capability because it is something a provider knows about 
> and can do something about. It's a requirement because a client  needs to do something about it (engaing in a behavior, using for 
> selction, etc )
>
>
>
> 2. Assertion may or may not be optional. This *only* means that a  requester is given an option to ignore a given requirement. No 
> assertion can be ignored by a provider. Provider is guaranteed to  support all assertions. Optionality is something which is only 
> for  a requester to worry about.
>
>
>
> 3. Assertions must be understood by both parties. Spec says about  it already, but it's worth highlighting it.
>
>
>
> Given above 3 points, we can state that an assertion like  sp:HttpsToken and oasis:replyInTenSecs are equal WS-Policy citizens 
> because in both cases there's something a client can do about them.  In the former case
>
> a client will understand that it needs to use HTTPs in order to be  able to talk a provider. In the latter case a client will 
> understand that a service is very responsive and might use this  fact as a basis for choosing this provider among others.
>
>
>
> Now about wsp:optional (based on above 3 points).
>
>
>
> Two options are proposed :
>
> Option1. Retain wsp:optional but explain that wsp:optional is just  a syntactic shortcut to nominate a requirement as being 
> optional  for a requester to understand/do anything about. As well captured  elsewhere, at the moment an optional "capability" in 
> a compact form  suddenly becomes a requirement in a normal form. This is confusing.  wsp:optional is a way to nominate an optional 
> requirement.
>
>
>
> Option2. (Preferred) Drop wsp:optional altogether. Why ? Because  IMHO it doesn't bring anything useful but the complexity. It 
> makes  it more complex for a policy engine to convert a policy alternative  from a compact form to a normal one, and for policy 
> authors to  understand how to work with it and when it's appropriate to use it.
>
> Lets explain clearly that for a given assertion/requirement be  optional it should be avalable in one alternative and not in the 
> other one and this is all... It will add a bt more work for a  policy author, but IMHO not a lot.
>
>
>
> Finally :
>
>
>
> Point 2 above refers to oasis:replyIn10Secs assertion. A client can  not really do  something about it as far as the interaction 
> is  concerned, but it still can do something about it : use it to  select a provider, for ex. For such assertions not to interfere 
> with those policy-aware clients which are not aware of what  oasis:replyIn10Secs means and which may or may not have some priory 
> polic requirements, we should recommend that when possible, policy  authors should attempt to give an option to ignore such 
> assertions  by using policy alternatives as appropriate. Note no 'optional'  qualifier is used here :-)
>
>
>
> So that's it... Does it make it a bit simplier ? Criticize away  please :-)
>
>
>
>
>
> Cheers,
>
> Sergey Beryozkin
>
> Iona Technologies
>
>
>
>
>
>

Received on Monday, 2 October 2006 14:36:21 UTC