Hi Massimiliano,
This contribution is much appreciated by the XACML community. It
appears
to address a missing aspect of the XACML specifications, and
potentially
can play a significant role in advancing the XACML standard.
We will place it on the list of reference (implementations) on the
XACML TC
home page, either in its current form, final form, or whatever you
prefer.
However, I do have a number of questions of a detailed level, which
are
primarily looking for clarifications or identifying possible typos.
I also
have some suggestions, which I will indicate, but wait for the
clarifications
before elaborating on them.
Here are the initial set of comments I would like to have answers
to, which
I think are necessary before I can fully evaluate the paper:
- p13, table 1: (actually also tables 2,3) Personally, I think
the title of table
should be "Policy Set Evaluation" (singular) instead of the
current
"Policy Sets Evaluation" (plural). As I look at the 3 columns, I
see the
possible outcomes of evaluation of one Target, multiple Policy
or
PolicySet elements within a single PolicySet, and a single value
in
column 3 for the "value" of a single PolicySet.
- p13, table 1: column 2: I believe that because a PolicySet can
contain
multiple Policies and multiple PolicySets that the title of this
column
would be better as "PolicySet/Policy Values", instead of the
current
"Policy Values" (note: I have capped all words in the column
headers,
but that is just a suggestion as well, however if only the
element names
are capped, then that I think is ok, too)
- p15: I suggest adding a "Table 6a" or "Table 7" that will show
the
evaluation of a single "match element". In particular, I think
that the
last paragraph before section 3, starting with "Finally, the
evaluation
of a match element ..." describes what should be in this
proposed
table.
- p16, table 7: My sense is that this should begin as something
like:
PDPpolicySet ::= Palg;PolicySet (single top level PolicySet)
PolicySet ::= { Palg;PolicySet | Ralg:Policy } (multiple
PolicySets and Policies)
I am not sure of the syntax of the above lines, which will come
out
in some subsequent comments below.
- p16, table 7: I do not understand the "double constructs" that
appear at
the end of the Policies line: " | Policies Policies " and at
the end of the Rules line: " | Rules Rules "
Please explain, maybe I missed it in the text.
- p16, table 7: the second line of the Policies defn has angle
brackets
surrounding the "policy". I assume this indicates there is only
"one"
construct allowed, as opposed to the curly brackets in the prev
line
which I assume means repeated constructs are allowed (in the
PolicySet).
- A general suggestion on p15, sec 3.1 1st para: please explain
here, in addition
to the square brackets, all the other constructs that are used
in the EBNF
syntax you are using. BNF is notorious for having as many
dialects as there
are authors who use it, so in the absence of a solid std,
authors should
probably, imo, say what they are using in enough detail incl a
ref to a BNF
baseline that will enable a reader not to have to deduce it all.
- p18: preliminary comment on the general match element as
opposed to
the XACML 2.0 category-specific match elements: XACML 3.0 has
taken
this approach, and, imo, unfortunately, while cleaning up the
syntax,
has muddied up the semantics. In particular, the
category-specific matches
had the benefit of maintaining all the matches that were grouped
together
as automatically referring to the corresponding category in the
request.
In 3.0 by generalizing the match elements, there was a possibly
inadvertent
side effect of no longer having this correspondence, which
effectively means
that any group of attrs in the policy can refer to anything in
the request.
I think the same issue may be introduced here. There are ways to
address
this, but they have been deferred for the present, however, I
advise being
careful not to introduce this issue in a 2.0 context.
One additional piece of info is that the OpenAz project has an
"abbreviated" XACML
syntax that I believe can fit into the semantics you have proposed:
http://openliberty.org/wiki/index.php/OpenAz_Main_Page
One would need to go the code repository that is linked from the
wiki to get to
the details, but I expect that once I have the syntax in the paper
clarified that
we will be able to do the mapping.
A final comment is that I think you have done a great job on this
paper, and I look
forward to working with it in the immediate future.
Thanks,
Rich
On 12/23/2011 3:54 AM, massimiliano.masi@gmail.com wrote:
Hello All,
At the university of Florence, we have worked on providing a
denotational semantics
for XACMLv2, available at:
http://rap.dsi.unifi.it/xacml_tools/xacmlFormalisationFULL.pdf.
We first introduce a simpler syntax for policies, and
then we define a semantics for that syntax in a denotational style.
We implemented the semantics in order to provide some additional assurance
of the usability of such formal semantics. The implementation is available at
http://rap.dsi.unifi.it/xacml_tools/
We believe that such mathematical foundations can be used as a basis for further
formal analysis on policy equivalences, policy ordering, and other
similar concepts.
An extended abstract will appear in the proceedings of ESSoS 2012
http://distrinet.cs.kuleuven.be/events/essos/2012/
to appear in the LNCS series - Springer.
Ciao,
Massimiliano
|