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: Hi Bill, On 15/09/2021 9:47 am, William Parducci wrote: Ok, so itâs effectively ignore-others (allows for order variance)âcorrect? Yes, where "other" includes attribute values supplied by the PEP in the request, values fetched from PIPs by the DAA and added to the request context while processing DA policy, and values that would have been fetched from PIPs by the context handler when the PDP evaluates the final request. I chose "initial" to align it with the initial request though I meant it to cover the request context that it would normally give rise to (which includes values fetched from PIPs later). So ignore-other-values is a better name given the effect the obligation is intended to have. Regards, Steven Thanks b On Sep 14, 2021, at 2:45 PM, Steven Legg <
steven.legg@viewds.com> wrote: ï Hi Bill, On 15/09/2021 12:46 am, William Parducci wrote: Hi Steven, If itâs possible for multiple dynamic attributes to exist in the decision context how do you see ignore-initial-values obligation working? Wouldnât there have to be arbitration amongst those as well? Like the exclude-all-values obligation, an ignore-initial-values obligation would nominate a single attribute by category, attribute ID, data-type and optional issuer. So each attribute type would be considered separately. Informally, the ignore-initial-values obligation would instruct the context handler to ignore any initial attribute values that would have been selected by an attribute designator with the same category, attribute ID, data-type and optional issuer. Regards, Steven thanks b On Sep 9, 2021, at 10:40 PM, Steven Legg <
steven.legg@viewds.com < mailto:
steven.legg@viewds.com >> wrote: All, I've been considering the issue of how to handle dynamic attributes generated by the Dynamic Attribute Authority that are attributes already in the request context (see Section 3.4 of
https://www.oasis-open.org/apps/org/workgroup/xacml/download.php/68861/xacml-3.0-dyn-attr-v1.0-wd03.docx <
https://www.oasis-open.org/apps/org/workgroup/xacml/download.php/68861/xacml-3.0-dyn-attr-v1.0-wd03.docx > ). The three main options are "merge", "dynamic attribute overrides" and "existing attribute overrides". There are straightforward ways to get the effect of "merge" or "existing attribute overrides", whatever the default behaviour, by judicious use of the issuer field and the existing DAA obligations, but not in the case of "dynamic attribute overrides". This would suggest that "dynamic attribute overrides" should be the default, though it feels a bit like a sledgehammer and isn't the path of least resistance. XACML allows the same attribute to appear multiple times in the request, with one or more possibly-duplicated attribute values in each instance, so tacking on a few more generated by the DAA is trivially easy and is likely to involve the least disruption to existing context handler implementations. This is the "merge" option. The current DAA draft merges while avoiding adding duplicate values, but it would be simpler to not worry about duplicates since they rarely matter and there are a few ways to avoid them if required. If "merge" is the default then I would propose adding a new obligation so as to get the effect of "dynamic attribute overrides" when desired. Call it the ignore-initial-values obligation. It would have the same components as the exclude-all-values obligation and its effect would be to cause the context handler the exclude any original values of the nominated attribute from the request context. If I don't hear any arguments to the contrary, in the next DAA draft I will keep "merge" as the nominal behaviour, except in the presence of an ignore-initial-values obligation, and drop the need to check for duplicates. I'll add a non-normative section on ways to get the different behaviours. Regards, Steven --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php <
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >