[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes of XACML Focus Group Meeting 8 May 2003
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]