[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, Ok, thanks for the clarification. That wouldn't be a big change, which I think we could make: add a static @Issuer to <AttributeAssignment>. Best regards, Erik Rich.Levinson wrote: > Hi Erik, > > What I had in mind w @Issuer in AttributeAssignment is that possibly > the Policy designers wish to distinguish among themselves in some > manner as to on whose (the Issuer) direction the Obligation is being > ordered. i.e. a PEP may treat Obligations from one or another Issuer > in a distinct manner. i.e. the "Issuer" would conceptually be an > entity in the policy domain as opposed to an original input Attribute > Issuer. > > Thanks, > Rich > > > Erik Rissanen wrote: >> 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]