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,

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]