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 for 26 May TC Meeting - UPDATED - clarificationson new issues

Hi Erik,

That sounds good to me.


On 5/31/2011 8:04 AM, Erik Rissanen wrote:
4DE4D960.2050703@axiomatics.com" type="cite"> Hi Rich,

Thanks. I think it can be made even simpler if say: "'Node' represents a PolicySet, a Policy or a Rule. A node can be evaluated to produce a decision, as defined in Section 7."

Then we change the signature to: "Decision denyOverridesCombiningAlgorithm(Node[] children)"

and one line in the code: "Decision decision = children[i].evaluate();"

This makes it more explicit where the evaluation happens. Otherwise it may be unclear whether the Decision() constructor must defer evaluation.

Best regards,

On 2011-05-30 21:09, rich levinson wrote:
4DE3EB7E.5090909@oracle.com" type="cite"> Hi Erik,

There is an improved suggested algorithm in the Implementers Guide that more fully
preserves the current algorithm and removes the cast: Recommended implementation strategy

In order to preserve the structure of the XACML 3.0 algorithms, and, at the same time, allow for optimization of those algorithms, the following general approach is suggested:

  • Prior to calling the combining algorithm, wrap each of the decision-producing child nodes (which include PolicySet, Policy, and Rule nodes) of the current node (which will either be a PolicySet or Policy node) within what we will call a Decision object. For example, one could create a Decision object with the following constructor:
    • Decision decision = new Decision(node[i]);
  • Therefore a collection of child Decision nodes can be accumulated, which do not require actually evaluating the node that they contain.
  • Then one can pass the collection of unprocessed nodes to the XACML 3.0 combining algorithm.
  • Now, in order to get the Decision for the current node in the algorithm’s loop, all one needs to do is execute the following statement:
    • Decision decision = decisions[i].getDecision();
  • Now, the “magic” is that the getDecision() method can be implemented, such that if the evaluate() method has not yet been applied to the node that was passed in to the constructor, then that evaluate() method can be executed now in order to obtain the actual Decision value.
  • Similarly, since the return “value” from the algorithm is also a Decision object, the caller
    will also have to use the getDecision() method to get the value, however, this time, since evaluate has already been called the Decision object would simply return the value that was calculated on the first access and not do the evaluate again.

 i.e. this recommends only changing the 2 lines indicated above, while treating the Decision object
as having more capabilities to both create a value within a constructor and to return a an enumerated
value by getDecision().

Note: I have some updated information on the referenced paper in the implementers  guide that should be of general
interest that I will include shortly.


On 5/30/2011 10:25 AM, Erik Rissanen wrote:
4DE3A8C9.5050609@axiomatics.com" type="cite"> Hi Rich,

I agree with your point that there is an ambiguity with how obligations are returned, or maybe not an ambiguity, rather an unintended change in behavior. Thanks for noticing this. :-)

Section 7.16 essentially says that obligations are passed up from the policies/rules which "are evaluated". So the exact point at which the combining algorithm performs the evaluation has a significance for the returned obligations, although not for the decision.

So I think we should do as Rich proposes and change the pseudo code so it has an explicit "evaluate" in it. Though I think the representation Rich made can be simplified a bit. For instance, I don't think the cast to a Rule is needed.

Best regards,

On 2011-05-30 04:41, rich levinson wrote:
4DE303E8.7040403@oracle.com" type="cite"> Hi Bill,

Clarifications to some points in the minutes - in line.


On 5/26/2011 7:14 PM, Bill Parducci wrote:
9164EE5E-3B4C-40A6-9123-AB2A23CCA189@parducci.net" type="cite">
I. Roll Call
 Voting Members
  Hal Lockhart (Chair)
  Bill Parducci (Co-Chair, minutes)
  Paul Tyson
  Doron Grinstein
  Remon Sinnema
  Anthony Nadalin
  Rich Levinson
  Hal Lockhart
  John Tolbert

|  David Broussard

 Quorum NOT met: (47% per Kavi)

I. Roll Call & Approve Minutes:
  NO vote on minutes for 19 May 2011 TC Meeting

II. Administrivia
  Hal noted that he will request at that next call we move back to 
  biweekly calls.

 XACML 3.0 core wd 20 uploaded
  The TC is encouraged to review.

  Hal will create a poll to gather the final attendance count for the 

III. Issues Discussed
 PDP REST Interface (PAP)
  Hal noted that the current thinking on the list attribute
  information would be in JSON and transported using a POST over HTTP
  with the response. He offered that he personally would like to see
  this done in such a way that doesn't cap the functionality. 

  David Chadwick concurs with this and noted that his current
  prototype doesn't cover Multiple Resources, but that this isn't part
  of the Core spec. 

  Paul pointed out that the W3C is working to develop standardized
  mechanisms for expressing RDF graphs and that XACML fits within the
  scope of this work. Therefore the TC should consider building upon
  that work. Alternatively, he offered that a "bridge" between XACML
  and the W3C work may be developed.

  Hal countered that direct association with the concept of "Semantic
  Web" work may defeat the underlying driver for this project 
  (enhanced approachability of XACML).

  Paul noted that he is not against any efforts to make XACML more
  approachable in HTTP based environments.

 XACML Implementers Guide
  Rich reviewed his position on the ramifications of how the current 
  direction on extended Indeterminate response and what it may mean to
  new adopters. This lead to the revival of the Adopters Guide. Rich
  asked that the TC consider adding/updating content to the guide as
  for changes to the spec/Profiles that have been added since the 

