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] New issue: new attribute ids for xml multiple decisions


> -----Original Message-----
> From: Jan Herrmann [mailto:herrmanj@in.tum.de] 
> Sent: Friday, November 20, 2009 08:50
> To: Tyson, Paul H
> Cc: 'XACML TC'
> Subject: AW: [xacml] New issue: new attribute ids for xml 
> multiple decisions
> Hi Paul,
> Your described use of the resource-id value in the multiple 
> decision request appears to be very application specific. In 
> fact you propose to use it as some sort of metadata 
> describing the multiple resource as a whole. I am not sure if 
> it makes sense to use the central resource-id attribute for 
> such a thing. In fact all information you use in your example 
> can be obtained by the general, generic mechanism too.

My point was that we shouldn't prevent any reasonable use of the generic
"resource-id" attribute by putting a special meaning on it in certain
contexts.  We should use special attributes for special purposes,
thereby leaving the generic attributes for application-specific uses.

The trouble with "resource-id" started when it took on a special meaning
as "an xpath expression for selecting a sequence of nodes in the Content
element".  This specialized meaning competes with the generic meaning of
"a primary identifier of a resource in the domain of interest of the
XACML application".

No matter how you choose primary identifiers in your domain of interest,
they are not likely to look like "*[3]/*[2]".  But the range of values
for XACML resource-id includes "123-456-789",
"http://foo.example.com/part-numbers/123-456-789";, and "//*[@part-number
= '123-456-789']".  The last item just doesn't belong in that list.

We could eliminate this confusion by deprecating xpathExpression
resource-ids in 3.0, but I suppose we are too far along for that.

But we don't need to extend the confusion by specifying additional uses
for this type of "resource-id".



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