[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] The <ResourceContent> element again
Thanks for the explanation. I had forgotten about the decision to allow documents outside the Request Context. Regards, Anne Erik Rissanen wrote: > Anne, > > I interpreted Daniel's proposal to mean that the xpath expression is > applied at the element with the id, not at the request element. See the > text on issue 40 in the issues list: > > ---8<--- > 40. Change ResourceContent > > Daniel's proposal: When looking at the generalizing the request schema > as required by Issue#3, I could not find a good place for the existing > ResourceContent context element. Adding schema restrictions for a > particular context attribute category seems to be not a very elegant > solution.In any case – existing way to provide an arbitrary XML context > document inside an element of “any” type does not seem to be optimal. > > I suggest: > > 1. Modify XACML processing model to allow a single arbitrary XML > document to be submitted along with the Request in an implementation > defined way. > > 2. Modify the AttributeSelectorType and add an optional “ContentURI” > attribute, of type xs:anyURI with a default value of > urn:oasis:names:tc:xacml:3.0:requesturn > > This attribute will be used in the following way > > 1. It identifies document node for the path expression in AttributeSelector > > 2. Default value is the URI for the request document – default behavior > would be exactly as it is now > > 3. If an additional document is present in the request this URI resolves > to that document, so the path expression in the selector applies to it. > In this case you can not use the AttributeSelector to select individual > attribute values, but that would be redundant to AttributeDesignator > anyway. An alternative would be to have two reserved URI – for the > request, and for the submitted document. > > 4. If any other URI is used in the policy, it should be resolved in an > implementation dependent way. That may allow to use an AttributeSelector > to extract values from different documents. > > So the main point is to replace the existing ResourceContent with a > separate document, and to allow AttributeSelector to identify document > uri, with default behavior remaining the same as it is now. > > 20 July 2006 meeting recommendation: Request will be extended to contain > optional sequence of <Content> elements, each with a required XML > attribute specifying a unique URI identifying that content. A <Content> > element can arbitrary XML content, which may be equivalent to the > current ResourceContent, or may be XML elements that contain information > regarding any entity (category) in the Request - essentially, XML-valued > Attributes. AttributeSelector will select the unique URI and then > provide a path to the desired information in the XML content. > ---8<--- > > I particular, note the last sentence. This is the functional requirement > I intended. Yes, you are right that the right Content can be selected by > the xpath expression itself, but I thought people wanted this syntactic > sugar, which would mean a shorter xpath expression. > > I didn't want to deviate from this since it was decided during a TC call > in July that we should implement it. > > Maybe I misunderstood it? > > However, I think Daniel expressed an opinion recently in an email to the > list that the id is not useful anymore since we move the <Content> > inside the <Attributes> element. I think draft 1 of the core still has > the id since the matter hasn't been resolved finally yet. > > Daniel's email: > http://lists.oasis-open.org/archives/xacml/200702/msg00047.html > > Regards, > Erik > > Anne Anderson - Sun Microsystems wrote: > >>Erik, >> >>I did not understand why "It is a functional requirement that the >><AttributeSelector> searches the request for the id elements." I can >>understand that the XPath expression in the AttributeSelector may >>reference the id element, but that is not a functional requirement for >>AttributeSelector, just the meaning of the XPath expression. >> >>Regards, >>Anne >> >>Erik Rissanen wrote On 02/20/07 02:41,: >> >>>All, >>> >>>I moved the element formerly known as <ResourceContent> inside the >>><Attributes> element and added anyAttributes to it, to make it backwards >>>compatible, as discussed during the meeting. >>> >>>There is one small issue still which I encountered. According to >>>Daniel's proposal, the <Content> element contains an XML attribute >>>called "id" which is required. An attribute selector may use this >>>attribute to refer to the <Content> element. There was no such id >>>attribute in 2.0, so I made it optional, or otherwise, when translating >>>2.0 policies, we would have to generate dummy ids which won't be used, >>>which is a bit ugly in my opinion. >>> >>>Another thing I was thinking about: Should we allow multiple <Content> >>>elements in a single category? In 2.0 only one <ResourceContent> element >>>was allowed. If we allow only one <Content> element, now that the >>><Content> element is inside the <Attributes> element, it is identified >>>by the category of the <Attributes> element, so the id attribute is not >>>really needed. (Thought it is still useful in the attribute selector, to >>>select a document from an implementation specific source, as proposed by >>>Daniel.) Actually, it is strictly not needed in any case, since it is >>>possible to match on any XML attribute in an XPath expression. >>> >>>For now I am writing it so only one <Content> element per <Attributes> >>>element is allowed and the id attribute is optional. It is a functional >>>requirement that the <AttributeSelector> searches the request for the id >>>elements. >>> >>>Let me know if you disagree. >>> >>>Regards, >>>Erik >>> >>> >> > > > -- Anne H. Anderson Anne.Anderson@sun.com Sun Microsystems Labs 1-781-442-0928 Burlington, MA USA
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]