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] wd-19 indeterminate policy target handling / wd-20 /proposed resolution

To TC,

In an attempt to bring the combining algorithm issue to a satisfactory close,
and following the guidance of the TC at last week's meeting:
(see note about continuing discussion on separate impl strategy thread),
I have uploaded a proposed implementor's guidance section in the context
of resurrecting the old Implementor's Guide, which we have been talking
about doing for a long time, but there has not been a threshold issue to
initiate the effort. I considered this issue significant enough to pass the
threshold of need to get it going, and thus uploaded proposed starting point,
as a modification to the long dormant original Implementor's Guide.

I believe I have captured the issue and presented information to implementors
and users alike that should explain the issue that people may encounter and
the strategy for addressing it. I believe I have incorporated everyone's input,
and this can serve the purpose of handling concerns regarding this issue that
may come up in the future. In addition, the doc contains a ref to some previous
work that was done on this exact same issue, which should provide another
reference point for understanding both the issue and possible solution spaces
for addressing the issue.

With this explanatory note, I believe the current spec can be used pretty much
as is (there are a few suggested cosmetic changes to facillitate consistency in
some of the earlier emails that may be useful, although none are critical enough
to require separate action).

The information in the first draft is intended to be the minimum necessary to
bridge the conceptual issues that have been raised against the current spec, and
serve the purpose of setting the perspective so that developers and users can
clearly understand what their options are.

The text was written with the changes currently in WD-20, so everything should
be current and consistent.


On 5/22/2011 5:10 PM, rich levinson wrote:
4DD97BC2.4070802@oracle.com" type="cite"> Hi Ray/TC,

I want to emphasize that I consider this a serious issue, and hope that people can
bear with what some might consider a waste of time picking at details of marginal
relevance to specification.

In particular, to emphasize the seriousness, please consider the following points:
  • Section 2.1 Requirements, lists the basic requirements for a policy language
    for expressing information systems security policy, of which the first item is:
      "To provide a method for combining individual rules and policies into a
        single policy set that applies to a particular decision request. "
  • In order to test compliance with the specification, it is necessary to be able
    to define meaningful tests that an implementation can execute to demonstrate
    such compliance.
I also want to say that I consider the fact the Ray has implemented to this spec,
and has provided detail in prev email as to the nature of that impl, as valuable
input for analyzing the integrity of the algorithm that we are discussing, which
is lines 5740-5799 of section C.2 of WD19, which is declared on line 5739 to
"represent the normative specification of this combining algorithm".

All that being said, there are a few points that Ray mentioned that I would like to
respond to in the interests of advancing this discussion toward some kind of closure
where we are all satisfied that the spec is meeting our objectives (which, while
unstated, I assume are well understood in conventional software engineering terms).

To the specific points:
  • Ray said: "remember this is *pseudo*-code, not actual code".
    • I agree, but also would like to point out that pseudo-code, in order
      to be meaningful must be consistent in its use of terminology. i.e. the
      terms used cannot arbitrarily change their meaning partway thru
      the algorithm.
    • In order to test this consistency, please look again at the algorithm signature:
        Decision denyOverridesCombiningAlgorithm(Decision[] decisions)
      If the p-code is considered to be consistent, then I think it should be
      self-evident that what is returned is an instance of Decision, where "Decision"
      may be implicitly defined as one of the "values" returned on any of lines:
      • 5751 return Deny
      • 5780 return Indeterminate{DP}
      • 5784 return Indeterminate{DP}
      • 5788 return Indeterminate{D}
      • 5792 return Permit
      • 5796 return Indeterminate{P}
      • 5798 return NotApplicable
    • Since this set of return values actually represents the full set of possible
      return values defined by XACML (where the D,P,DP can be considered
      internal combining algorithm intermediate values that are removed
      from the final result which is just Indeterminate w no qualifier, when
      any of the qualified Indeterminates are the preliminary final decision),
      then for consistency, the input: Decision[] decisions, of necessity is
      a collection of Decision instances each of which can be one of the
      list enumerated above. (or, as discussed below, conceptually can
      be some kind of object that will resolve to one of these instances
      when pulled from the input collection.)
  • The next point was that "arrays and iterators are conceptually equivalent", at
    least in terms of p-code.
    • For the moment, as I prev indicated, I will accept that premise, because
      I understand the point to be that the distinction between these two forms
      of collection are not particularly relevant to the concerns of the combining
  • The next point was that "the iterator should return Decisions, not unprocessed nodes"
    • As mentioned above, I agree with this point as being required in order
      for the p-code to be self consistent.
    • However, it appears to me that given that, that the iterator must be
      envisioned to be operating on a collection of yet to be resolved objects,
      such as an object that is equivalent to "evaluate(node)", where the
      evaluate is not executed until the iterator performs the next() operation.
    • To me, this is not an ordinary construct that one can assume is meant
      by the algorithm specification. On the one hand the algorithm explicitly
      says the output is one of the enumerated Decision instances listed above,
      but implicitly says that a collection of these same objects on input may
      be regarded as "unresolved instances, to which some sort of handle and
      evaluation mechanism is attached".
      • This is the primary issue that I have with Ray's response, which is
        that while I understand what is being said, on the other hand,
        I do not think it is reasonable to expect a reader of the spec to
        be able to consider such an abstraction to be implicit in the
        specification of the algorithm. i.e. a clearly defined output object,
        with no further explanation is expected to be able to be envisioned
        as some kind of object with which there is little general familiarity.
