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: Re: [xacml-users] Contribution for the XACML Reference list

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:
  1. 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.
  2. 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)
  3. 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
  4. 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.
  5. 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.
  6. 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).
  7. 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.
  8. 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:

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.


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:


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


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
to appear in the LNCS series - Springer.



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