[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Notes from Focus Group 30 June 2005: Discussion of admin policy draft 6
Notes from XACML TC Focus Group 30 June 2005 Attendees: Erik Rissanen, Hal Lockhart, Anne Anderson Agenda: Discuss "XACML v3.0 administration policy", Working draft 06, 10 June 2005 http://www.oasis-open.org/committees/download.php/13027/access_control-xacml-3.0-administration-wd-06.zip 1. Types of policies Currently spec distinguishes between o Access Policy: does not contain a <PolicyIssuerMatch> element. Grants or denies access. Same as XACML 2.0 policies. May or may not have a <PolicyIssuer> element. o Administration Policy: contains a <PolicyIssuerMatch> element. Grants permission to issue new Access Policies or Administration Policies. ISSUE: Should Administration Policies that grant permission to issue new Access Policies be distinguished from those that grant permission to issue new Administration Policies? If same policy would never be used for both cases, it might make policies more understandable if they were given different names. Use case for doing both in one policy: Erik may delegate permission to Hal to make updates to the spec during Erik's vacation, but Erik may also be happy if Hal further delegates this permission in case Hal is busy or traveling. One could duplicate the policy, one for the direct access case and another for the delegation case, but we try to minimize need for such duplications. RECOMMENDATION: continue to use just two types of policies. 2. Specificity of delegation controls ISSUE: We agreed that we want to allow controls over later delegation in a chain, but Hal has concerns about allowing too much specificity here: if a policy says the delegation chain must be Hal->Erik->Anne, then if responsibilities change, this policy will easily become invalid. RECOMMENDATION: leave this as open issue until spec has a way for a <Policy> to control the <LaterDelegation> element now in the <Context>. Erik simply has not gotten to that yet, but will on the next draft. Once the control mechanism is spelled out, then group can decide on whether it is overly general or not. 3. Extensible target categories ISSUE: exactly what was the recommendation about "free targets" from the Face-to-Face in April? CLARIFICATION: Rather than <Subject>, <Resource>, ... have <Category CatId="...:subject">, <Category CatId="...:resource">, etc. That is, make the Target categories extensible. For backwards compatibility, define equivalence between current <Subject> and <Category CatId="...:subject">, etc. RECOMMENDATION: seems fine. 4. Inconsistencies and missing pieces in schema ISSUE: Currently, a <LaterDelegate> element is in the Context for specifying delegates further down the delegation chain, but there is nothing that corresponds to this in the Policy schma. ACTION: Erik will complete this part of the spec for the next draft. ISSUE: In the policy Target, <IssuerMatch> and <Delegate> are currently used interchangeably to mean the same thing. XACML 2.0 always matches a name in a policy against a name in a context, but in this case we need to match what is a "Delegate" condition in a policy against what is called an "Issuer" in a context. RECOMMENDATION: next draft will use <IssuerMatch> consistently. Then group can decide whether <Delegate> would be more clear. -- 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]