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

[Jean-Paul Buu-Sao <jean-paul.buu-sao@tscp.org>]

1. About the mean to designate each one of the three "forms", I would rephrase your proposal, by considering that we are discussing different "types" of policies: template, data, instance. Hence it follows:

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

Policy template data, which references a policy template and associates literal data to named parameters:
<Policy  xmlns:pt="urn:policy-template-namespace"  pt:Type="data"  pt:PolicyTemplateId="template1" PolicyId="data1"  ... />

A policy template instance, which results from a reduction of a template+data pair:
<Policy  xmlns:pt="urn:policy-template-namespace"  pt:Type="instance" pt:PolicyTemplateId="template1" pt:PolicyDataId="data1" PolicyId="instance1" ... />

2. About the dynamic data: we are in agreement that this requirement is orthogonal to the requirement of parameterized policies, and I agree to keep it separate from this profile. Should we add this requirement to the list of open issues? So we are now left with a policy templates mechanism that reduces (template + data=instance), with (instance) values only containing literals

3. About the reduction mechanism: we need to spell out where the (template + data = instance) reduction can occur: 
   A. At design time in the PAP (meeting the use-case that Hal had in mind, use-case 1 on the Wiki)
   B. At import time in the PRP (meeting the ITAR/TAA use-case, use-case 2 on the Wiki) -  pro: leaving PDP unmodified, simplifying implementation
   C. At authorization time in the PDP (meeting the ITAR/TAA use-case, use-case 2 on the Wiki) - pro: allowing more options and opportunities
  
  In order to meet the two use-cases we need to consider A and (B or C), and I understand that you favor C
  The profile must call out the two use-cases (on the Wiki, I will articulate their distinctive features)
  My question is: 
    a) can we leave B or C as an implementation decision, or 
    b) should the profile be directive on either one?

Jean-Paul
  

-----Original Message-----
From: Danny Thorpe [mailto:Danny.Thorpe@quest.com] 
Sent: Saturday, June 30, 2012 02:18
To: Jean-Paul Buu-Sao; xacml@lists.oasis-open.org
Subject: RE: [xacml] Proposed Agenda for 28 June TC Meeting

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