IV. New Issue
 Permit|Deny Bias PDPs & Extended Indeterminate
Above should be
    "Permit-biased|Deny-biased PEPs & Extended Indeterminate"
(see sections 7.2.2, 7.2.3 of core spec. for ref to PEP not PDP)
And here is link to issue (raised after agenda, but before meeting):
9164EE5E-3B4C-40A6-9123-AB2A23CCA189@parducci.net" type="cite">
  Rich introduced and issue that was derived from comments by
  Indeterminate (D|P) results need to be percolated up to the response
  when generated by PDP bias.
The suggestion is to percolate up in all cases. There is no notion of "PDP bias". The
point is that a PEP-bias can make use of this information, which can be ignored by
a "Base PEP" section 7.2.1.
Also, the point of returning the extended indeterminate is that a deny-biased PEP (7.2.2)
may Permit a response that is Ind-P, meaning that since there was no explicit Deny,
AND there was no Indeterminate that could have produced a Deny, then Permit
can be allowed.
Similarly, but opposite sense in 7.2.3 permit-biased PEP.

9164EE5E-3B4C-40A6-9123-AB2A23CCA189@parducci.net" type="cite">
  Paul asked for clarification where Ind(D|P) would be applicable in a
  real world example. He noted that and Ind(D) could not be converted 
  into a Permit. Rich offered that additional Attributes could result 
  in a N/A. Paul replied that this still doesn't result in a practical
  Use Case. Rich suggested that the TC dig into Chapter 2 of the
  Implementor's Guide to begin the clarification process.
The suggestion I made was to dig into section 2 of "the paper that is referenced in
Implementers guide". i.e. there has been some difficulty getting across the meaning
of the extended indeterminate, and section 2 of that paper,
has good information explaining the issues that extended indeterminate addresses.

The point being that since we have had a lot of email discussing this issue, and
there are still misunderstandings, then possibly having the viewpoint of an external
party that has not been involved with our discussions, but has analyzed the same
issues, might be useful for people to look at for additional perspective.

9164EE5E-3B4C-40A6-9123-AB2A23CCA189@parducci.net" type="cite">
 Obligations/Advice combining ambiguities.
  Rich asked for input on the current understanding on how Obligations
  /Advices are combined in a deterministic manner. Hal reviewed the 
  historical context of the desire for unordered evaluation. Rich
  will post a proposed solution to the list that is based upon the
  concept of a "default" behavior, that is followed by a list of an
  enumerated list of Obligations/Advices that are attempted.
To make this issue a little more clear, there are 2 types on non-deterministic
behavior that can occur that appear to be part of the overall discussion:
  1. If a deny-overrides combining algorithm returns the Obligations from
    the first Deny it encounters, then if there are subsequent un-evaluated
    Deny's that had their own Obligations that could have been returned,
    then another evaluation of the same request could have returned the
    Obligations from another Deny.
    This type of non-determinism cannot be resolved w/o "ordering" the
    Rules/Policies, which is covered by the "ordered-deny-overrides"
    combining algorithm.
    This aspect of the issue is fairly well understood.
  2. The 2nd type of non-determinism arises from the discussions on the
    Signature of the deny-overrides combining algorithm, where it was
    basically said that breaking the loop when encountering the first
    Deny as in XACML 2.0, that was removed from the algorithm in 3.0,
    should be regarded as some kind of "optimization" and not an inherent
    part of the algorithm.
    In this case, there is the possibility that a "less optimized" PDP would
    evaluate the decisions prior to applying the algorithm, in which case
    Obligations from more than the first encountered Deny rule would
    be created and presumably returned.
    If this is an inherent part of the algorithm then it should be explicitly
    included to remove this ambiguity, or explained what implementers
    are expected to do.
The above clarifications are in addition to the original issue that was raised:

Once it is resolved what the spec currently says about returning obligations,
wrt combining algorithms (section 7.18 is a good start, but does not address
the points raised in this issue, at least, afaict), then I will be able to propose
more details about defining a default and optional behaviors that can close
the remaining "imbalances" in the algorithms as they currently stand.


9164EE5E-3B4C-40A6-9123-AB2A23CCA189@parducci.net" type="cite">
V. Carryover Issues
 Indeterminate Policy Target handling

 PDP REST Interface - proposal 
  ("Towards the creation of XACML PEPs")

 Attribute predicate profile for SAML and XACML

 XACML Metadata

 Attribute predicate Profile for SAML and XACML

 Break The Glass Profile

 Profile Examples (Hierarchy) 

 PIP directive (additional information directives)

 Usage of status:missing-attribute in case of an AttributeSelector

 "Web Friendly" Policy Ids

 Specifying a specific associated Resource in a Policy (Sticky Policies)

meeting adjourned.

Next meeting June 2, 2010.

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:

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