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] Hierarchical Profile and the URI

> As I said in the first msg after the call, the only drawback I see  
> to this is that the ancestor information and the URI form might be  
> inconsistent with each other. As I also said, there are lots of  
> other ways that the Request Context can contain inconsistent  
> information, which we do not prohibit, so this does not seem like a  
> serious issue.

> If we split these two approaches, rather than leaving them merged,  
> then we will only avoid inconsistencies by requiring that when  
> Ancestor information is provided, it is prohibited to name the  
> resource and its ancestors using a hierarchical URI. This seems too  
> extreme. It seems to me to be desirable to let users name their  
> resources in the most natural way for their environment.

A common use case would be web application resources integrated in  
some mash up application.  More often then not their logical  
relationship that is relevant for access control are not reflected in  
there location names.   I do not think it will be wise to make people  
to use any particular naming scheme just for compatibility with XACML.

> I don't feel that strongly about this, so if the TC wants to change  
> the Profile to say that in the non-XML case you can either provide  
> a bunch of hierarchical names OR provide a bunch of non- 
> hierarchically named ancestors, them I will go along with it.

I think that the ancestors profile should be very clear about the  
fact that it is completely independent of a naming scheme for the  


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