[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Possible Issue: XACML 3.0 WD 9 - 2 questions on Obligation
Hi Rich, You can already have multivalued datatypes in XACML 2.0 by multiple <Attribute> elements, so nothing has changed functionally. We moved the AttributeId XML attribute because XACML 2.0 was split into two schemas, which both contained a declarations for an <AttributeValue> element, but the placement of the AttributeId XML attribute was different in the two schemas. We wanted to merge the schemas in order resolve a circular dependency between the two schemas with the additional functionality in 3.0. To avoid the collision between the two <AttributeValue> elements, we had to change one of the compared to 2.0. XACML 2.0 already allows multiple <AttributeAssignment>s in an obligation, and we would like to keep that the same in 3.0 for compatibility. Best regards, Erik Rich.Levinson wrote: > Hi again, Erik, > > Thinking about this some more, I realized that I jumped the gun > calling the AttributeValue possibly functionally extraneous. It has an > explicit function which is to enable multi-valued Attribute elements. > > However, this suddenly puts additional spotlight on the move of > DataType in 2.0 from the Attribute element, to the AttributeValue > element in 3.0. > > * This now means that in 3.0 an attribute with a specific > AttributeId can have multiple values, each with a different > DataType! Was this intended? I took a quick run thru 3.0 and > could not find any explicit indicators that this was > functionality that was being utilized in any specific manner. > * Does this impact the "bag functions" in section A.3.12? All the > examples there appear to assume that all the elements in the bag > have the same DataType. That was a good assumption in 2.0, > because DataType was defined at the parent element, but > apparently not in 3.0, because each child element can now have > its own DataType. > > In any event, if my interpretation of AttributeAssignment in prev > email is correct, that would mean that each AttributeAssignment can > only be single-valued, because it does not "contain" an AttributeValue. > > The net effect of this is to make Obligation now the functional > equivalent of a single multi-value multi-data-type element comparable > to our regular definition of Attribute. However, unlike an Attribute, > now each AttributeValue equivalent (AttributeAssignment) has its own > AttributeId. > > The net effect of all this I am finding really confusing and would > appreciate some guidance to bring it under a more reasonable > conceptual framework. If my interpretation of your original response > is correct, it appears that Obligations, in effect, are another > conceptualization of how to define Attributes. > > I think it would be much easier to have AttributeAssignment be > equivalent to Attribute and be able to contain multiple > AttributeValues in the familiar way. > > So, I guess there are two potential issues against core here: > > 1. Are we making Obligations unnecessarily complex by not allowing > them to contain multiple AttributeValues within an > AttributeAssignment, and forcing this functionality back up, > which remakes a single Obligation into the functional equivalent > of a single Attribute (both multi-valued, but constructed quite > differently). > 2. Does putting DataType in the AttributeValue element force new > functionality to be required now that a single attribute can not > only contain multiple values, but each value may be of its own > DataType? > > Thanks, > Rich > > > > Rich.Levinson wrote: >> Hi Erik, >> >> Thanks for the feedback and attempted clarification on >> AttributeValueType :). I admit I am still a little confused, let me >> try to explain. I think the problem is that a definitive example is >> needed. Here is my perspective: A typical attribute in the >> RequestContext has the following form: >> >> <Attributes Category="abc"> >> <Attribute AttributeId="def" Issuer="ghi" IncludeInResult="jkl"> >> <AttributeValue DataType="mno" >> >content data</AttributeValue> >> </Attribute> >> </Attributes> >> >> (Couple points worth noting are that DataType has moved from being an >> attribute of Attribute in XACML 2.0 to being an attribute of >> AttributeValue in XACML 3.0., also that IncludeInResult is new in >> 3.0, and Category is expanded in 3.0 to be general, from the >> SubjectCategory special case from 2.0) >> >> Presumably, all the attributes in the response sent by >> IncludeInResult appear in this same form in the Response. >> >> The first additional case we addressed was MissingAttributeDetail, >> section 5.56, which appears to come back in the following form: >> >> <StatusDetail> >> <MissingAttributeDetail Category="abc" AttributeId="def" >> DataType="mno"> >> <AttributeValue >> >content data</AttributeValue> >> </MissingAttributeDetail> >> </StatusDetail> >> >> This has essentially the same form as the other attributes, except: >> >> * Category is pushed down so it now appears alongside AttributeId >> etc. >> * DataType is above <AttributeValue> as it was in XACML 2.0 >> >> I am ok w those differences, since an AttributeValue may not be >> returned, in general, because, after all, the point is that it is >> "missing" and the PDP may tell the PEP what dataType is needed, it >> probably is not going to say what value to provide. However, and >> empty AttributeValue w DataType attribute might be an improvement. >> >> Also, I am satisfied with pushing down Category into the >> MissingAttributeDetail, because the StatusDetail can hold multiple of >> these elements and there is not reason why they would all have the >> same Category, which is unlike the case on Input, and to some degree >> IncludeInResult as well. >> >> With that context in mind, what I am "expecting" to see for >> AttributeAssignment is something along the following lines: >> >> <Obligation ObligationId="123"> >> <AttributeAssignment Category="abc" AttributeId="def" Issuer="ghi"> >> <AttributeValue DataType="mno" >> >do this and that</AttributeValue> >> </AttributeAssignment> >> </Obligation> >> >> I have not found any examples to confirm the above "expectation", so >> I have been relying on interpreting the xml, which is the reason for >> my original question. >> >> From the meeting minutes, I see the TC agreed w your suggestion to >> include Category as optional, which seems fine to me. >> >> So, all that remains in my mind is straightening out what is actually >> returned. It sounds from your description that >> >> * "AttributeAssignment has the same content as AttributeValueType, >> except that the XML attribute AttributeId is required" >> >> I apologize for being picky, but with the absence of examples, I >> still find this sentence difficult to parse in a way that makes >> sense. I interpret "content" as "child", so in this case if I take >> the first part of the sentence literally, AttributeAssignment >> "replaces" AttributeValue, so there is no "AttributeValue" and it >> just has the text content, no contained elements. >> >> Now the second part of the sentence says that "except that the XML >> AttributeId is required", which I interpret that AttributeId is >> attribute of AttributeAssignment. Finally, w decision for optional >> Category, we would have: >> >> <Obligation ObligationId="123"> >> <AttributeAssignment Category="abc" AttributeId="def" DataType="mno" >> >do this and that</AttributeAssignment> >> </Obligation> >> >> Is this correct? >> >> If so, then I guess my comment is why the need to squeeze out the >> AttributeValue element? Also, if it can be squeezed out why is it >> there in the first place? >> >> Bottom line: I think the reason I am still confused it that there >> appears to be some non-intuitive behavior, which appears somewhat >> arbitrary, possibly because AttributeValue may be functionally >> extraneous, which doesn't bother me, and even if it is, my >> recommendation is that we use it consistently and not arbitrarily >> squeeze it out. >> >> Also, might want to consider "Issuer" in the AttributeAssignment as >> well in case, policy designers want to distinguish where Obligations >> are coming from, at a finer granularity than just "the PDP". >> >> Thanks, >> Rich >> >> >> >> >> >> >> Erik Rissanen wrote: >>> Hi Rich, >>> >>> I presume you are referring to the following schema fragment: >>> >>> <xs:element name="AttributeAssignment" >>> type="xacml:AttributeAssignmentType"/> >>> <xs:complexType name="AttributeAssignmentType" mixed="true"> >>> <xs:complexContent mixed="true"> >>> <xs:extension base="xacml:AttributeValueType"> >>> <xs:attribute name="AttributeId" >>> type="xs:anyURI" use="required"/> >>> </xs:extension> >>> </xs:complexContent> >>> </xs:complexType> >>> >>> This means that an AttributeAssignment has the same content as >>> AttributeValueType, except that the XML attribute AttributeId is >>> required. Like this: >>> >>> <AttributeAssignment AttributeId="urn:....:foo" DataType="urn:...:bar"> >>> some value here >>> </AttributeAssignment> >>> >>> We want to declare the XML attribute, although xs:anyAttribute is >>> already allowed, since without the declaration the AttributeId is >>> not _required_. >>> >>> I haven't thought about the category for attributes in obligations. >>> I have thought them as parameters of the obligation, not parts of >>> the request. But I see the point. What about making the Category an >>> optional XML attribute? That way it won't "pollute" those >>> obligations which just contain obligation parameters, but it will >>> still be possible to return parts of the request. >>> >>> Best regards, >>> Erik >>> >>> Rich.Levinson wrote: >>>> While reviewing where we have ended up with the handling of >>>> Obligation elements in 3.0, I have 2 questions which I am unable to >>>> resolve based on my reading of the text (question 2 contains a >>>> possible issue of functionality, question 1 might just be >>>> clarification either by response to this email or by issue for >>>> more explanatory info in the text): >>>> >>>> 1. AttributeId in Obligation in Response: In section 5.41, >>>> AttributeAssignmentExpression, it says: >>>> * "It SHALL contain an AttributeId and an expression which >>>> SHALL by evaluated into the corresponding attribute >>>> value." >>>> * Presumably, this means that these two items will be what >>>> the PDP puts into the Obligation element that is put into >>>> the Response. This interpretation is also in agreement, I >>>> believe, with the description of this element in >>>> section 5.39: >>>> o "The expressions SHALL be evaluated by the PDP to >>>> constant <AttributeValue> elements, which shall be >>>> the attribute assignments in the <Obligation> >>>> returned to the PEP. " >>>> * Presumably the two items above (AttributeValue, >>>> AttributeId) are then put by the PDP into the >>>> AttributeAssignment element (section 5.36) which is child >>>> to the Obligation (section 5.34) >>>> * Here is my basic question on section 5.36, which may be >>>> simply that I do not understand the mechanics of the >>>> extension element in the schema: it appears on lines >>>> 2543-2546 that AttributeId might be defined here as an >>>> attribute of AttributeValue: >>>> o " >>>> >>>> <xs:extension base="xacml:AttributeValueType"> >>>> >>>> <xs:attribute name="AttributeId" >>>> type="xs:anyURI" >>>> >>>> use="required"/> >>>> >>>> </xs:extension> >>>> >>>> " >>>> o So, that's the 1st part of the question. Is this the >>>> same AttributeId identified in section 5.41, and >>>> does it show up in the output Obligation as an >>>> attribute of the AttributeAssignment element or of >>>> the AttributeValue element? (It appears based on the >>>> above that it might be the latter, if not please >>>> explain.) >>>> o If it is the an attribute of AttributeValue, the 2nd >>>> part of the question is does this not kind of >>>> violate section 5.31 AttributeValue, because this >>>> AttributeId would presumably now be part of the >>>> xs:anyAttribute. >>>> 2. (2nd question) Should we include the "Category" in the >>>> Obligation (probably not because that would apply to all >>>> AttributeAssignments) or preferably in the AttributeAssignment >>>> (assuming the AttributeId is already there from question 1)? >>>> * The reason for asking is that it does not seem >>>> unreasonable that in many cases the AttributeId assigned >>>> to the Obligation/AttributeAssignment will be the same >>>> AttributeId used to pull an attribute out of the Request. >>>> Granted, it doesn't have to be, but let's assume that is >>>> what some people might want to do. >>>> * Assuming people want to do this, we now run into the same >>>> ambiguity that led to the addition of Category to >>>> MissingAttributeDetail (section 5.56), namely that if the >>>> PEP needs to know how to correlate the returned attributes >>>> with the input request, then both AttributeId and Category >>>> are needed, in general. >>>> >>>> Thanks, >>>> Rich >>> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]