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] Minutes 11 September TC Meeting


Hi Erik,

My issue was with the TC intent to reduce the status of the p-code
from normative to non-normative. I don't think such an action should
be taken without definite reason, which as my email explained appeared
to me to be insufficient to justify.

I have no objection to improving the text. I have generally used the
p-code and never really scrutinized the text in much detail. However,
now, when looking at the existing text, I can see if someone was
using that as the basis for design they would have problems. I
think the suggested text improves to soundness of the logic of
the existing text, but it also takes away some of the motivating
notions within the existing text. If those motivating factors could
be preserved possibly as prelude to the suggested text and if
the p-code was kept as is, then I think that would be a
reasonable action to take.

Thanks,
Rich


Erik Rissanen wrote:
48CDF88C.9010700@axiomatics.com" type="cite">
Rich, All,

I think the pseudo code is fine as well, so either way is good for me.
But I don't understand all your objections in your email.

The proposed description is not written in a formal logic, it's written
in English, which I think is fine for this purpose. I don't think there
is any ambiguity in the proposed text. Perhaps it's missing the implied
step "0. Evaluate all rules". The remaining steps refer to the results
from this initial step.

And the pseudo code is not formal logic either, so it is as ambiguous as
the natural language text.

In any case, we need to change the specification in some manner because:

1. There are currently two descriptions for each combining algorithm,
one in English and one in pseudo code, and no statement of which of them
is the normative one.

2. The natural language description is currently not correct. It does
not cover all possible cases.

So we need to fix the natural language description and then choose
either it or the pseudo code as the normative one. I don't mind which
one, as long as they are both right. :-)

Best regards,
Erik


Rich.Levinson wrote:
  
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
      
---------------------------------------------------------------------
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
    


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

  


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