[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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"
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.
Best regards,
Erik
Tyson, Paul H wrote:
> Attached find proposed description of conceptual model for producing
> single authorization decision requests from a multiple authorization
> decision (MAD) request.
>
> This would replace some content in sections 2.1, 2.2, 2.3.
>
> I came up with a few questions and concerns:
>
> 1. I still don't like the idea of mutable resource-ids. Either the
> original request should have something like "resource-selector", or the
> resulting context should have "decision-node-id" or something. But then
> the problem is, how does the PEP request the resource-id to be returned
> (using "IncludeInResult")? We might have to specify some built-in
> semantics to handle this.
>
> 2. This does not specify how the xpathExpression resource-id for
> individual resources will be constructed. The TC is still discussing
> whether to specify this, and if so, what the form should be. In any
> case, it seems necessary to say something about the namespace binding
> context that will be used for name prefixes. Default might be to use
> the namespace binding context represented by the union of the contexts
> in <Content> children, but this is not specified. One way to facilitate
> regexp matching on xpath strings would be to allow policies and/or
> requests to specify a namespace binding context.
>
> 3. scope=EntireHierarchy is out of place here. Consider moving Section
> 3 to hierarchical profile. The conceptual model and expected results
> are different than the other multiple authorization decision modes. The
> "multiple" processing only takes place internally--a single decision is
> expected (possibly multiplied by additional subjects or actions).
>
> Regards,
> --Paul
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]