RE: [xacml] new issue: PolicyIdentifierList scope and order

["Tyson, Paul H" <PTyson@bellhelicopter.textron.com>]

Comments inline. 

> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com] 
> Sent: Tuesday, November 24, 2009 13:54
> To: Tyson, Paul H
> Cc: XACML TC
> Subject: Re: [xacml] new issue: PolicyIdentifierList scope and order
> 
> Paul,
> 
> See inline.
> 
> 
> On 11/24/2009 08:33 PM, Tyson, Paul H wrote:
> >
> >
> >    
> >> -----Original Message-----
> >> From: Erik Rissanen [mailto:erik@axiomatics.com]
> >> Sent: Tuesday, November 24, 2009 12:56
> >> To: Tyson, Paul H
> >> Cc: XACML TC
> >> Subject: Re: [xacml] new issue: PolicyIdentifierList scope 
> and order
> >>
> >> Paul,
> >>
> >> Section 5.42 says that this includes policy sets as well. 
> So it was 
> >> always intended that they include policy sets as well.
> >>      
> > Yes, that clarifies it, but can I suggest replacing lines 2845/2846 
> > (first sentence of 5.49) with:
> >
> > ================
> > The<PolicyIdentifierList>  element contains an ordered list of 
> > identifiers of the *policies* and *policy sets* that evaluated to 
> > something other than "NotApplicable" in the process of making a 
> > decision.  The order of the identifiers shall match the evaluation 
> > order implied by the original policy or policy set.
> > ================
> >    
> 
> I think this is good, except that XACML does not specify an 
> evaluation order. There is nothing in the spec which says 
> that the PDP must evaluate the policy tree from the root to 
> the leafs and many policy combining algorithms have no 
> defined order for policy evaluation.
> 
> I think it would be mistake to require a defined order for 
> the policy identifier list since it would essentially force 
> the implementation to evaluate the policies in a particular 
> order, or to implement a separate, unoptimized code path for 
> the case where it needs to collect the policy id list. The 
> implementation overhead would be very big or there would be 
> performance impact.

I will defer to the implementors on this one.  However, even a partial
ordering would be helpful.  Since PolicySets cannot be evaluated without
first evaluating their children, can we at least specify a depth-first
ordering of Policy[Set] ids with respect to the top-level policy
structure in the PAP?  In the degenerate case where "first-applicable"
combining algorithms are used everywhere, this would result in an
ordered list of ids from the top PolicySet down to the effective Policy.

> 
> 
> >> I would prefer a separate element for the list and not use the 
> >> policy(id)reference element. These two purposes are very different 
> >> and it would be confusing if the same element can be used 
> to two such 
> >> different uses. It would make the description of these elements in 
> >> the spec more complex since two different uses need to be 
> described 
> >> in the same section.
> >>      
> > I do not see any context-specific aspects of PolicyIdReference and 
> > PolicySetIdReference.  They are pointers to a remote 
> entity, no matter 
> > where they appear.  In a PolicySet, a conformant processor must 
> > dereference the id and process the contents.  Outside of a 
> PolicySet, 
> > no behavior is specified, but I do not see why this would 
> cause confusion.
> > In a Result, these ids may be handled or ignored.
> >    
> 
> Well, I suppose you are right, but I think a dedicated 
> element with the right attributes would be better than 
> overloading an existing element, although it is only slightly.
>

OK.  We could create a type hierarchy to indicate the similarity.  New
type "PolicyIdentifierType" would extend xs:anyURI with a Version
attribute.  The existing type "IdReferenceType" would be re-defined as
an extension of PolicyIdentifierType with added EarliestVersion and
LatestVersion attributes.  New elements PolicyIdentifier and
PolicySetIdentifier would be of type PolicyIdentifierType.

This doesn't put the id in an XML attribute, as you suggested, but it
creates a sensible type hierarchy without modifying the schema too much.

Regards,
--Paul