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 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.


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]