[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for XACML TC meeting 22 July 2004
Minutes for XACML TC 22 July 2004 Attendees: Anne Anderson (scribe) Bill Parducci Seth Proctor Frank Siebenlist Michiharu Kudo Simon Godik Tim Moses Daniel Engovatov Ron Jacobson Quorum was not achieved. Agenda: http://lists.oasis-open.org/archives/xacml/200407/msg00080.html 0. Happy Birthday to Frank's daughter! 1. Minutes of 8 July 2004 No comments, but no quorum to approve. 2. <Issuer> child element or CombiningAlg Parameter Bill: Problem with PolicySet that includes a Policy issued by someone else. But hard to create policies without having actual instances if in CombiningAlg. Uncomfortable with hasty inclusion of <Issuer>. Proposes allowing <Policy> to contain <Issuer>, but not <PolicySet>. Neither Polar nor Frank really happy with this. Anne: in favor of not making changes now. Go ahead with XACML 2.0, and let discussion on delegation continue and go into a proposed Profile. Maybe Profile will require an XACML 2.1 schema for changes, or maybe not. Daniel: in favor of not including Issuer information explicitly in policies; it is meta-data, and the processing procedure should just look it up. Having an implementation would really help in evaluating how and how well the process works. Anne: what would we lose if we describe a normative the processing procedure, but do not spell out where the issuer information comes from? Frank: the algorithm is in his Haskell document, posted on 17 November 2003 with "Subject: [xacml] Modeling Delegation of Rights in a simplified XACML with Haskell" (http://lists.oasis-open.org/archives/xacml/200311/msg00022.html) Anne posted a very simple summary of the process on 18 May 2004 with "Subject: summary of Frank's delegation proposal" (http://www.oasis-open.org/archives/xacml/200405/msg00081.html), and Frank elaborated on that in subsequent messages. [Simon] will write up a description of how delegation might work based on the proposals so far. Something will probably have to be on the list for the next meeting if it is to be considered for XACML 2.0. 3. SAML Profile for XACML Please review 4. Hierarchical resource treatment of XML documents Anne summarized. Bill: treat document one way or the other. Tim: But what if document treated one way in policy, but request submitted other way. resource identifier would identify as a single resource or as a structured document. Michiharu: There will be an agreement between PEP and PAP: a) document level access control (URIs) b) element level access control (XPath) PEP should ask PDP if target document is accessible via a given mechanism. XACML is access control policy specification language. It should not define the semantics of each application. XACML should provide a very primitive way for the implementor. One way is Request/Decision pairs that does not use any ResourceContent. Second way contains XML data in ResourceContent, with way to ask element level or fine-grained access control. Each vendor can select how to combine. One use case is first ask about document accessibility, then make element level access request. Anne: Profile does not limit, just makes default. Bill: Michiharu is proposing possible mechanism for negotiating how a document is to be accessed. Simon: Need to say in Request whether asking for entire document or for individual nodes. Use [scope] attribute: "Descendants" means entire document. Or add [scope] = entire resource. Bill: then combiner alg should say deny-override: if any node denied, then result is deny. 5. URI matching [Tim] will post the 7 issues here for discussion. Bill: try to resolve these on the list. 6. Next focus group URI match, IP address matching Hierarchical resources Delegation Actual topic(s) will be decided based on list discussions, where it seems productive to hold a discussion on a call. 7. Next F2F: with OASIS meeting in Brussels? we will tell OASIS we will NOT be having a meeting in Brussels in conjunction with the OASIS meeting there. 8. OASIS has new IPR policy We will need to discuss this at some point prior to XACML 2.0 vote. 9. New TC mailing list: xacml-dev@lists.oasis-open.org For implementors who have questions about use and implementation of a TC's specifications. OASIS has set up such a mailing list for every TC. [Anne] raised warning/issue about ideas coming from non-OASIS members: if we use them in our specifications, we have an undefined and possibly dangerous IPR situation. This came up with the RBAC Profile: once it was clear that a non-OASIS member was proposing actual ideas for inclusion in the Profile (not just asking for clarification or commenting on existing idea), Anne had to stop the discussion to avoid tainting. -- 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]