That sounds good to me.
On 5/31/2011 8:04 AM, Erik Rissanen wrote:
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
and one line in the code: "Decision decision =
This makes it more explicit where the evaluation happens.
Otherwise it may be unclear whether the Decision() constructor
must defer evaluation.
On 2011-05-30 21:09, rich levinson wrote:
There is an improved suggested algorithm in the Implementers
Guide that more fully
preserves the current algorithm and removes the cast:
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
- 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
- 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 =
- 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
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
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
interest that I will include shortly.
On 5/30/2011 10:25 AM, Erik Rissanen wrote:
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.
On 2011-05-30 04:41, rich levinson wrote:
Clarifications to some points in the minutes - in line.
On 5/26/2011 7:14 PM, Bill Parducci wrote:
Above should be
I. Roll Call
Hal Lockhart (Chair)
Bill Parducci (Co-Chair, minutes)
| David Broussard
Quorum NOT met: (47% per Kavi)
I. Roll Call & Approve Minutes:
NO vote on minutes for 19 May 2011 TC Meeting
Hal noted that he will request at that next call we move back to
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
"Permit-biased|Deny-biased PEPs & Extended
(see sections 7.2.2, 7.2.3 of core spec. for ref to PEP not
And here is link to issue (raised after agenda, but before
The suggestion is to percolate up in all cases. There is no
notion of "PDP bias". The
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.
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.
The suggestion I made was to dig into section 2 of "the
paper that is referenced in
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.
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
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
To make this issue a little more clear, there are 2 types on
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.
behavior that can occur that appear to be part of the
The above clarifications are in addition to the original
issue that was raised:
- If a deny-overrides combining algorithm returns the
the first Deny it encounters, then if there are
Deny's that had their own Obligations that could have
then another evaluation of the same request could have
Obligations from another Deny.
This type of non-determinism cannot be resolved w/o
Rules/Policies, which is covered by the
This aspect of the issue is fairly well understood.
- 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
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
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
are expected to do.
Once it is resolved what the spec currently says about
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
V. Carryover Issues
Indeterminate Policy Target handling
PDP REST Interface - proposal
("Towards the creation of XACML PEPs")
Attribute predicate profile for SAML and XACML
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)
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: