Revised proposal for i070 - Clarify relationship between extensibility model and policy

[Frederick Hirsch <frederick.hirsch@nokia.com>]

I suggest we modify Prateek's proposal and put this up front, in  
section 2.2, "Nested policy assertions" after line 223. (Note 3.1.3  
may be removed once WS-Policy progresses)

I propose we add the following text (incorporating Prateek's proposal):

-- startProposal--
The W3C WS-Policy submission states in section 4.4:

Two policy assertions are compatible

1. if they have the same type and

2. If either assertion contains a nested policy expression, the two  
assertions are compatible if they both have a nested policy  
expression and the alternative in the nested policy expression of one  
is compatible with the alternative in the nested policy expression of  
the other.

Thus an assertion with a nested policy element cannot match the same  
assertion without a nested policy element. This should be kept in  
mind when using assertions that have been extended with additional  
assertions that are meant to be placed within a nested policy  
element. For example, use of an extension assertion that indicates  
the presence or absence of an optional field within a security token  
may result in policy intersection failure.

A policy expresses important distinguishing criteria, thus indicating  
that they are requirements to be met in a policy compatibility test,  
limiting a successful policy match. Expressing a nested policy  
statement indicates a concern about that level of detail, with that  
specific  case requiring a more particular policy match. Allowing a  
match to an implicit statement could be risky, due to possible  
changes to the implicit choices from evolution or XML extensibility  
points. To be able to match more generally without relying on  
implicit statements,  a policy might list all legal alternatives.  
This may be eased by using wsp:PolicyReference statements referencing  
common policy definitions.  Alternatively a nested policy might not  
be used, anticipating only matching other similarly simple policy  
assertions.

--endProposal--


In effect, once some parties start specifying nested policy  
statements, all others will need to list all possibilities to enable  
matching, a negative consequence of the rule. (Is this a denial of  
service attack?)

Perhaps this committee should create a set of common PolicyReference  
policy assertions and associated URIs, to enable interoperability.

regards, Frederick

Frederick Hirsch
Nokia


On Jun 13, 2006, at 2:38 PM, ext Prateek Mishra wrote:

> Add to Section 11.2:
>
> (include after line 2372)
>
> As explained in Section 3.1.3, an assertion with a nested policy  
> element cannot match the same assertion without
> a nested policy element. This should be kept in mind when using  
> assertions that have been extended with additional
> assertions that are meant to be placed within a nested policy  
> element. For example, use of an extension assertion
> that indicates the presence or absence of an optional field within  
> a security token may result in policy intersection
> failure.
>
>