OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xacml] Dynamic Attributes versus Existing Attributes

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.




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.


On Sep 9, 2021, at 10:40 PM, Steven Legg <steven.legg@viewds.com <mailto:steven.legg@viewds.com>> wrote:


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.


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>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]