Got it. Thanks.
b
> On Sep 14, 2021, at 5:30 PM, 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 <> 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 < <mailto:>> 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>
>>>
>
