[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] change request: xacml context attributes and data types
[Seth was not able to send this directly, so I am posting it for him. -Anne] ------- start of forwarded message ------- From: Seth Proctor <seth.proctor@sun.com> Subject: types in Attribute/AttributeValue To: xacml-comment@lists.oasis-open.org Date: Wed, 02 Oct 2002 14:10:18 -0400 User-Agent: Mutt/1.5.1i I work with Anne Anderson here at Sun, and recently we've been having some discussions about the issue of including type information in Attibutes and AttributeValues. I know that there are open issues where feedback is wanted, and so she suggested that I send my thoughts to this xacml-comment list (I am not on the xacml mailing list). I have been giving her feedback on the spec for some time, and I have also been doing some implementation work, so these comments come both from the point of view of a policy language designer and an implementor. I am (somewhat) concerned about the choice to remove type information from the AttributeValue type in the Policy schema. I understand that the Function listed in the AttributeValue tells us what types are allowed, but there are two problems I see here. First, It is significantly more work for a programmer to support this method for finding the attribute's type, and it requires an API that is more complex (for extending the engine to support custom functions). This is a small issue, but it's one to consider when making a language change. The second problem I see is more serious. While the function gives us the type the attribute is expected to be, it doesn't tell us what the attribute's type actually is. If someone builds a policy, and puts in an integer value (for instance) as an input for a function that expects a string, the attribute will parse fine, but will not be used in the way that was intended for the attribute value. Obviously this is a simple example where it might not be such a problem, but with custom datatypes this could be more serious. There is no way to check that the attribute type being used is the correct one. Including the attribute type in the AttributeValue object may be redundant from a language point of view, but it provides (in my opinion) a valuable reality-check to make sure that the policy isn't being evaluated in a manner that the policy author didn't intend. In the case of the Attribute type in the Context schema, the problem is compounded. First, the implementation is harder, since when you're parsing the Request object you can't parse any of the attribute types, since you don't know what type they are until you start processing the policy and find what functions are being used. Not only is this harder, but it's (arguably) less effecient. Second, because you can't parse the attribute values until you consider them in the scope of a function, you could end up with designators that select the same attributes as inputs into functions that take different values. Drawing from the example above, what happens if a policy wants to interpret the same attribute as a String, an Integer, and some custom type? Is this an error, or should this be allowed? I suspect that all Requests will be formed with attributes of known and intended values, so I think this is a real problem. Last, because the Attributes aren't being included in the Request in the scope of a Function, the requestor has no idea how the attribute will be used in the policy, and so trying to guess at the value based on the function's types seems very dangerious to me. I would suggest that the type field in the Attribute type be made manditory. It may not seem as pretty in the language, but it heads off a lot of ambiguity without adding almost any overhead to the language (or making it any harder to form a Request), and that seems like a very worthwhile tradeoff to me. I would welcome any discussion on this topic with those of you on the list. I would like to see a final version of the language soon, so please don't take any of this as an attempt to slow things down. I have backed off on other issues with Anne that I didn't think were worth taking the time to address, but I feel this issue is pretty important to sort out. Including the types of Attibutes and AttributeValues is a seriously small piece of the schema, but it can have significant effects on implementation and interpretation. thanks seth -- Internet Security Research Group Sun Microsystems Labs ------- end of forwarded message -------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC