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