OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

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

Subject: Re: [xacml-comment] hierarchical node id datatype

It would help, if the Policy had type specification and operators that 
can order the values of these types.

One such case is domain matching, whether it is Subject LDAP DN or 
resource URL. The other important case is ordering roles to form a role 
hierarchy. It would be far more intuitive to specify policy in a form of 
"Subject.role >= X" than require the caller to be aware of the hierarchy 
and supply the set of roles that each Subject.role is superior to to be 
able to compare them using set operators.


Tyson, Paul H wrote, On 24/01/2009 17:27:
> In the 3.0 draft hierarchical profile of 7 November 2008:
> Data type for non-XML node ids (section 2.2) is required to be anyURI.
> While this might be useful to support some xpath-like operations, it
> seems to be overspecified for the basic use case of testing to see if
> one resource is an "ancestor" of another.  A string data type would work
> as well.
> Consider a resource-id "r1", used in two places in a hierarchy:
> 	http://example.com/path/to/one/r1
> 	http://example.com/path/to/another/r1
> I have a rule that says "permit if resource has ancestor 'path'".
> My context handler can supply a bag of resource-ancestor attribute
> values ["one","another","to","path"] for resource-id "r1".  But
> according to the draft spec I would have to write the rule:
> 	permit if 'http://example.com/path' anyURI-equal
> resource-ancestor
> and the context handler would have to supply URI values like
> 'http://example.com/path', 'http://example.com/path/to', etc.
> In other contexts, values like 'path', 'to', etc. would be the actual
> resource-id values for these resources.  It would be convenient to use
> these values directly as the values of 'resource-parent',
> 'resource-ancestor', and 'resource-ancestor-or-self'.  This would not
> interfere with any existing functionality provided by the hierarchical
> profile, because they would be distinguished by a different datatype.
> Please consider relaxing the anyURI datatype requirement for non-XML
> 'resource-parent', 'resource-ancestor', and 'resource-ancestor-or-self'
> attribute values in the hierarchical profile.  This would also allow
> policies to use other appropriate comparators besides anyURI-equal and
> regexp-uri-match.
> --Paul Tyson

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