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
