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