[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Dynamic Attributes versus Existing Attributes
Ok, so itâs effectively ignore-others (allows for order variance)âcorrect? 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> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]