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,

You can already have multivalued datatypes in XACML 2.0 by multiple 
<Attribute> elements, so nothing has changed functionally. We moved the 
AttributeId XML attribute because XACML 2.0 was split into two schemas, 
which both contained a declarations for an <AttributeValue> element, but 
the placement of the AttributeId XML attribute was different in the two 
schemas. We wanted to merge the schemas in order resolve a circular 
dependency between the two schemas with the additional functionality in 
3.0. To avoid the collision between the two <AttributeValue> elements, 
we had to change one of the compared to 2.0.

XACML 2.0 already allows multiple <AttributeAssignment>s in an 
obligation, and we would like to keep that the same in 3.0 for 

Best regards,

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]