RE: Simplifying the meaning of assertions and wsp:optional

+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