[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">Above should beI. 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 "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">The suggestion is to percolate up in all cases. There is no notion of "PDP bias". TheRich 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. 9164EE5E-3B4C-40A6-9123-AB2A23CCA189@parducci.net" type="cite">The suggestion I made was to dig into section 2 of "the paper that is referenced inPaul 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, 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">To make this issue a little more clear, there are 2 types on non-deterministicObligations/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 overall discussion:
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]