OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

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]