Re: [xacml] The context node of hierarchical resources

[Erik Rissanen <erik@axiomatics.com>]

Hello again,

I just realized that we must change this as I suggest since it won't 
work otherwise.

The context nodes specified in the hierarchical resource profile must be 
the same as the context node specified for the xpath functions in core, 
or otherwise the xpath functions won't match the hierarchical resources.

We should change this both for the 2.0 errata and for 3.0.

Regards,
Erik


Erik Rissanen wrote:
> All,
>
> I am looking into the hierarchical and multiple resources profiles again.
>
> They sometimes do not specify the context node of the xpath 
> expressions they make use of.
>
> In the hierarchical profile (section 3.1) the context node is said to 
> be the "one and only child of the <ResourceContent> element".
>
> First, I suspect that what is really meant is the "one and only child 
> element of...". I could be wrong, but if not, then indentation would 
> not be possible since indentation are child text nodes.
>
> Second, I propose that we change this to the <Content> element itself 
> in 3.0. This seems more aesthetic to me. And we get the benefit that 
> the top level element of the application data becomes part of the 
> expression in the policy.
>
> Consider these two requests (note the lack of indentation):
>
> <Content><Book>
>    <Id>1234</Id>
>  </Book></Content>
>
> <Content><Patient>
>    <Id>1234</Id>
>  </Patient></Content>
>
> When the child of the <Content> element is the context node, referring 
> to the book id look likes this:
>
> ./Id/text()
>
> Referring to the patent id looks like this:
>
> ./Id/text()
>
> The two expressions are the same, which could lead to confusion in the 
> policies (if they are in the same namespace).
>
> With the <Content> element as the context node:
>
> ./Book/Id/text()
> vs
> ./Patient/Id/text()
>
> And they won't collide even if they are in the same namespace, and 
> definitely easier for people to understand.
>
> And I don't see the need to limit the resource content to a single 
> element. It could be useful to do requests to different resources in 
> the same multiple request. Granted, the application could always work 
> around this by using an extra "top level" element in all its requests, 
> but this is unnecessary overhead.
>
> Regarding any errata for 2.0, I don't think we should change anything. 
> I am afraid we would break things in existing implementations. A 
> "foolproof" implementation could accept either a single node, or a 
> single element surrounded by text nodes. This would inter-operate with 
> either interpretation.
>
> Regards,
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php