OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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


Section 5.42 says that this includes policy sets as well. So it was 
always intended that they include policy sets as well.

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

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.

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.

Best regards,

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 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]