Clarification of Hierarchical Resource Profile

Title: Message

Hi

 

I'm seeking to 
clarify my understanding / the intent of the Hierarchical Resource 
Profile.  Primarily XACML 2.0, but I understand that 3.0 mainly refines and 
adds clarity, so anything from 3.0 that's relevant in this respect I am 
interested in.

 

I'm iinterested 
in the hierarchical path representations of non-XML nodes, ie 2.0 spec 
lines 190 et seq.

 

My question is if 
the Hierarchical Resource Profile deals (is intented to deal with) with 
resources-in-path-context.  That is, if a resource belongs to multiple 
hierarchies/has multiple parents/ancestors, can a policy be written for this 
resource-in-path-context.  (to put it another way, policies dealing with 
resources when being accessed as part of a particular collection having a 
specific policy, rather than a resource being accessed, and because it is a 
member of - rather than being accessed in the context of being a member of - 
having a specific policy).

 

Example paths for a 
resource "c" (ignoring the fact these aren't URIs, I gather this 
restriction was relaxed in 3.0)

/a/b/c

/x/y/c

 

According to the 
spec, a request for resource c should result in two separate resources in the 
request context, a resource-id with value /a/b/c and a resource-id with value 
/x/y/z - is that correct?

 

And two different 
policies, one specifying (as URI regex match) /a/b/.* and the other /x/y/.* 
would both match?

 

Is it also 
permissible for the incoming request to the PEP to specify the full path, for 
instance to state that resource c is being accessed in the context of 
collection b which is a member of collection a?  Thus only the first policy 
would match?

 

That is, because a 
full resource-id is already present then the engine shouldn't go away and build 
the paths.

 

And is it 
conceivable that both forms could exist together?

 

For instance, if 
there was a resource attribute of object-ID, and it is defined that resource-id 
is formed of the full path to object-ID then we could have

 

Request 
one:

specifies resource 
object-id = "c"

result: engine 
builds all applicable paths to "c" - ie two separate resources with their own 
resource-id (so both above policies match)

 

Request 
two:

specifies 
resource-in-path-context, specifying resource-id directly as 
"/a/b/c"

result: engine does 
not build resource-id and only the first policy matches

 

Any guidance on this 
appreciated.  My reading so far of the specs suggests that the Hierarchical 
Resource Profile isn't intended for resource-in-path-context (or 
resource-accessed-as-member-of-collection).

 

Thanks

Steve