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] | [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