[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Passing parameters to the attribute designator
Let me re-project the problem after going through the responses, I wonder if it still interests the TC. I accept the point that the attribute identifier on the designator should be all that the context handler must use but it looks like there are cases where mapping attributes to queries is after all not problem free. An example being the query - get top n-elements from the stack, where 'n' is a variable. Policies may have to be written with 'n' hardcoded within to avoid a surplus of attribute identifiers to deal with. I assume the context handler remains unaware of the policies the PDP is evaluating and only serves callbacks from the PDP for attributes, and therefore do not think an additional context that maps the policy to 'n' would be available to the handler. Regards, Anil -----Original Message----- From: Seth Proctor [mailto:Seth.Proctor@sun.com] Sent: Friday, July 04, 2008 9:12 PM To: Erik Rissanen Cc: xacml@lists.oasis-open.org; Anil Tappetla (atappetl) Subject: Re: [xacml] Passing parameters to the attribute designator Erik Rissanen wrote: > This issue falls under the broader issue of attribute provisioning, > which I think is very important and currently somewhat underspecified > in the XACML world. But this is much because by design XACML chose to > abstract away this kind of details. This kind of abstraction makes > XACML more generally applicable and adaptable to different > environments and growth over time. > [...] > So I am opposed to the proposed change in the XACML schema. For what it's worth I agree with Erik here. This issue has actually come up a couple of times before. As I recall, the last time was when Anne and I were looking at some related issues, and she decided to take a stab at starting to define some basic provisioning configuration. As it (quickly) grew very complex, I was of the opinion that this is something best configured separately, rather than trying to wedge it into the already somewhat verbose policies. I think the main issue in my mind boils down to how people are likely to use his feature. I have not yet come across any real-world scenarios where people want to define different configuration within the same policy for various Designators. This is the only strong argument I can think of for including configuration in the policy itself. As long as configuration is defined per-policy or, more likely, per-PDP, then doing the configuration separately seems like a much cleaner approach. seth --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: 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]