[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.
Thanks,
Rich
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]