[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
Attendees:
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
works.
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"
(http://lists.oasis-open.org/archives/xacml/200311/msg00022.html)
Anne posted a very simple summary of the process on 18 May
2004 with "Subject: summary of Frank's delegation proposal"
(http://www.oasis-open.org/archives/xacml/200405/msg00081.html),
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
Delegation
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
vote.
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]