RE: [xacml] Context attribute clarification

[Tim Moses <tim.moses@entrust.com>]

Seth

I expect the proposal is actually in-line with your understanding.  It is my
attempt to describe it that is out of line.

I think you are saying that, as far as the PDP is concerned, anything
between <AttributeValue> tags is a single attribute (including any xml
attribute of the <AttributeValue> element, itself).  Whether the attribute
is primitive or structured, it is the associated function that should
validate the contents.  In the structured case, it will need some private
way of locating the schema, given the DataType URI.

Here is the current definition:

<xs:element name="AttributeValue" type="xacml-context:AttributeValueType"/>
<xs:complexType name="AttributeValueType" mixed="true">
	<xs:sequence>
		<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
	<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

An attribute value that is an unencapsulated sequence of elements is valid
according to this definition.  But, if we expect the function to
schema-validate, doesn't this introduce a problem, because such a sequence
is anonymous?  

My understanding is that the anyAttribute declaration does not REQUIRE the
<AttributeValue> element to have an atribute, but it MAY have one or more.

Awaiting your thoughts.  All the best.  Tim.


-----Original Message-----
From: Seth Proctor [mailto:Seth.Proctor@Sun.COM] 
Sent: Tuesday, March 02, 2004 12:11 PM
To: Tim Moses
Cc: 'XACML'
Subject: Re: [xacml] Context attribute clarification



Judging from the examples you provide, I guess I haven't been reading these
changes to the spec carefully enough. Here's what I think should be
happening...

> In the first case, we have a multi-valued attribute of primitive type.  
> This is relatively straightforward.  The data-type is defined in the 
> <Attribute> element.  In this case, the <AttributeValue> element 
> SHOULD NOT have any xml attributes.
> 
> <xacml-context:Attribute 
> AttributeId="urn:com:food:favouriteVegetables"
> DataType="http://www.w3.org/2001/XMLSchema#string";>
>  <xacml-context:AttributeValue>Brocolli</xacml-context:AttributeValue>
>  <xacml-context:AttributeValue>Parsnip</xacml-context:AttributeValue>
> </xacml-context:Attribute>
> 
> A matching <SubjectAttributeDesignator> or <AttributeSelector> would 
> return a bag containing two strings.

Agreed. There are two values, both of type string, both with the same
identifier. This is the whole point of Rebekah's proposal: a simple
mechanism so that we don't have to use the Attribute element twice.

> In the second case, we have a multi-valued attribute of complex type.
> 
> <xacml-context:Attribute xmlns:Food="urn:com:food" 
> AttributeId="Food:favouriteMeals" DataType="Food:Dish">  
> <xacml-context:AttributeValue>
>   <Food:Dish BestSeason="Fall">
>    <Food:Main>Potato pie</Food:Main>
>    <Food:Veg>Brocolli</Food:Veg>
>   </Food:Dish>
>   <Food:Dish BestSeason="Fall">
>    <Food:Dessert>Apple pie</Food:Dessert>
>    <Food:Topping>Double Devon cream</Food:Topping>
>   </Food:Dish>
>  </xacml-context:AttributeValue>  <xacml-context:AttributeValue>
>   <Food:Dish BestSeason="Spring">
>    <Food:Main>Asparagus quiche</Food:Main>
>    <Food:Salad>Spinach</Food:Salad>
>   </Food:Dish>
>   <Food:Dish BestSeason="Spring">
>    <Food:Dessert>Crème brulée</Food:Dessert>
>   </Food:Dish>
>  </xacml-context:AttributeValue>
> </xacml-context:Attribute>
> 
> A matching <SubjectAttributeDesignator> or <AttributeSelector> would 
> return a bag containing four <Food:Dish> elements.

Here I don't agree. The example you give only has two AttributeValues. A
designator or selector should therefore return a bag with two values in it.
How exactly am I supposed to see 4 values here? More to the point, how is
the processing code supposed to see 4 values? If this example really yields
4 values instead of 2, then this proposal is not just providing a convenient
shorthand syntax, it is re-defining how we process attribute values.

> In this case, the <Attribute> element DataType attribute contains the 
> QName of the attribute element.  Additionally, the namespace has to be 
> declared.

No. The Attribute element specifies the identifier for the datatype used. If
this is a custom type, and the processing code knows how to deal with the
identifier as a QName and resolve a namespace, that's ok, but that's unknown
to the specification.

> Conclusion: the DataType attribute of the <Attribute> element should 
> be required.  If the <AttributeValue> is of primitive type, the 
> DataType attribute MUST contain the type identifier of the attribute 
> as a URI.  Also, in this case, the xml attribute in the 
> <AttributeValue> element MUST be omitted.

The DataType attribute is required now, and is always a URI. Has the
proposal in question changed this? It should not. Also, I don't think I
understand the last sentence here...there is no standard XML attribute for
xacml-context:AttributeValue.

Some of the confusion here, I think, is that the example is incorrect. The
DataType in the Attribute should not be Food:Dish, it should be something
like Food:Dishes. Either that or there should be 4 AttributeValue elements
in the Attribute. Actually, I think that the correct way, given the current
specification, is:

<Attribute AttributeId="Food:favouriteMeals" DataType="Food:Dish">
<AttributeValue BestSeason="Fall">
  <Food:Main>Potato pie</Food:Main>
  <Food:Veg>Brocolli</Food:Veg>
 </AttributeValue>
 <AttributeValue BestSeason="Fall">
  <Food:Dessert>Apple pie</Food:Dessert>
  <Food:Topping>Double Devon cream</Food:Topping>  </AttributeValue>  ...
</xacml-context:Attribute>


> If the <AttributeValue> element has complex contents, then the 
> namespace MUST also be declared and it is RECOMMENDED that it be 
> declared in the <Attribute> element.  Also, in this case, the DataType 
> attribute of the <Attribute> element MUST contain the QName of the 
> attribute element.  The <AttributeValue> element may contain xml 
> attributes.

Gah. Is this really what we're proposing? Why the addition of QNames? The
DataType attribute has clear meaning right now. It's an identifier that
specifies the datatype of the value(s). 

As an aside, I am seriously worried about this proposal. It was originally
supposed to provide a simple syntactic shorthand for describing a collection
of values that happen to have the same datatype and identifier. This should
have been trivial to add. That it's taking this long, and that we're talking
about how to handle QNames, namespaces, and complex content suggests to me
that this proposal has become something much more complex. Could someone
please post a complete list of changes for this proposal so we can
understand exactly what has happened?

> Is this consistent with everyone's thinking?  All the best.  Tim.

Apparently not. Sorry :(

Also, it's spelled "Broccoli" ... at least in this country :)


seth