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

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

> 
> There are still two aspects that concern me though:
> a) You keep referring to the PDP as the component doing the policy template
> reduction, where I assumed that this component can leave outside of the
> PDP, for instance to allow a zero impact on existing PDP. This is the reason
> why I introduced this Policy Template Engine, that can physically reside in the
> PDP but could be outside, such as in the PRP or PAP; and yes, I suggest that
> reduction yields a core-spec policy, with the only caveat that this core-spec
> contains information on the sources of the reductions (this info does not
> affect the core evaluation for authorization, and is just needed for change-
> management))

I see two ways to implement policy templates:  
  1. Reduce policy template syntax to core-spec policies upon import to the policy repository.  The policy repository and the PDP have no knowledge of policy templates.
  2. Support policy template syntax directly in the PDP. 

Whenever I refer to the PDP engaging with policy templates, I am referring to the 2nd case.  

I see the value of having option #1 as a least impact path to supporting policy templates.  For my own work, if I were to pursue implementing policy templates I would be more likely to follow option #2 as it inherently provides more options and opportunities.

> 
> b) We are in agreement on the two distinction of static vs. dynamic
> reduction; however I assumed that the dynamic reduction is orthogonal to
> policy templates: it could very well be  a capability that makes sense outside
> of a policy template, as a substitute for any literal value in existing (non
> templatized) policies. I think that this is healthier to keep this dynamism
> separate of policy templates, as dynamic resolution has, by definition, to
> occur in the PDP, whether the policy has been reducted or not
> 
> I agree that two approaches are possible (PTE on the PAP/PRP, or on the
> PDP), but if we make the two capabilities of reduction and dynamic literal
> expansion independent, then reduction can use either approach, whereas
> dynamic literal substitution must be implemented in the PDP. Again, and this
> is a question: does dynamic literal expansion a capability that can exist
> outside of templates? I think yes but need confirmation. Example of a
> dynamic literal expansion: the string "$EU" (or whatever makes sense) is
> expanded, at authorization time, to a bag that currently (in 2012) contains 27
> literal country codes.

If your dynamic literal expansion is orthogonal to policy templates, then it should be considered in a separate discussion and profile.

I'm not convinced that XACML needs "dynamic literal expansion"; that's what AttributeDesignators are for.  AttributeDesignators are not limited to fetching attributes provided in the auth request - they can fetch data from any data provider available to the PDP context handler. 

Here's how:
1. Define an attribute Id to represent your data-to-be-determined-at-evaluation-time (urn:EU-country-codes)
2. Write policy using AttributeDesignators to select that data
3. Configure your PDP context handler with a PIP or DB to provide data values for that attribute Id to the PDP
4. When the PDP evaluates that policy for an auth request, it will discover the AttributeDesignator(urn:EU-country-codes) and ask the context handler to resolve that attributeId into a bag of values.
4. Presto, dynamic data.  

The data will always be current because the PDP context handler / PIP / DB have an opportunity to present new country codes on every auth request handled by the PDP.  So when the PDP receives an auth request at 12:01am Jan 1, 2013, it will be up to your DB to return the 28 EU country codes valid at that date.  (If Jan 1 is the activation date)

Granted, step #3 above does step outside the normative text of the XACML spec, but it is within the overall XAMCL system architecture diagram.  If what you really need is a vendor-independent way to define attribute Ids and their values to work with any conforming PDP implementation, I'd be more inclined to explore a new profile in the PIP area of the diagram than a macro substitution scheme.

> 
> Thank you for your detailed analysis on what must happen on reduction of
> Match expressions. I let you report these findings in a new section of the
> Wiki, such as "Technical implications" or equivalent.
>

Ok, I'll update the wiki with Match expression transform details.

-Danny