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

[Erik Rissanen <erik@axiomatics.com>]

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 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.


>> I don't know whether it is necessary to keep the "namespaces"
>> of policy and policy set identifiers separate. If so, we
>> should add a second element for the list.
>>      
> In my use case it is necessary to distinguish between Policies and
> PolicySets.  Because of our limited use of combining algorithms, there
> will only be one Policy in the list, and if that is always the last
> element in the list we can assume it is a Policy.
>
> However, that will not work in the general case.  There could be several
> non-NotApplicable Policies, so it would be helpful to distinguish
> between Policy ids and PolicySet ids.
>    

I think it probably a good idea to separate them out since they are 
separate everywhere else in the XACML spec and schema. There might be 
surprises ahead out there in the wild if we break this convention.

Best regards,
Erik