[xacml] change request: add Datatype back to policy elements

[Anne Anderson <Anne.Anderson@Sun.com>]

[Forwarded for Seth, who still can't post to the list, although
he is subscribed. -Anne]

From: Seth Proctor <seth.proctor@sun.com>
Subject: followup to dataType comments
To: xacml@lists.oasis-open.org
Date: Wed, 02 Oct 2002 18:10:02 -0400

[I seem to have been added to the xacml list faster than expected, so no
 comments need be sent directly to me any more...]

Adding to my previous mail, the same arguments apply to putting the dataType
attribute back on at least AttributeSelector, and maybe AttributeDesignator.
I realize these were just recently removed, so my applogies for bringing this
up, but I think it's pretty important (and from my quick reading of the archive
I didn't see any comments along my train of thought, although please point me
in the right direction if I've missed something).

The AttributeSelector type lets the PDP look into the request, and pull out
some arbitrary sting data that has no type associated with it. Because of
this, once again the data is being defined by function inputs, and not what
the Request author intended. Also, as I discussed in my previous email, this
lets multiple AttributeSelectors pull out the same data but treat it as
different types based on the function being used (either in a Match or an
Apply), which seems like a Bad Thing. I would be much happier if a policy
writer could provide an XPath statement, but also say what kind of data
should be returned.

I'm less concerned about the AttributeDesignator having a dataType attribute,
since as long as the dataType attribute is required in the Request Attribute,
we'll always know what the intended data type is. That said, both for 
consistency in the language, and to make sure that the correct type is being
pulled out of the Request (ie, something with the correct id but wrong type
could be found in the Request, and we'd have no way of knowing), I would like
to see the dataType field in the AttributeDesignator as well. It makes the
implementation faster, cleaner, and gives it more chances to check that the
right thing is being done.

thanks

seth "I promise not to bring up too many issues" proctor
-- 
Internet Security Research Group
Sun Microsystems Labs