Policy Template Profile

Note: this area supports the collaborative building of a Policy Template Profile. This profile is sponsored by http://www.tscp.org

Use cases

  1. Intra-organization use case: allows policy authoring tools to create an enterprise policy structure which would be used by multiple security officers to create business specific policy instances. The policy template reduction process occurs within the policy authority
    • A policy template that has been proofed once, with respect to the access rules, can be reused over and over with different set of data, drastically reducing risk for errors
  2. In the context of secure collaboration across organizations, allows a policy authority to distribute a policy template to all contributing organizations, and template data to individual organizations that allow generating business context specific policy instances. The policy template reduction process occurs outside of the policy authority
    • Export control: the US DDTC policy authority can distribute policy templates for ITAR to organizations, letting organizations provide the parameter data that thy use to generate the business specific TAA


  1. Policy template: a XACML policy, that contains insertion points for parameters
  2. Policy template data: an artifact that provides data values for a designated policy template
  3. Policy template reduction: A transform that produces a policy by replacing parameters in a policy template with data from a policy template instance
  4. Policy template instance: a XACML policy, that is the result of the reduction of a policy template against a policy template data
  5. Policy template parameter: in a policy template, a reference to a value that will need to be substituted with actual values, provided in the policy template data
  6. Policy template engine (PTE): the component that generates policy template instances from policy templates and policy template data
  7. Static policy template reduction: the reduction is performed at administration time, and the resulting policy template instance is stored in the policy repository. PDP does not need to be aware of policy templates, as the policy template instances are processed just like any other XACML policy
  8. Dynamic template reduction: the reduction is performed at authorization time. PDP has knowledge of policy template syntax and semantics, the PDP may perform the equivalent of policy template reduction while evaluating an authorization request. Expanding template parameters in the context of an authorization request enables use of contextual data not available in static reduction

Statement of requirements

  1. The relationship of policy template to policy template instance is one-to-many (1:n)
    1. A policy template instance refers to exactly one policy template
    2. A policy template may be referred to by multiple policy template instances.
  2. Expression of the parameters:
    1. A parameter in a policy template is an <AttributeValue> element with ParameterId attribute containing a string name.

    2. A parameter in a policy template data is a <Parameter> element with a ParameterId attribute containing a string name.

      1. Each <Parameter> element may contain zero or more <AttributeValue> elements which contain actual data.

      2. In dynamic template reduction implementations, a <Parameter> element may also contain zero or more <AttributeDesignator> or <AttributeSelector> elements alongside <AttributeValue> elements. These elements are expanded into a set of <AttributeValue> elements in the context of an auth request so that parameter substitution in template reduction is still only a matter of injecting a set of <AttributeValue> elements into the policy template. This is to avoid problems where <AttributeDesignator> and <AttributeSelector> cannot be used in place of <AttributeValue>, such as in <Match> expressions.

      3. All children of a <Parameter> element must be the same data type.

    3. Each parameter used in a policy template must be defined in the corresponding policy template data. If a policy template contains a parameter that is not defined by a policy template data, reduction must fail with an error.
    4. A policy template data may define parameters that are not used by the policy template. (The data provided in policy template data may be a superset of the template requirements)
  3. Expansion of parameters.
    1. A <Match> element that contains a policy template parameter must be rewritten as a series of <Match> elements, one for each parameter value + the original <AttributeDesignator> or <AttributeSelector>, and the series combined under an <AnyOf> element. This is because a <Match> element can only contain exactly one <AttributeValue> and one <AttributeDesignator> or <AttributeSelector>. Substituting a set of <AttributeValue>s for a parameter in the first <Match> argument will produce invalid syntax.

    2. For all other cases, each use of a parameter element is replaced with a set of single-value <AttributeValue> elements of the same data type.

  4. Timing of Template Reduction
    1. Static template reduction can be performed independently and in advance of auth request evaluation and produces a policy that contains all the data values needed to evaluate the policy by the PDP. There is no implication of values to be resolved by the PDP at auth request evaluation time.
    2. Dynamic template reduction occurs in the context of an auth request evaluation and may leverage values that are known only at auth request evaluation time, such as metadata about the user making the auth request.

Implementation Options

Discussion on options for implementations to support the use cases of policy template reduction within the policy producer (use-case 1) an within the policy consumer (use-case 2)

  1. Static, at design-time in the PAP (supports use-case 1)
    • Template reduction produces a core-policy. The PRP and PDP have no knowledge of policy templates (simpler and quicker to implement)
  2. Static, at import-time in the PRP (supports use-case 2)
    • Template reduction produces a core-policy. The PRP and PDP have no knowledge of policy templates (simpler and quicker to implement)
  3. Dynamic, at request-time in the PDP (supports use-case 2)

The profile should leave B or C as an implementation decision. If a policy template data uses <AttributeDesignator> or <AttributeSelector> elements in a <Parameter> definition, the policy template can only be evaluated dynamically. If there is no use of <AttributeDesignator> or <AttributeSelector> in a policy template data, 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.


Several syntactic options are discussed here:


Several examples are discussed here:

Open Issues

  1. How to specify meta-values for parameters? Allow AttributeDescriptors/Selectors in <Parameter> elements? resolved

  2. Need to clarify use of on-permit-apply-second so <Target> can have parameters, in the <AttributeDesignator> option

Policy Template Profile (last edited 2012-10-12 09:03:53 by jean-paul.buu-sao.tscp)