RE: [xacml] Proposed Agenda for 28 June TC Meeting

[Danny Thorpe <Danny.Thorpe@quest.com>]

Jean-Paul,

I found the new wiki page you created (https://wiki.oasis-open.org/xacml/Policy%20Template%20Profile). I can help copy data points from this conversation over to the wiki page as we go.

> a. "I can see in your examples that the named parameters are injected as
> AttributeValue elements, which will satisfy XACML schema requirements but
> will not enable correct evaluation unless the PDP has specific knowledge of
> the meaning of the ParameterId attribute on the AttributeValue."


> [JP] You said "the PDP" but I assume you meant the policy-template-data-
> generator component, that IMO would be more in the area of PAP or PRP,
> than PDP. So the suggested semantics is simply based on AttributeValue
> elements name matching between the ones of the policy-template and the
> ones of the policy-data, and this specific knowledge would be restricted to
> this one (new) component, with no impact on any other
>

I think my comment crossed wires. ;>  I was observing that the proposed syntax for using parameters in a policy template (using an AttributeValue with a special ParameterId attribute) will produce a policy that will pass Xacml 3.0 core schema validation.  That's kind of nifty, but something more has to happen before the policy template can be evaluated to produce auth decisions:  either the PDP needs to understand policy template syntax and semantics, or the policy template needs to be reduced to core-spec policy syntax.

Having a formal definition of the transform needed to reduce a data+policy instance to core-spec policy syntax will be useful to illustrate how the policy template relates to core-spec policy definitions and to provide a lower-cost path for adoption for implementers.  Implementers can choose to take a minimum effort path by transforming data+policy instances at import, or with greater effort and code modification they can choose to integrate knowledge of policy templates into the PDP core evaluator.

There is a significant difference in capabilities between these two approaches.  The reduce-at-import approach is a static representation of the policy template built well before auth request evaluation time. The integrated-into-PDP-evaluator approach is capable of dynamic evaluation of named parameters in the context of an auth request.  This would address your point about parameter data changing over time.

If we want to include some aspect of dynamic evaluation of named parameters in this profile, we should make a clear distinction between static import and dynamic evaluation and segregate features by these modes.  It will be difficult to define dynamic evaluation of named parameters in a static reduced-at-import policy.  Perhaps the policy template profile should contain a static import section and a dynamic evaluation section to discuss the capabilities and limitations of each.

> b. It should be possible to transform (reduce) parameterized policies to
> traditional policies, so that the PDP does not need special knowledge to
> evaluate parameterized policies correctly.
> [JP] Exactly so, modulo the fact that, as said on 6. the reduced policies retain
> the information of their sources

The generated / reduced policy will need to have a reference back to the policy template and data+policy instance.

Which raises a question: How do we distinguish between these three forms of policy?  There is no top-level marker in the policy template <Policy> to indicate right away that this is a policy template.

Perhaps something like a Mode (or Form?) attribute:

Policy template, which uses named parameters:
<Policy  xmlns:pt="urn:policy-template-namespace"  pt:Mode="template"  PolicyId="template1" ... />

A data+policy instance, which references a policy template and defines data for named parameters:
<Policy  xmlns:pt="urn:policy-template-namespace"  pt:Mode="instance"  pt:PolicyTemplateId="template1" PolicyId="instance1"  ... />

A policy generated by reducing a data+policy instance:
<Policy  xmlns:pt="urn:policy-template-namespace"  pt:Mode="reduction" pt:PolicyInstanceId="instance1" pt:PolicyTemplateId="template1"  PolicyId="reduction1" ... />

Including the template id on the reduction is a little bit redundant since that could be found by looking up the policy instance, but worth the convenience I think.

> 
> c. Parameterized policy reduction would need to rewrite Match expressions
> that reference a named parameter to produce one Match expression per
> parameter data item and the Matches combined under an OR operator
> (AnyOf) because the attribute value of a Match expression cannot be a bag
> of values.
> [JP] So you are saying that the policy-template-data-generator component
> would potentially to expression rewrite, not only bag expansion. Seems to
> be a derived technical requirement
>

Correct - bag expansion alone of named parameters in reduction will produce invalid Match expressions.
 
Template:
<Match ...>
  <AttributeValue parameterId="country" ... />
  <AttributeDesignator .../>
</Match>

Reduced by substituting bag for named parameter:
<Match ...>
  <AttributeValue ...>US</AttributeValue>
  <AttributeValue ...>FR</AttributeValue>
  <AttributeDesignator .../>
</Match>

Or?

<Match ...>
  <Apply functionId="string-bag">
	<AttributeValue ...>US</AttributeValue>
  	<AttributeValue ...>FR</AttributeValue>
  </Apply>
  <AttributeDesignator .../>
</Match>
 

Neither of those are valid Match expressions.

Reduction must replicate the Match expression under an AnyOf to preserve Match's single-value first parameter requirement:

<AnyOf>
  <Match ...>
    <AttributeValue ...>US</AttributeValue>
    <AttributeDesignator .../>
  </Match>
  <Match ...>
    <AttributeValue ...>FR</AttributeValue>
    <AttributeDesignator .../>
  </Match>
</AnyOf>
  

> d. If a Match expression referencing a named parameter resides at the
> nesting limit of a Target expression, the expression resulting from parameter
> reduction will exceed the Target expression's limit of 3 nesting levels.
> Reduction should fail.  Caveat policy writer: Keep your Matches at level 1 or 2
> in parameterized policies.
> [JP] OK, you are establishing a requirement on a) the policy template
> authoring tool, as well as b) on the policy-template-data-generator that
> surely must produce an exception should the case arise
> 

Yes.

> e. In Condition expressions, your sample code only uses named parameter
> AttributeValues inside bag constructors.  I suggest making this a required
> pattern of use to simplify parameter reduction. Though it's a bit wordy to
> author, it works well to simplify reduction tasks. Reduction need only
> replicate the AttributeValue in-place for each parameter data item, without
> modifying any of the condition expression around it. (Nice!) Match
> expressions would be the only exception to this requirement.
> [JP] Confirming that it's expansion in most cases, but for Match expressions,
> as you said above

Yes.

Strictly speaking, though, the named parameter doesn't expand to a bag, it expands to zero or more  <AttributeValue> elements.  In condition expressions, the policy template author must place the named parameter within a bag constructor.  

This is solely to simplify the profile so we don't have to define a transform to rewrite condition expressions where a named parameter is used as an argument to a function that is expecting a single value.  

-Danny