So, I guess what I am looking for is some kind of definition up front that will state
that the Decision[] decisions input represents the set of values from the child nodes
of the current node, and that either the decisions independently obtained from those
nodes for "static" processing , or the unprocessed nodes themselves may be passed
in for "dynamic" processing.

If we can reach agreement on that then I think there are a couple of other minor
details that we should address:
  1. recommend that text similar to 2nd para above be included in section C.1 to describe
    the assumptions about the input Decision[].
  2. recommend that "normative" be applied to the definitions on lines 5701-5712.
  3. recommend that a statement be added that "Indeterminate" is what is returned
    as the "final" decision (i.e. the D,P,DP qualifiers are stripped off - I don't recall having
    seen that mentioned anywhere).
  4. recommend that section 7 be updated in some places mentioned before in earlier
    emails so that the terminology is consistent. Explicitly identifying each spot pending
    agreement on the above.

On 5/21/2011 5:57 AM, remon.sinnema@emc.com wrote:
2B109622CFC23D4BA8349254A011FBE001497D4FAB@MX27A.corp.emc.com" type="cite">

From: rich levinson [mailto:rich.levinson@oracle.com] 
Sent: Saturday, May 21, 2011 12:06 AM
To: Sinnema, Remon
Cc: xacml@lists.oasis-open.org
Subject: Re: [xacml] wd-19 indeterminate policy target handling

That being said, maybe we can rephrase the issue as to what it means when it says on line 5739:
"The following pseudo-code represents the normative
  specification of this combining algorithm."
The first line of the algorithm that follows appears to be some kind of
interface signature:
Decision denyOverridesCombiningAlgorithm(Decision[] decisions) <<

2B109622CFC23D4BA8349254A011FBE001497D4FAB@MX27A.corp.emc.com" type="cite">
Yes, but remember this is *pseudo*-code, not actual code. IMHO, the implementation doesn't necessarily need to have the exact same interface, as long as it's conceptually equivalent, IOW, as long as it gives the same results. I think this is what Erik has been saying all along.

It sounds to me like what you are saying is that when a software development organization sees that in the specification,
that said organization will be completely comfortable by implementing
the parameter, Decision[] decisions, by passing in an Iterator to a collection
of Decision objects that have not yet been resolved. <<
2B109622CFC23D4BA8349254A011FBE001497D4FAB@MX27A.corp.emc.com" type="cite">
Yes, because arrays and iterators are conceptually equivalent in this case, since the random access part of an array (that an iterator doesn't have) isn't needed for implementing any of the combining algorithms.

In other words, if a development organization first implements this algorithm by passing in a precalculated array as represented
by the normative interface signature, and then they complain
that it is too inefficient, that I can tell them to pass in an
Iterator to a collection of unprocessed nodes and just calculate
the Decision objects in the first line of the loop. For example,
I could suggest that the first line of the loop look something
    Decision denyOverridesCombiningAlgorithm(Iterator decisions)
    for ... {
        Decision decision = evaluate(decisions.next())
where Iterator.next() returns a PolicySet, Policy, or Rule, and "evaluate()"
produces the Decision. <<
2B109622CFC23D4BA8349254A011FBE001497D4FAB@MX27A.corp.emc.com" type="cite">
Well, the iterator should return Decisions, not unprocessed nodes, because that's what the algorithm needs to work on. The implementation of the iterator should do the evaluation when it's next() method is called. The combining algorithms shouldn't need to know anything about evaluating PolicySets, Policies, or Rules.

If that is what you are suggesting and people agree, then I am ok with that, as well, I think, assuming people really believe that this is an acceptable
view of the specification. <<
2B109622CFC23D4BA8349254A011FBE001497D4FAB@MX27A.corp.emc.com" type="cite">
I'm interested to see if anybody has any objections to this view, since this is actually how I implemented it ;)


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