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,
Erik
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.
Thanks,
Rich
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
Member
| David Broussard
Quorum NOT met: (47% per Kavi)
I. Roll Call & Approve Minutes:
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.
F2F
Hal will create a poll to gather the final attendance count for the
F2F.
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
guide
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):
http://lists.oasis-open.org/archives/xacml/201105/msg00092.html
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,
https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/2008-9-report.pdf
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:
- 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.
- 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:
http://lists.oasis-open.org/archives/xacml/201105/msg00094.html
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.
Thanks,
Rich
9164EE5E-3B4C-40A6-9123-AB2A23CCA189@parducci.net"
type="cite">
V. Carryover Issues
Indeterminate Policy Target handling
http://lists.oasis-open.org/archives/xacml/201105/msg00090.html
PDP REST Interface - proposal
http://lists.oasis-open.org/archives/xacml/201105/msg00056.html
http://lists.oasis-open.org/archives/xacml/201105/msg00086.html
("Towards the creation of XACML PEPs")
Attribute predicate profile for SAML and XACML
http://lists.oasis-open.org/archives/xacml/201105/msg00088.html
XACML Metadata
http://lists.oasis-open.org/archives/xacml/201105/msg00004.html
Attribute predicate Profile for SAML and XACML
http://lists.oasis-open.org/archives/xacml/201104/msg00080.html
Break The Glass Profile
http://lists.oasis-open.org/archives/xacml/201104/msg00082.html
Profile Examples (Hierarchy)
http://lists.oasis-open.org/archives/xacml/200910/msg00024.html
PIP directive (additional information directives)
http://lists.oasis-open.org/archives/xacml/201010/msg00005.html
Usage of status:missing-attribute in case of an AttributeSelector
http://lists.oasis-open.org/archives/xacml/201104/msg00003.html
"Web Friendly" Policy Ids
http://lists.oasis-open.org/archives/xacml/201103/msg00046.html
Specifying a specific associated Resource in a Policy (Sticky Policies)
http://lists.oasis-open.org/archives/xacml/201103/msg00012.html
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|