[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, There is a problem with adding the @Issuer since it would be static in the obligation expression, so it won't help in roundtripping attributes from the request. Also, the XACML datatype/attribute value model does not retain the issue at runtime, so it would be lost in the expression. We could add a static @Issuer, but I don't see much value with it. Best regards, Erik Rich.Levinson wrote: > Hi again, Erik and TC, > > I think we can now consider this possible issue as being "almost > resolved". > > * The only remaining suggestion I have is that we also add > optional Issuer to the AttributeAssignment element. > > The following is an explanation in case anyone is interested: > > As indicated a couple emails back, I had a certain expectation that an > Obligation was the functional equivalent of the Attributes element and > was effectively equivalent to a general collection of Attributes. > > However, I also had the expectation that the AttributeValue subelement > of Attribute was relevant in some way to that functionality, and was > concerned for the lack of an example to show how this functionality > was expressed. > > So, first, wrt to the example, the thing that made this different from > XACML 2.0 was that the example in Ch 4 was no longer complete because > Obligation had been replaced policy-side by ObligationExpression. > However, in 2.0 the policy-side and response-side were equal, so the > 2.0 policy served as an example and does show AttributeAssignment w > attributes: AttributeId and DataType, and a child text value. Noticing > this, I was then satisfied that AttributeValue never originally was > child to AttributeAssignment, so at least we were not losing anything > from 2.0 in this regard, which I was wondering about. > > Now wrt to the functional equivalence of Obligation to a collection of > attributes, as indicated in prev emails, I was thinking that > AttributeValue first was meaningful, then possibly extraneous, then > meaningful again. Now, I think I have effectively reached the > conclusion that it is "functionally" extraneous, but may serve useful > purposes in other respects, but maybe not. In any case, I am not > recommending changing it for any non-functional purpose. > > Effectively there are 4 xml attributes that totally define the > metadata associated with the text content (the 5th item in list) of an > Attribute. They are: > > * Attributes@Category > * Attributes/Attribute@AttributeId > * Attributes/Attribute@Issuer > * Attributes/Attribute/AttributeValue@DataType > * Attributes/Attribute/AttributeValue/text() > > For an Obligation, we can list the equivalent information (as of WD10): > > * Obligation/AttributeAssignment@Category > * Obligation/AttributeAssignment@AttributeId > * Obligation/AttributeAssignment@DataType > * Obligation/AttributeAssignment/text() > > The purpose of my recommendation should be obvious, now, which is to > fill in the missing piece of potentially useful metadata, which is: > > * Obligation/AttributeAssignment@Issuer > > One final note is that Obligation does have one additional attribute > that Attributes does not have a functional equivalent, which is: > > * Obligation@ObligationId > > which effectively means that Obligation, in current form, w @Issuer > added, is effectively one dimension greater than already extremely > general Attributes element. i.e. while we can have multiple Attributes > elements they are only distinguishable by Category, whereas Obligation > can distinguish by Category by only including elements within a single > Category, but then multiple collections of this type can then be > distinguished by ObligationId. > > It probably turns out that, for the multi-resource profile that xml:id > fills this gap as well. > > Thanks, > Rich > > > Rich.Levinson wrote: >> Hi Erik and TC, >> >> I have found the answer on the multiple DataTypes. The >> AttributeDesignator has a required DataType attribute, which >> restricts the bag returned to be of a single DataType. >> >> This was also in XACML 2.0. The change in 3.0 effectively >> consolidates the need in 2.0 to specify separate Attribute elements >> for each DataType, by moving the DataType down to the AttributeValue, >> which enables one Attribute element to contain all AttributeValues >> with same AttributeId. >> >> Please ignore question 2, however, I would still like clarification >> on question 1. >> >> Thanks, >> Rich >> >> >> 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 >>>>> >>>> >>> >> >> --------------------------------------------------------------------- >> 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]