[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes of Focus Group 29 July 2004
Minutes of the XACML TC Focus Group 29 July 2004 Present: Anne Anderson Tim Moses Ed Coyne Polar Humenn Michiharu Kudo Agenda: 1. URI match, IP address matching 2. Hierarchical resources 3. Profiles to move to CD status along with core 4. RBAC - snag 5. Delegation 6. Date on closure for core and profiles 7. Anne on vacation Minutes 1. URI match, IP address matching [Tim] these were resolved on the list. We will use regexp for everything. Bill can't say "I told you so" :-) 2. Hierarchical resources [Anne] Plan to add new "scope" value for case where an entire XML document or an entire sub-tree of it is to be accessed, with one result returned. If combining algorithm is "deny-overrides", then if any node in the requested document is "deny" then the one result will be Deny. If ALL nodes are "permit" then the one result will be Permit. All applicable policies will be applied to all nodes. [Michiharu] Semantics of the scope must be clearly defined. Orthogonal to the combining algorithm. [Anne] May need to specify a "super-combining-algorithm" such as "deny-overrides". [Michiharu] could avoid complexity of "super-combining-alg" by saying XACML policy does not deal with that level of complexity. So don't introduce new level, but have the Context Handler deal with the new "scope" value. [Tim and Anne] agree this is a good approach. [Tim] The Hierarchical Resources Profile will overlay the core XACML functionality. The Multiple Resources Profile will overlay the Hierarchical Resources Profile to specify how "scope" is dealt with. [Anne] issue of optimization: PDP may need to know the scope in order to deal with entire set of nodes at once. [Michiharu] they could use custom combining algorithm in this case. Optimization could depend on each application's semantics. XACML should just specify sufficient way to specify policy that fits most use cases. [Anne] will continue to state semantics of scope such that requirement is for result being same "as if" given steps are performed, but no requirement for actually performing steps one by one. ACTION [Anne] will produce new draft of the profile. [Michiharu] question about examples using resource-ancestors. Wanted to be sure Daniel was happy with the fact that it is impossible to tell the sequence of ancestors, so can't write policy that depends on path to the node. [Anne] Daniel is aware of this, and seems satisfied. [Anne] is "document-id" Attribute OK? [Michiharu] hasn't yet done actual use case. "document-id" might be used in the specified way (entire resource of which "resource-id" may be a part). If target document is XML document, then it may have "document-id", so then document-id makes sense. But if use hierarchical resource spec with <ResourceContent> that represents policy for file system - there "document-id" means nothing. Fine so long as inclusion of "document-id" whenever <ResourceContent> is optional, and not required. [Anne] Fine. 3. Profiles to move to CD status along with core Hierarchical Resources Multiple Resources SAML DSig Profile? - next revision will simply point to SAML Profile as recommended way to encapsulate and sign XACML artifacts, and will mention some of the canonicalization issues that artifact generators will need to deal with (since SAML punts on this). Everything just guidelines, not normative. Privacy Profile? - not much discussion on the list, but the profile is very simple and short. Tim will test the waters for the TC is interesting in progressing this. LDAP Profile - NO: Tim has been focusing on a SQL approach rather than LDAP, so no longer interested in progressing the LDAP Profile. Tim's basic idea is PDPs have a "topic" that is syntactically identical to a <Target>, but semantically says "this is the set of queries I will answer". He has a data model and algorithm for generating SQL queries from the <Target>. Will not finish this in time for the Core CD vote and standardization process. 4. RBAC - snag [Anne] Is now convinced that the current Profile, while OK for basic and hierarchical RBAC, does not deal adequately with Separation of Duty. Problem is that, until policy is executed, it is not necessarily known (and should not be necessary to know) which role is needed for the access being requested. Yet can't request all role Attributes, since various roles are not allowed to be held at the same time in Separation of Duty. A new function can be created to request the specific role Attribute needed, but such a function does not fit into the model used by the current Profile (the function is described in the current Profile). This problem was brought to Anne's attention by Aleksey Studnev (Exigen Group) and by Stefan Berthold, (Technische Universitaet Dresden, Fakultaet Informatik) "eXtensible Access Control Markup Language: XACML im Vergleich mit P3P und EPAL" (http://dud.inf.tu-dresden.de/~kriegel/ss04/hauptseminar/Berthold2004_HS_XACML.pdf). Aleksey proposed a solution, but Exigen Group is not a member of OASIS and appears to be uninterested in clarifying the status any IPR it might hold in Aleksey's solution. Anne is doing a literature search for a free-and-clear solution. Until and unless such a solution is found, Anne is unwilling to progress the current Profile. 5. Delegation [Tim] Simon has volunteered to write up a specific profile draft. [Polar] Fine. No time to work out the algorithm, etc. Still thinks adding <Issuer> element is a mistake. [Anne] Can still object to anything in the draft, as anyone else can! 6. Date on closure for core and profiles [Tim] Will propose at next meeting that we pick a date for final comments on the core and any profiles that will be progressed to Committee Draft stage with the core. There are no outstanding specific issues, so only remaining issue is giving people any necessary time to review and comment. 7. Anne on vacation Anne WILL be on the call next week (5 August), but will be on vacation the following week (12 August) and will have to miss that call. -- 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]