Re: [xacml-users] Contribution for the XACML Reference list

["massimiliano.masi@gmail.com" <massimiliano.masi@gmail.com>]

Dear Rich,

Thanks a lot for your mail. Sorry for the late answer, but I was
abroad after christmas (a long week in the www.ihe.net connectathon
event). Please find my comments below.

On Tue, Jan 10, 2012 at 7:34 AM, rich levinson <rich.levinson@oracle.com> wrote:
> 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.

Yes, you are absolutely right. We are going to address these issues in our
technical report.


> 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.

We see these issues related. We think that the difficulties in understanding
syntax of the policy language are due to an unfortunate notation: brackets
( . ), < . > and { . } are terminal symbols of our grammar (in fact,
they are used
as delimiters for rules, policies and policy sets, respectively), while
brackets [ . ] are used as EBNF meta-notation to indicate optional
items (that is,
everything that is set within the square brackets may be present just once, or
not at all). This might be confusing (the examples in Sec. 3.1 may
help to clarify).
We will add some remarks in the technical report on the dialect of the EBNF
that we used, in order to clarify.

Instead, regarding the "double constructs", it simply indicates the
juxtaposition of two terms. For example, the production
Rules   ::=   (Effect; ...)   |   Rules  Rules
means that within the block "rules:{...}" of a policy there can be
more terms of the form (Effect; ...) juxtaposed.

> 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.

As you correctly notice, in order to obtain a simpler syntax and
a manageable semantics, we have generalized the match elements by
avoiding the explicit use of categories in the syntax of targets.
This is justified by the fact that the evaluation of the information
in different categories is performed in the same way. However,
to adhere to the XACML 2.0 specification, and hence
to avoid the side effect that you mentioned above
(i.e. matches can refer to anything in the request), it is required
a disciplined use of names and the three logical operators we use
for expressing targets (as shown in Section 3.1). In our examples,
we use structured names (using the dot-notation) to express the
logical categories, e.g. subject.xspa_subject-id may represents
the XSPA Subject ID value (i.e. it refers to the Subject category).
What is your opinion on that?


> 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.

This would be really interesting. Unfortunately, I wasn't able to
access the grammar defined.
Can you please point me at the docs or to the code? We would be really
glad to start working
on that.

Best Regards,

      Massimiliano (also on behalf of the other authors)


-- 
Massimiliano Masi

http://www.mascanc.net/~max