Re: [xacml] complexity going forward

[Seth Proctor <Seth.Proctor@Sun.COM>]

> in my mind XACML was never intended to be an end
user language. 
> while i 
> think that it is a powerful language for policy
expression and is 
> an 
> excellent base for policy storage, it's real value
is it's ability 
> to 
> interchange policy information (be it for
auditing, migration or 
> integration). in that light, *hopefully* the only
people that will 
> have 
> to be able to read/write xacml will be
programmers. this isn't to 
> say 
> that complexity should be ignored, but that the
tolerance for such 
> is 
> higher amongst the beanie headed... :o)

Well, of course XACML isn't an end user language. No
XML-based language should be. And yes, XACML is very
nice as an intermediary form, and I suspect it will
be used that way. But it will also be used for
policy expression and evaluation, and eveyone I'm
taking with right now is using XACML as their policy
system, not as a translation medium. This is to be
expected.

Regardless, I don't expect that anyone should have
to work with the language directly (ie, editing XML
by hand), programmers included. I'm hoping that good
tools will get built that insulate most people from
this level. Still, someone will have to work with
these tools to build policies and understand how
policies relate to each other, which means they'll
need to understand how XACML works even if they
don't need to know the syntax. This means that any
feature that _semantically_ adds to the
specification also adds complexity to any use of the
language at any level. If the spec gets a new
reference mechanism, or properties, or different
ways to handle obligations, these will all affect
the people who are working with policies no matter
how well they're insulated from the syntax, and most
of these people will not be "beanie headed" :)

One other thing: I'm a programmer. I've built an
implementation of XACML. I consider myself to be
fairly intelligent and to have above-avergage
experience with policy. I've now written dozens of
example policies and lots of examples of how to form
simple requests. When I sat down to support complex
policy requirements in a real-world application
using a custom database and attribute retrieval
system, it was hard. Period. Tools and other
abstractions would have made it easier, but just
understanding the implications of all the policy
references and the each target on a rule took a lot
of effort. If that's my experience, what will a
sysadmin, IT person, or average coder see? I can
tell you based on what I'm already hearing that they
need _a lot_ of hand holding just understanding the
ideas, regardless of whether they're looking at the
syntax. This is my motivation for sending mail to
the list.

> > I'm particularly curious about demand for some of
> > the features being discussed.
> 
> is there anything in particular that seems non
'real-world' in 
> your mind?

I never said that any of the examples weren't "real
world," I'm just asking whether there has been any
attempt to draw from real experience using this
language. It's one thing to come up with things that
sound likely, it's another thing entirely to add new
features that are actually needed or wanted. XACML
is already very complex, and it seems like any
features that are added quickly (ie, before everyone
can digest 1.0) should have a strong justification,
not just a plausible use case. Again, this is just
my opinion.


seth