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

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

The profile should leave B or C as an implementation decision.  Until such time as a profile names specific features or functions that can only be implemented by evaluating the policy template at request time, policy template handling can be entirely defined by the static reduction process (B).  

The (C) option can be noted as an implementation possibility in the profile text with a requirement that it produce equivalent auth decision results as if the policy template had been reduced to a simple policy per the profile spec. The XACML core spec uses language like this in several places to allow implementations to deviate from the examples as long as they produce equivalent results. 

An example of a feature which would require evaluation of the policy template in the PDP at request time:  If the policy template data format were extended to allow AttributeDesignator or AttributeSelector elements in Parameter definitions alongside simple attribute value elements.  Such constructs cannot be expanded at policy design time (A) nor at import time (B) because their values will vary per auth request.

-Danny

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

> -----Original Message-----
> From: Jean-Paul Buu-Sao [mailto:jean-paul.buu-sao@tscp.org]
> Sent: Saturday, June 30, 2012 1:21 AM
> To: Danny Thorpe; xacml@lists.oasis-open.org
> Subject: RE: [xacml] Proposed Agenda for 28 June TC Meeting
> 
> 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