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