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] Moving ahead with 3.0

Rich Levinson wrote:
> It seems to me, although I haven't gotten to all the details yet, that 
> a lot
> of what you say is valuable about admin and WS-XACML could be
> had building as profiles and adjuncts to 2.0. Is there a reason why these
> core changes are tied to those items?

The  admin policies (aka delegation) were initially designed on top of 
the old 2.0 schema with subject/resource/etc. We decided to generalize 
the schema to attribute categories because of three reasons:

1. In our discussions someone, I don't remember who, said that there had 
been requests from users who did not like to be tied to the fixed 
existing categories. They felt their applications mapped better to other 

2. Delegation requires a new category for attributes, the Delegate. We 
also had an IndirectDelegate at the time, but this was removed because 
of computational complexity issues in the delegation model. It was felt 
that since we need to introduce a couple of new categories now, we might 
as well go ahead and move the categories from the XML schema into URIs 
so we could ad more categories in the future if needed by yet unknown 

3. The initial implementation of delegation on top of the 2.0 schema 
lead to some technical difficulties regarding the distinction between 
administrative policies and access policies. Since both used the same 
attribute categories we needed to differentiate between the two types of 
policies by other means, such as the presence of a Delegate category in 
the target. This lead to problems since it was not possible to write 
targets matching any delegate, unless additional special constructs were 
introduced in the target. All these issues were solved by putting 
administrative requests in their own attribute categories, as permitted 
by the generalized schema. In other words, delegation is easier to 
implement on top of the general schema.

As it happened, 1 and 2 preceded 3 in the discussion and technical work. 
(We didn't realize that delegation became easier until after we moved to 
general categories.)

I think now is a better time to make this change rather than later. The 
more 2.0 deployments there are, the harder it will be to do the change 
in the future. The general categories allow for considerable flexibility 
for the future without the need of schema breaking changes.

Best regards,

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