OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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]