RE: [xacml] MAD conceptual model

["Tyson, Paul H" <PTyson@bellhelicopter.textron.com>]

> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com] 
> Sent: Thursday, October 22, 2009 07:49
> To: Tyson, Paul H
> Cc: xacml@lists.oasis-open.org
> Subject: Re: [xacml] MAD conceptual model
> 
> Paul,
> 
> I have not had the time to review all the proposed changes 
> yet, but regarding question 2 below: the namespace context of 
> an xpath expression data type is already defined by the 
> current core draft. From section A.2, page 101, line 3888 (PDF CD-1):
> 
> "When the value is encoded in an <AttributeValue> element, 
> the namespace context is given by the <AttributeValue> element"

Yes, I discovered that on a closer reading after I posted my questions.

> 
> In general, XACML should strive to use the "natural" 
> namespace context, which is the element where the xpath 
> expression occurs. Look at this:
> 
> <Request xmlns:ns1="http://example.com/namespace/apple";>
>   ...
>   <AttributeValue
> DataType="...:xpath-expression">ns1:foo/ns1:bar</AttributeValue>
>   ...
>    <Content xmlns:ns1="http://example.com/namespace/orange";>
>     ...
>    </Content>
>   ...
> <Response
> 
> I think the average user would think that the ns1 in the 
> xpath expression would resolve the "apple", not "orange". 
> Anything else would be very confusing.

Agreed.  Namespace binding in the request context is well defined.

However, there appears to be some motivation for defining it better in
the Policy evaluation model, to allow more predictable xpath
resource-ids to be generated for multiple decision requests, to
facilitate regexp matching.  That is, the policy writer would be able to
specify what namespace prefixes will be used, so that rules testing the
string value of the xpath expression can be written without regard to
the namespace binding used in the request.  I'm not terribly sympathetic
with this, because I haven't seen a good XACML use case for it.  But on
principle, any module that deals with xml namespaces ought to be free to
define its own set of bindings to insulate itself from external changes.

Regards,
--Paul

<snip>