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] 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]