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
compatibility.
Best regards,
Erik
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
>>>
>>
