Minutes of XACML Focus Group Meeting 8 May 2003

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

Minutes of XACML Focus Group Meeting on 8 May 2003

Present:
 Anne Anderson (minutes)
 Simon Godik
 Steve Crocker

Agenda:
A) Hierarchical resources proposal
B) attribute ID's
C) other items.

ACTION ITEM: Anne to write up match functions for UFS resource
model as an example.

Discussion:

A. Hierarchical resources

   Simon likes Anne's proposal to define new functions for
   handling each hierarchical resource model.

   Simon suggests using DataType="string" rather than new
   DataType for resource models.  In "<type>-match", <type> can
   now be a resource model or a datatype.

   Simon would still like to specify that one action implies
   another action.  Anne suggests specifying it in the
   description of a "<model>-action-match" function associated
   with the resource model.  The specific implication rules would
   be spelled out in the text that describes this function as
   part of the resource model description.  One resource model
   could reference the action-match function of another resource
   model.

   TENTATIVE RECOMMENDATION: Each resource model description
   should include a <model>-resource-match function and an
   optional <model>-action-match function, where the action-match
   function may reference the action-match function of a
   previously defined resource model.

   ACTION ITEM: Anne will write up proposed functions for UFS
   resource model as an example.

B. attribute ID's

   Simon proposes we drop it.  It was just for digital
   signatures, but we are not now proposing to sign portions of a
   policy, so Attribute Ids are not required.

   If want to reference one <xacml:Policy> element in an XML
   document that contains many <xacml:Policy> elements, would
   attribute ID make references easier?  Simon says yes, since
   you would not need XPath to form a URI that leads to the
   element.  AttributeId should be optional and applied only to
   <PolicySet> and <Policy> (and to <Rule> if <Rule> becomes
   separately referenceable).

   Alternative is to use an XPath expression, but that requires
   XPath support and is a little complicated.  SAML decided
   AttributeId was better since not everyone wants to support
   XPath.

   Focus Group recommends either of following options:

   1) optional (for backwards compatibility) Id attribute on
      <PolicySet>, <Policy>, and possibly <Rule>
   2) do nothing (if you really want to reference something, must
      use XPath (or maybe XPointer?))

C. Should <RuleIdReference> be supported?

   Steve slightly yes.  Anne fairly strongly yes, but not "to die
   for": <Rule> can be embedded inside a <Policy> that is then
   referenced.  Simon doesn't care: some value in it, but mostly
   syntactic sugar; XACML syntax is already big; won't vote
   against <syntactic-constructReference> if people really want
   it.

   Note that a real product-driven use case motivated the request
   for <RuleIdReference>: ebXML policies were constantly having
   to restate the same small set of <Rule>s.  Could put each
   <Rule> into a <Policy> and refer to it that way, but that
   seems like unnecessary overhead for lots of small <Rule>s.

D. Condition references

   Need Michiharu for this discussion.  Anne thinks
   RuleIdReference is enough for now.  Simon doesn't care: it's
   all sugar.  Steve: no opinion yet.

E. Properties (parameters) for combining algorithms

   Need Michiharu for this discussion.  In general Simon thinks a
   placeholder for something like a list of Attributes is needed:
   extensibility point reserved for purpose X.  Anne thinks we
   should be discussing standardization of a particular combining
   algorithm that requires such parameters, rather than starting
   with parameters.

Meeting adjourned at 10:49 EDT.

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