Re: [xacml] Dynamic Attributes versus Existing Attributes

The XACML core specification allows some leeway in how a context handler obtains attributes
and in my implementation the context handler doesn't attempt to obtain attributes from a PIP
if those attributes were supplied in the request (this gives the PEP some control over the
request context). So PEP attributes override PIP attributes. With that in mind ...

I had intended that an optimal implementation of a co-located DAA would be able to continue to
use the same request context for evaluating the final request against regular policies that
had been constructed while evaluating the initial request against the DA policies. This is to
avoid having to actually construct an explicit final request and rebuilding the request
context from scratch. However, I've come across an issue in how the merge strategy would
work when the attribute being merged is not in the initial request but fetched from a PIP. It
makes a difference whether or not the DA policies happen to evaluate the attribute.

Suppose that some DA policy references the attribute with an attribute designator that is
evaluated during processing by a co-located DAA. Since the attribute is not in the request the
context handler will try to fetch the attribute from the PIPs. Suppose that it finds some
values and adds them to the request context. By the end of processing the DAA generates some
include obligations for some more values for the same attribute. The context handler processes
the obligations and adds the values to the attribute in the request context (in lieu of
creating an explicit final request), which now has both the values fetched from the PIP and
the values generated by the DAA. Attribute designators in regular polices will return a bag
containing both collections of values.

Suppose instead that the DAA doesn't have a policy that references the attribute or doesn't
need to evaluate any policy that does. At the end of DAA processing the attribute hasn't been
fetched into the request context. The context handler processes the obligations and adds the
values to the attribute in the request context, which this time only has the values generated
by the DAA. Attribute designators in regular polices will return a bag containing only the
generated values. While it is expected that results will vary depending on what attribute
designators evaluate to, it is isn't expected that results will vary depending on whether an
attribute designator is evaluated at all.

Attribute designators in regular polices will also return a bag containing only the generated
values if a standalone DAA is used because any attributes it fetches from a PIP will go into
its own request context that the context handler doesn't see. It is also the case with an
explicit final request since a dynamic attribute in the final request will stop my context
handler fetching that attribute from a PIP.

The final processing step in the latest DAA draft talks about merging the dynamic attributes
into the request context but it should talk about merging the dynamic attributes into the
initial request as mentioned elsewhere in the draft since the state of the request context is
uncertain. Implementors need to work out the consequences on the request context for their
own implementation strategy. A "PEP overrides PIP" context handler with a co-located DAA
needs to be able to tell the difference between values that came from the PEP and values that
came from the PIPs so that values that came from a PIP can be discarded (overridden) when
merging dynamic attributes into the request context. An alternative context handler
implementation that usually merges PEP and PIP attributes would need to do something
different.

If the dynamic attributes are merged into the initial request then they are combined with the
PEP attributes. Whether the context handler then merges or overrides the PIP attributes when
evaluating the final request remains implementation defined. To be consistent the
ignore-other-values obligation should only apply to PEP attribute values.

The "dynamic attribute overrides" strategy would also need to be with respect to PEP
attributes because it lacks a mechanism to force the context handler to ignore certain PIP
attributes while evaluating the final request if it's not a "PEP overrides PIP" context
handler.

The "existing attribute overrides" strategy could include PIP attributes though it relegates
the DAA to being the least authoritative source of attributes.

Regards,
Steven

On 15/09/2021 10:30 am, Steven Legg wrote: