OASIS eXtensible Access Control Markup Language (XACML) TC

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):


  
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:
    

      
"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:
    

      
"
        

        
      <xs:extension
base="xacml:AttributeValueType">
        
         <xs:attribute
name="AttributeId" type="xs:anyURI"
        
                    use="required"/>
        
      </xs:extension>
        
"
      
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.)
  
      
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.
    
  
  
(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

Hi Rich,

I presume you are referring to the following schema fragment:

         

Just thinking out loud, but as an alternative would it make sense to make Obligation (and/or Advice) input a category type? Or do we expect to be using the same attribute for multiple purposes?

Hal

> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com]
> Sent: Thursday, March 19, 2009 2:03 AM
> To: Rich.Levinson
> Cc: xacml
> Subject: Re: [xacml] Possible Issue: XACML 3.0 WD 9 - 2 questions on
> Obligation
> 
> Hi Rich,
> 
> I presume you are referring to the following schema fragment:
> 
>          

I don't understand this alternative. Could you clarify?

Regards,
Erik

Hal Lockhart wrote:
> Just thinking out loud, but as an alternative would it make sense to make Obligation (and/or Advice) input a category type? Or do we expect to be using the same attribute for multiple purposes?
>
> Hal
>
>   
>> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
>> From: Erik Rissanen [mailto:erik@axiomatics.com]
>> Sent: Thursday, March 19, 2009 2:03 AM
>> To: Rich.Levinson
>> Cc: xacml
>> Subject: Re: [xacml] Possible Issue: XACML 3.0 WD 9 - 2 questions on
>> Obligation
>>
>> Hi Rich,
>>
>> I presume you are referring to the following schema fragment:
>>
>>          

  


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:
49C1DFFF.7080600@axiomatics.com" type="cite">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

  

  


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:


  
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).
  
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:
49C280D7.3030602@oracle.com" type="cite">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


  

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:
>>
>> 
>>
>> (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:
>>
>> 
>>
>> 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 

  
  


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:
49C2EA27.5090107@oracle.com" type="cite">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

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:
>>>>
>>>> 
>>>>
>>>> (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:
>>>>
>>>> 
>>>>
>>>> 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 

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:
>>>>>
>>>>> 
>>>>>
>>>>> (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:
>>>>>
>>>>> 
>>>>>
>>>>> 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 

Hi Rich,

Ok, thanks for the clarification. That wouldn't be a big change, which I 
think we could make: add a static @Issuer to 

Hi Rich,

You can already have multivalued datatypes in XACML 2.0 by multiple