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 for XACML TC meeting 22 July 2004

Minutes for XACML TC 22 July 2004

   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

   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"
   Anne posted a very simple summary of the process on 18 May
   2004 with "Subject: summary of Frank's delegation proposal"
   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

   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

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]