Re: [xacml] Possible Issue: XACML 3.0 WD 9 - 2 questions on Obligation

["Rich.Levinson" <rich.levinson@oracle.com>]

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