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] 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

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.


-----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.


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

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