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: Minutes of Focus Group 29 July 2004

Minutes of the XACML TC Focus Group
29 July 2004

  Anne Anderson
  Tim Moses
  Ed Coyne
  Polar Humenn
  Michiharu Kudo

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


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
   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
   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"
   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

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