[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Minutes 11 September TC Meeting
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]