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] Updated policy template wiki


I put in one such example on the wiki page. Search for "on-permit-apply-second" and you will find it.

Best regards,

On 2012-10-04 23:01, Jean-Paul Buu-Sao wrote:



Apologies for missing the call today, as I was in a TSCP event, together with Gerry and David of Axiomatics.

I have been much interested in the last findings, and agree that if the “template” property that we are (all, I think) looking for could be achieved with standard the <AttributeDesignator> construct, rather than introducing new concepts, then this would be for the better.

May I suggest that, in order to verify this assertion (so to speak), some folks, such as Erik or Danny, would be kind enough to propose an alternate proposal to the sample found on our Wiki (https://wiki.oasis-open.org/xacml/Policy%20Template%20Profile%20Examples)? By the way, as a word of caution, please disregard the in-correctness of the XCAML 3.0 of section 1. of the example (yes the devil is in the details, and David shown me how this example could be made compliant).


Thanks in advance,



From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Danny Thorpe
Sent: Thursday, October 04, 2012 20:11
To: Erik Rissanen; xacml@lists.oasis-open.org
Subject: RE: [xacml] Updated policy template wiki


When the original proposal for policy templates was brought forward, I noted that simply replacing a single AttributeValue element with a list of values from the policy template <Parameter> would fail in <Match> expressions, since <Match> is very explicit about one value, one designator/selector.  I offered a transform to help produce valid match expressions.


AttributeDesignator does provide similar “insert-multiple-values-here” operations to the policy template substitution behavior, but I believe the suggestion of policy parameterization came up because of situations in which AttributeDesignator cannot be used. Comparing an  attribute against a static list of test values (specific to an organization or location and applied to a generic policy), for example, is a many-to-many comparison, but cannot be expressed in a <Match> element.


As we discussed on the TC call today, we’re finding more difficulties with parameter substitution the deeper we dig. Steven Legg noted in an earlier email that some Xacml functions that take single <AttributeValue> won’t work if multiple values are dropped in to replace the <AttributeValue>. This means some sort of _expression_ transform will be necessary in condition expressions as well to move policy templates forward.


In light of these increasing complexities and challenges, I’m beginning to agree with you that perhaps the policy template use case can better be addressed using the existing <AttributeDesignator>. 


This would mean:

1.       Giving up parameterization behavior in <Match> expressions and moving that logic into conditions using <AttributeDesignator> to reference an attribute ID representing the parameterization data.

2.       Moving parameterization data from a static policy generator step to a PIP to fill <AttributeDesignator> references to a particular attribute ID with parameterization data in the PDP at auth request evaluation time.


Using <AttributeDesignator> instead of policy templates does impact the use case quite a bit because populating PIP data is not part of the Xacml spec.  Policies could be shared between organizations per the use case, but how the parameterization data is applied to those policies would become a vendor-specific implementation detail.


I can see the attraction of parameterizing policies to allow up-front synthesis of specific policies, but as we say “the devil is in the details.” The details are winning. :/




Danny Thorpe

Authorization Architect

Dell | Identity & Access Management, Quest Software


Quest Software is not part of Dell.


From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Erik Rissanen
Sent: Thursday, October 04, 2012 4:42 AM
To: xacml@lists.oasis-open.org
Subject: Re: [xacml] Updated policy template wiki



I still fail to see why this is useful.

If you take a policy template, and replace each <Parameter> with an appropriate <AttributeDesignator>, then you get a regular XACML policy, and the PEP/PDP can "fill in" the "template" at runtime using normal XACML attributes.

Why do we need a new standard? In particular I would be opposed to "implementation option C", that is a PDP would construct the policy from the template at runtime. That's lots of heavy machinery for no gain.

Best regards,

On 2012-09-20 20:25, Danny Thorpe wrote:

I’ve updated the policy template wiki (https://wiki.oasis-open.org/xacml/Policy%20Template%20Profile) with text about required Match _expression_ rewriting in parameter substitution and optional use of AttributeDesignators and AttributeSelectors in Parameter data in dynamic policy template reduction implementations.




Danny Thorpe

Product Architect | | Quest Software - Now including the people and products of BiTKOO | www.quest.com



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