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

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

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

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

> 
> And if we would change the schema, I would prefer that the 
> identifiers use XML attributes rather than child elements, like this:
> 
> <PolicyIdentifier PolicyId="foo" Version="1.0"/>
> 
> It's more compact and readable. And elements are not needed 
> since each policy identifier has a one to one mapping to the 
> two components.

If Policy[Set]IdReference cannot be re-used, I would agree with this.

> 
> Regarding your proposal that the policy id should be the id 
> which resulted in the decision, then it would be against the 
> explicit design of the original proposal. Also, it is very, 
> very complex issue the define which of the multitude policies 
> was the "significant" one. I wouldn't like to go there. At 
> least not in the 3.0 timeframe.

Yes, if you go very far with this you are returning a complete
evaluation trace, and I do not think we need to go there.  I believe it
can be a little better specified without extending the functionality.

Regards,
--Paul

> 
> Best regards,
> Erik
> 
> 
> Tyson, Paul H wrote:
> > Hi all,
> >
> > When I first saw PolicyIdentifierList in a v3 working 
> draft, I assumed 
> > it included PolicySets as well as Policies.  But now that I 
> read cd-1 
> > section 5.49 closely, I see it only mentions policies.
> >
> > My use case requires an ordered list consisting of 0 or 
> more PolicySet 
> > ids and 1 Policy id that were successfully evaluated to return the 
> > decision.  But I don't see that PolicyIdentifierList will provide 
> > this, as currently specified.
> >
> > I propose that PolicyIdentifierList be specified as an 
> ordered list of 
> > PolicySet and Policy ids that were successfully evaluated 
> to reach the 
> > decision.  Each item in the list would have the Policy[Set] id and 
> > version, as currently specified.
> >
> > Further specification might be necessary for PolicySets, to avoid 
> > ambiguity in the case where two or more children were evaluated 
> > successfully.  In this case, the final id should be the id of the 
> > policyset whose policy-combining-algorithm resulted in the decision 
> > that was returned.  I have not analyzed this much, and we 
> do not use 
> > exotic combining algorithms, so more analysis is required.
> >
> > It might be possible to use <PolicySetIdReference> and 
> > <PolicyIdReference> in this list, instead of creating new 
> element types.
> > In this context the EarliestVersion and LatestVersion 
> attributes have 
> > no meaning.
> >
> > If the IdReferenceType element types are used, the definition of 
> > PolicyIdentifierList would be:
> >
> > <xs:element name="PolicyIdentifierList"
> > type="xacml:PolicyIdentifierListType"/>
> > <xs:complexType name="PolicyIdentifierListType">
> >   <xs:choice minOccurs="1" maxOccurs="unbounded">
> > 	<xs:element ref="xacml:PolicySetIdReference"/> 
> > 	<xs:element ref="xacml:PolicyIdReference" />
> >   </xs:choice>
> > </xs:complexType>
> >
> > Section 5.50 and the <PolicyIdentifier> element could be deleted.
> >
> > Regards,
> > --Paul
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the 
> OASIS TC that 
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >   
> 
>