[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes of the 5 February 2004 XACML TC Meeting
Minutes of the XACML TC General Body Meeting 5 February 2004, 10-11am EST Attendees: Tony Nadalin Anne Anderson (minutes) Michiharu Kudo Bill Parducci (Co-chair) Tim Moses Maryann Hondo Hal Lockhart (Co-chair) Seth Procter Steve Anderson Polar Humenn Frank Siebenlist Simon Godik Peiyin Pai (Observer) Quorum present 1. Minutes from the 22 January 2004 TC meeting http://lists.oasis-open.org/archives/xacml/200401/msg00052.html Anne moved they be accepted; Hal seconded; unanimous approval. 2. Face-to-Face Meeting plans Results as of today on the ballots to choose the date and location are: Can attend week of February 16 2 Can attend week of February 23 5 Can attend week of March 1 6 Can attend week of March 8 7 Can attend April 26 in New Orleans 12 Can only attend Boston 2 Can only attend Austin 0 Can attend either, no preference 0 Can attend either, prefer Boston 2 Can attend either, prefer Austin 9 Prefer week of February 16 1 Prefer week of February 23 2 Prefer week of March 1 6 Prefer week of March 8 5 Prefer April 26 7 Based on these early strong results, the Chairs will try to arrange a meeting in New Orleans during the week of April 26 in conjunction with the OASIS Annual Meeting and other OASIS TC meetings. The 3 Feb 2004 e-mail from Dee Schur at OASIS indicated that there was already a waiting list for TCs wanting rooms for meetings, so it may not be possible for the XACML TC to meet. Hal will clarify this with the OASIS administration. 3. XACML RBAC Profile The XACML RBAC Profile under discussion is at: http://www.oasis-open.org/committees/download.php/2405/wd-xacml-rbac-profile-01.doc Anne reviewed the history of the profile. There was a series of meetings with the NIST RBAC team, with general approval of the profile. The NIST RBAC team consisted of: Rick Kuhn <kuhn@nist.gov> David Ferraiolo <david.ferraiolo@nist.gov> Ramaswamy (Mouli) Chandramouli <mouli@nist.gov> John Barkley <jbarkley@nist.gov> Two issues were raised by the NIST team, however. One was a desire for a section on administrative policies. The other was from Mouli, who thought he could provide a simpler way to handle hierarchical roles in XACML. Anne responded that the RBAC Profile actually has a section on administrative policies. It relies on each entity (such as the Role Assigner/Enabler) using its own XACML policy; XACML does not currently support integrated administrative policies, such as are being proposed for XACML 2.0. On the second issue, Mouli has not produced a simpler way to handle hierarchical roles. Anne mentioned that many developers appear to be using the XACML RBAC Profile, based on feedback we get related to Sun's XACML Implementation open source. Some of these have urged making it a standard. Anne moved that the XACML TC approve the XACML RBAC Profile as a Committee Draft. Hal seconded. The XACML TC voted unanimously to make the XACML RBAC Profile a Committee Draft. Anne has an action item to edit it into the standard Committee Draft format, with no changes to normative text. Anne will post the edited draft to the XACML TC mailing list for any last editorial comments before the draft becomes the official "Committee Draft". 4. XACML 2.0 Work Items The TC discussed the following XACML 2.0 Work Items. o 7. ConditionReference General agreement that a single XML type to unify Condition, Condition references, variable references, predicates, and values would be good. The existing "Condition" element would be replaced by an instance of this single XML type restricted to be a Boolean. If a single type is not created, then the schema will become complex: Condition will become Condition OR ConditionReference, Apply will become Apply OR VariableReference, etc. Exact names to be used for new elements is not settled, however. Tim reported that EPAL distinguishes between Predicates and Conditions. If EPAL ever indicates interest in collaborating with XACML, then it might be useful to preserve some of their concepts and make use of some of their design decisions. Tim did not feel strongly about this, just raised it as a consideration. ACTION: Polar and Simon will produce a unified proposal and post it to the list. o 10. Parameters for Combining Algorithms The current proposal for WI#11. "XACML Extension Points" is actually a proposal limited to addressing what was WI#10. "Parameters for Combining Algorithms". WI#10 will be re-opened with the current proposal, while WI#11 will remain open for possible alternative or additional proposals. Simon clarified that, in his proposal, if a combining algorithm does not understand the CombiningParameters, then the policy is invalid. Polar wants to resolve whether ConditionParameters can include references to values, because then ConditionParameters would have to be included in the type system. Seth likes having them included in the type system because it makes it easier to implement and to extend the referencing mechanism into parameters. Can still define a DataType that is an XML structure. Polar would like to do administration policies as parameters to a combining algorithm. Simon is concerned about limiting what can be put into ConditionParameters. Doesn't want to limit them to AttributeValue. May or may not be a problem. Seth points out that an AttributeValue can be any type you want. Can define new types, use XML schema instances as types, etc. Big win to use one construct for all these. RESOLUTION: continue discussion on the list. o 11. XACML Extension Points Anne presented two possible use cases for Extension Points that are not satisfied by the proposal for WI#10: a place to put information about the Issuer of the policy (needed by Frank's administrative/delegation proposals); a place to put hints to the PDP about where to find Attributes used in the policy. Simon suggested that specific elements should be proposed for each such use case. Anne agreed that this would be a better approach, avoiding "kitchen sink" elements. RESOLUTION: keep open for now as place-holder for the two use cases, but will not necessarily do anything for 2.0. o 13. Optional Target Elements Current proposal: valid to leave out any Subjects, Resources, or Actions [or Environments] elements or entire Target, where omitted element means "no restriction", equivalent to existing "Any...". Polar now comfortable logically with optional target elements, with view that they represent pre-conditions. Bill feels optional elements are not as clear to human readers as explicit Any elements. Bill appears to be in the minority on this. Seth raised issue about semantics of omitted Target. Currently, omitted Target in a Rule means the Rule inherits the Target from its enclosing Policy. What is the meaning of "inheritance" when the enclosing Policy also has no Target. Tim expressed the view that the semantics of any omitted Target are "there are no further constraints" in addition to any inherited from enclosing policy/policyset. There was some discussion about whether this is just wording or whether it actually has a semantic effect. RESOLUTION: continue to discuss on list, bring to vote next time. 5. EPAL Tim has received no response from Fred Cohen regarding the Burton Group report that said incorrectly that XACML could not support EPAL's "purpose" attribute. It was suggested that the XACML TC see if the EPAL authors would be willing to work with the XACML TC to expand or modify XACML to meet their needs. A question was raised as to whether any TC members felt this might be an inappropriate increase in scope for the XACML TC, but no such concerns were expressed. RESOLUTION: the group voted unanimously to have the chairs approach the EPAL authors to see if they are interested in collaborating with the XACML TC to make XACML fit their requirements. 6. XACML 2.0 Draft 6 Tim will hold off on Draft 6 until the work items discussed today become more clear. 7. Adjourn Anne moved to adjourn. Maryann seconded. Meeting was adjourned at 11am EST -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]