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


Subject: 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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]