W3C home > Mailing lists > Public > public-ws-policy@w3.org > March 2007

Action 216 Proposal for Addition to Guidelines Document on Nested Policy Expressions

From: Anthony Nadalin <drsecure@us.ibm.com>
Date: Wed, 28 Feb 2007 10:00:37 -0600
To: <public-ws-policy@w3.org>
Message-ID: <OF2DFFCB9C.C6CE3CC6-ON86257290.00575057-86257290.0057F2AF@us.ibm.com>

Is this really what we want ? How does one know what the choices are to
enumerate ? There should be a way that one does not have to enumerate all
choices as this could be a nightmare with all the alternatives that we have
in security policy
             "Yalcinalp, Umit"                                             
             ap.com>                                                    To 
             Sent by:                  <public-ws-policy@w3.org>           
             public-ws-policy-                                          cc 
                                       Action 216 Proposal for Addition to 
             02/19/2007 07:00          Guidelines Document on Nested       
             PM                        Policy Expressions                  

The following text is my recommendation for the guidelines document for
resolution of 4212/Action 216. This is proposed as an addendum to Section
4.4, preferably to Section 4.4.2. We may decide to update the defn of
httpsToken to be nested (following the latest Ws-SecurityPolicy).

Many thanks to Dan Roth who has reviewed and provided constructive changes
to the text.
Please do note that I have designed the example using our interop
scenerios, Round 3.
Assertion authors should note the effect of nested policy expressions on
policy intersection in their nested policy design. The result of
intersecting an assertion that contains an empty nested policy expression
with an assertion of the same type without a nested policy expression is
that the assertions are not compatible. Therefore, when providers require
dependent behaviors these behaviors should be explicitly specified as
assertions in a nested policy expression. When the definition of an
assertion allows for nested dependent behaviors, but the use of the
assertion only contains an empty nested policy expression, this specific
use indicates the specification of no nested dependent behaviors. This use
must not be interpreted as being compatible with "any" of the nested
dependent behaviors that are allowed by the assertion, unless otherwise
specified by the assertion definition.

As an example, WS-Security Policy defines sp:HttpToken assertion to contain
three possible nested elements, sp:HttpBasicAuthentication,
sp:HttpDigestAuthentication and sp:RequireClientCertificate. When the
HttpToken is used with an empty nested policy in a policy expression by a
provider, it will indicate that none of the dependent behaviors namely
authentication or client certificate is required.

        </wsp:Policy>A non-anonymous client who requires authentication or client certificate
will not be able to use this provider solely on the basis of intersection
algorithm alone.


[Issue 4212] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4212

[Action 216] http://www.w3.org/2005/06/tracker/wspolicy/actions/216


Dr. Umit Yalcinalp
Research Scientist
Email: umit.yalcinalp@sap.com Tel: (650) 320-3095
SDN: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238
"Nearly all men can stand adversity, but if you want to test a man's
character, give him power." Abraham Lincoln.

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

(image/gif attachment: pic13794.gif)

(image/gif attachment: ecblank.gif)

Received on Thursday, 1 March 2007 05:30:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:27 UTC