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 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:
  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:
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 



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