Minutes of XACML Focus Group, 8 Apr 2004

[Anne Anderson <Anne.Anderson@Sun.COM>]

Attendees:
  Anne Anderson
  Tim Moses
  Simon Godik

1. XACML 2.0 Draft 8

   Tim says all the work items needed for XACML 2.0 have now been
   submitted, with the exception of "WI#9. Policy referring to
   hierarchical resources" and "WI#66. Add IP address match
   functions".  He will issue Draft 8 with all these work items
   incorporated.

2. WI#66. Add IP address match functions

   Anne will get IP address match functions out this week.  The
   plan is to reference the address match functions used in PKIX,
   but add support for port ranges (addresses match if their IP
   address portion matches by PKIX algorithm AND port or port
   range is a subset of the template value.

3. WI#71. Make ordered-* versions of combining algorithms
   mandatory

   The Focus Group recommends that the ordered-* versions of the
   combining algorithms be made normative and mandatory to
   implement.  This is required in order to support deterministic
   evaluation, especially with the acceptance of "WI#18.
   Obligations in Rules".

4. Hierarchical resources

   Anne's proposal for "WI#9.  policies referring to hierarchical
   resources" in
   http://lists.oasis-open.org/archives/xacml/200404/msg00049.html
   actually addresses WI#9, "WI#25.  Function for comparing file
   system pathnames", and "WI#58.  Standard hierarchy schemas."
   It is consistent with the solution to "WI#42.  Requests asking
   for access to multiple elements in a hierarchical resource" -
   the Request must contain a representation of the hierarchy in
   its "resource-content" Attribute.

   Simon thinks the "ancestor-attribute-match" function is too
   general, because it requires support for all kinds of
   Attributes on ancestor nodes, when the use case is just to
   support the UFS "must have execute privilege on all ancestors"
   semantic.  He would like to see this handled via a combining
   algorithm that understands the semantics of UFS file systems.

   Anne suggested defining a specific 'subject-can-execute'
   Attribute for use with 'ancestor-attribute-match',
   specifically to express notionally the UFS semantic.  Context
   Handler implementations of 'ancestor-attribute-match' can test
   for the XACML Subject having execute permission on all
   ancestor nodes via check with the actual file system.

5. XACML recommendations to SSTC regarding Attribute metadata

   We discussed the SSTC proposal to express the Attribute
   metadata in a separate message.  Since this would mean that
   each Attribute could have only one DataType, it means XACML
   Attributes could not always be translated into SAML
   Attributes, but we decided that was not a use case; the SSTC
   proposal does not affect translation of SAML Attributes to
   XACML Attributes.

   Hal suggested simplifying the recommendations so people don't
   think they have to read all of them.  Anne added short titles
   and [if not X] notes to convey the fact that the
   recommendations overlap, and we are not asking for all of them
   to be implemented.  Hal suggested getting the list out to the
   SSTC as soon as possible.  Anne has done so
   (http://lists.oasis-open.org/archives/xacml/200404/msg00053.html
   and
   http://lists.oasis-open.org/archives/security-services/200404/msg00019.html).

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