Re: [xacml] Grammatical Issue w XACML 3.0 specification

On Sat, Jul 28, 2012 at 12:34 AM, Danny Thorpe <Danny.Thorpe@quest.com> wrote:

I appreciate the desire to make the XACML schema element names fit more naturally into English grammar patterns, but now is really not the time to be introducing breaking changes into the XACML 3.0 spec. XACML 3.0 is already out the door with implementations in the field. All we have remaining is the TC formality of crossing T’s and dotting I’s and declaring it done. Let’s not derail that process. Awkward as the current element names may be, let’s just accept it and push ahead.

We can take this up again when new feature work requires breaking schema changes and forces us to bump the spec version to 4.0.

Sincerely,

-Danny

Danny Thorpe

Product Architect | | Quest Software - Now including the people and products of BiTKOO | www.quest.com

From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of rich levinson
Sent: Friday, July 27, 2012 2:43 PM
To: xacml
Subject: [xacml] Grammatical Issue w XACML 3.0 specification

To TC:

This is an issue that has been bugging me for some time, and I have tried
to raise it in years past. Since we have a fairly new group participating now,
I am going to re-raise it to see if it resonates more than it has in the past.

This issue has existed since XACML 2.0 and before, but XACML 3.0 raises
it to what I consider a crisis level, and if we hope that XACML will gain
wide-spread acceptance, my suggestion is that we fix it sooner, rather
than later, preferably in XACML 3.0, but if not then, then immediately
thereafter.

The issue is that the XACML 3.0 <Attributes> element (plural) is not only
misnamed, but misnamed in such a way as to render the XACML Policy
model indescribable using common English grammar.

I think the problem is best described by a simple analogy. Let's consider
an application for a bookstore where the application did stuff associated
with "books". Now, in order to write this application, the developers
came up with an XML model for books, and presciently recognizing
that books, in general, are comprised of "chapters" decided to represent
the book as a collection of <Chapter> elements.

Now, the developers recognized that they would need to be dealing
with collections of these <Chapter> elements, and decided to name
the collection <Chapters>.

So, now in a truly efficient manner, we can represent a book as follows:

<Chapters title="Gone w the Wind">
<Chapter chapnum="One">
<Chapter chapnum="Two">
     ...

In the process we have tossed out the word "book" since we no longer
need it to represent the collection of chapters.

Now, we are faced with the following problem when talking about
this application. Let's say we wanted to know how many books
an author has written, we'd have to say something like:

"How many <Chapters>s has author X written?"

Similarly, if we wanted to know how many chapters of a specific
book a person has read, we would say something like:

"How many <Chapter>s of the <Chapters> you bought have you read?"

This is exactly the position that using the name <Attributes> to represent
a collection of <Attribute>s puts us in.

Policies are written to determine what Subject entities are authorized
to perform what Action type on what Resource entities under what
conditions in the Environment scope.

XACML 3.0 provides no convenient way to talk about these entities
that are the main components about which Policies are written,
without first defining a parallel vocabulary and grammar that
can be used to resolve the obvious ambiguities that result
from using the XACML element and attribute names.

One suggestion to resolve this issue would be:

Replace the term <Attributes>
with the term <Entity>

Every application deserves to have an "Entity element" to represent the
general notion of an object that is a significant component of the
application's operational structure. Objects can have a category
that represents the type of object it is to distinguish between
different objects in semantic descriptions of the application.

One final note is that the term "entity" is used in the XACML spec,
sometimes in the sense described above, other times to describe
things like a PDP vs a PEP, and other times where it doesn't seem
to represent anything at all, for example in section 5.9 <Match>,
the Match element is defined as:

"The <Match> element SHALL identify a set of entities
by matching attribute values
in an <Attributes> element of the request context
with the embedded attribute value."

I cannot seem to come up with anything meaningful that
the above statement is saying or even trying to say.

My understanding is that similar to a <Condition> element,
that a <Match> element is "a Boolean function over attributes".

In any event, the purpose of this email has been to try to raise
awareness of what I consider to be a pretty serious issue wrt
usability of the XACML specification, namely simply being able
to talk about the spec and what it means in real world terms.

    Thanks,
    Rich

xacml message