Re: [xacml] Minutes 11 September TC Meeting

["Rich.Levinson" <rich.levinson@oracle.com>]

To TC:

Having now had a chance to look over the implications of
the decision to make the p-code non-normative and be
replaced by so-called "simpler text"

   "Rule combining algorithms - The TC will create simpler text
   description to describe combining algorithms as suggested on the
   list. The pseudo code will be listed as non-normative."

*I must express strong disagreement with this decision.*

I assert that the "simpler text" is only simpler because it
throws out the well thought out and technically unambiguous
logic of the p-code.

A simple comparison of the suggested text vs the p-code
makes this obvious. From the message:
http://lists.oasis-open.org/archives/xacml-comment/200808/msg00024.html

we have this logic suggested:

  Def.: Deny-overrides rule combining algorithm
    1. If any rule evaluates to "Deny", the result is "Deny".
    2. Otherwise, if any rule having Effect="Deny" evaluates to 
"Indeterminate", the result is "Indeterminate".
    3. Otherwise, if any rule evaluates to "Permit", the result is 
"Permit".
    4. Otherwise, if any rule having Effect="Permit" evaluates to 
"Indeterminate", the result is "Indeterminate".
    5. Otherwise, the result is "NotApplicable".

First problem: we have to define this logic so that it
is equally unambiguous. Therefore we have to say
that the "order" of the evaluation of the "conditionals"
is normative. We also have to define what a "conditional" is.

Second problem: the text within the so-called "conditionals"
is also ambiguous. What exactly does "if any rule" mean
that you have to do? Probably it means you have to
evaluate every rule. Therefore one is then looking at
a list of  "conditionals", the first four of which require
going thru this loop of all the rules.

Now one can easily say, "Oh, combine the "conditionals" into
a single loop for optimization purposes.". Therefore the whole
concept of some kind of standalone "conditional" breaks
down which further challenges us to define what a
"conditional" is in unambiguous terms.

I assert that going thru this exercise of replacing perfectly
good, unambiguous, tried and tested p-code with an
untested, ambiguous, non-standard, and as yet undefined
"language" of "conditionals" is a total waste of time for the
members of this TC.

The p-code is well thought out and known to be accurate.
If someone has trouble understanding it and needs the
"aid" of this proposed language of "conditionals", I have
no objection to adding such text as non-normative
addition to each section containing an algorithm with
some introductory text saying something like

    "The above p-code may be thought of as functionally
     equivalent to the following non-normative set of
     conditional statements:"

However, I will not be able to vote to approve any version
of the document that tries to replace the accurate p-code
with the clearly less-definitive text suggested above.

    Thanks,
    Rich




Bill Parducci wrote:
> 1. Roll Call
>    Hal Lockhart (minutes)
>    Bill Parducci (Co-chair, minutes)
>    Erik Rissanen
>    Anthony Nadalin
>    Rich Levinson
>    Hal Lockhart
>    Anil Saldhana
>    John Tolbert
>    Duane DeCouteau (non-voting)
>
>    Quorum reached 7 of 9 (77%)
>
>
> 2. Administrivia
>    Vote on minutes postponed to next meeting due to late posting
>    to list.
>
> 3. Issues
>
>   Open Issues on list
>    http://lists.oasis-open.org/archives/xacml/200809/msg00000.html
>
>    The TC has no objections to those Issues Erik suggests should be
>    considered No Action.
>
>    The TC has no objections to the Proposed Actions Erik presented on
>    the list.
>
>    Identifier conflict – the TC has chosen to resolve this by using:
>    urn:oasis:names:tc:xacml:1.0:subject:authentication-method
>
>    String comparison - the general consensus is this issue requires
>    more consideration. A possible source is XQuery's implementation.
>
>    Multiply function arguments - The TC agrees that 0 or 1 argument
>    will not be supported. The TC also agrees that Add and Multiply
>    arguments will BOTH allow multiple arguments in v3. V2 will not
>    be updated. The identifier will remain the same in V3.
>
>    Interger overflow - The TC agreed that interger overflow during
>    upon type conversion should be handled as an Indeterminate result.
>
>    Rule combining algorithms - The TC will create simpler text
>    description to describe combining algorithms as suggested on the
>    list. The pseudo code will be listed as non-normative.
>
>   Issue 72 SAML:Where should passed-in policies be inserted
>
>    Hal noted that the spec currently says that there is a top level
>    combining algorithm in an implied policy set. The TC decided that
>    the provided policies shall be inserted in the presented order
>    at the top of this policy set. Hal took an action item to propose
>    text which would include more explicit wording on the TLP set.
>
>   Issue 75: Defining an interface for closely coupled PEP/PDP
>    This will not be considered part of the core schema, rather it
>    will be addressed via a Profile. This is not on the V3 critical
>    path.
>
>   Issue 66: Missing attributes may be underspecified
>    This will discussed further on the list and will be taken up
>    on the next call.
>
> meeting adjourned.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php