RE: [xacml] Minutes of 20 May 2004 XACML Focus Group

[Anne.Anderson@Sun.COM]

>>And people are more likely to come up with
>>idiosyncratic ways of representing resources that could have been
>>represented in a common format.
>
>Exactly!  And they will not be happy with us forcing them into any
>particular naming convention - which we have no expertise, or need to
>define.
>
>I sincerely doubt that we can/should invent yet another
>standard/language within XACML.  Every attempt I have heard about for
>"universal" naming convention, beyond a unique label, was a major PIT
>A.
>
>Both "ancestors" and Xpath do cover the basic use case within an alre
>ady
>defined constructs in XACML (mandatory and optional).   No new
>restrictions, rule or guidelines are needed.

Daniel,

You seem to want resource node names that do not have to reflect the 
hierarchy, but I think you then have problems if your hierarchy contains 
ny duplicate node names.  For example, if your hierarchy is

              A
             / \
            A   B
           / \
         ...  C

and you want your policy to apply to "C", but not to "B", then you
can't use a policy statement like

    <Apply FunctionId="string-is-in">
        <AttributeValue DataType="#string">A</AttributeValue>
        <ResourceAttributeDesignator AttributeId="resource-ancestor" 
                                     DataType="#string/>
   </Apply>

You could use something like finding the size of the bag of "resource-ancestor"
Attributes that match "A" and insisting that it be exactly 2, but that
requires you to know the hierarchy, and starts getting complicated.

It seems like you need a way to represent node names that will distinguish
"/A/A/*" from "/A/*".  The proposed standard URI representation does that.

How do you propose to deal with duplicate names?

Note that the proposed standard URI representation does not constrain how you
represent the individual node names; that is whatever representation
is native on the host where the resource is located.  You just have
to pre-pend the ancestor nodes in order back to the root(s).  You are
going to have to walk the list of ancestors to generate "resource-ancestor"
anyway, so I don't see that this is really extra work.

Anne