[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for XACML TC Focus Group 19 June 2003
XACML TC Focus Group 19 June 2003 10am EDT Topic: Errata against XACML 1.0 Present: Anne Anderson (scribe), Michiharu Kudo, Simon Godik, Hal Lockhart, Polar Humenn, Tim Moses Agenda: http://lists.oasis-open.org/archives/xacml/200306/msg00058.html - KAVI e-mail search engine errors Simon is getting errors when he tries to use the "search" box to find e-mails related to a particular topic. Anne has had the same problem. Anne just submitted an error report (since she can find no record of having submitted this previously; maybe that is why she had not heard back from the OASIS webmaster :-). - errata 3.6: string-equality or uri equality for the subject category Proposal: not an errata, leave as is: string-equality. URI-equality implies URL-equality and this could get very complicated because URL can be url-encoded. Besides, this does not cover URN what subject attribute really is. RECOMMENDATION: accept proposal; continue to use string-equality. The type of the XML SubjectCategory attribute is "xs:string". - errata 3.9: <XPathVersion> element and XPath-based functions proposal: <XPathVersion> element is REQUIRED if the XACML enclosing policy set or policy contains <AttributeSelector> elements or XPath-based functions. RECOMMENDATION: accept proposal. - errata 3.10: context node for xpath expressions proposal: <xacml-context:Request> element is a context node for every xpath expression. RECOMMENDATION: doesn't matter except when using relative XPath expression. <xacml-context:Request> element is a context node for every xpath expression, under our assumption that this is what people have already implemented and as used in conformance tests, so we recommend this. - errata 3.11 semantics of the <attribute-assignment> children elements proposal: needs text. RECOMMENDATION: The <AttributeAssignment> element may be used in any way consistent with the schema syntax, which is sequence of "any". The value specified SHALL be understood by the PEP, but is not further specified by XACML. See Section 7.11 Obligations in the XACML 1.0 Specification. - errata 3.2 Need definition of type unification. ACTION ITEM: Polar will draft text and send to the list. - http://lists.oasis-open.org/archives/xacml-comment/200304/msg00007.html how to combine multiple policy sets? > How does each policy combining algorithm defined in Appendix C > combine multiple policy sets > (and a mixed sequence of policies and policy sets)? > > Here are the links to the related discussion. > In my understanding, the answer is that a <PolicySet> is > treated exactly like a <Policy> in all the policy combining algorithms. RECOMMENDATION: a <PolicySet> is treated exactly like a <Policy> in all the policy combining algorithms. This text should be added to XACML 1.1 in some appropriate place associated with the combining algorithms. - http://lists.oasis-open.org/archives/xacml-comment/200305/msg00001.html xpath-node-match and IIIG004Policy.xml I propose the following changes: Basically, I'd like to remove the insufficient definition of "the enhanced XPath expression" at all. >>This function SHALL take two "http://www.w3.org/2001/XMLSchema#string" >>arguments, which SHALL be interpreted as XPath expressions and SHALL >>return an "http://www.w3.org/2001/XMLSchema#boolean". No change. RECOMMENDATION: agree. No change. >>This function SHALL first extend the first argument to match >>an XML document in a hierarchical fashion. >>If a is an XPath expression and it is specified as the first argument, >>it SHALL be interpreted to mean match the set of nodes specified >>by the enhanced XPath expression "a | a//* | a//@*". >>In other words, the expression a SHALL match all elements and attributes >>below the element specified by a. >>This function SHALL evaluate to "True" if any XML node that matches >>the enhanced XPath expression is equal according to "op:node-equal" >>[XF Section 13.1.6] to any XML node from the node-set matched by >>the second argument. Replace this by the following: This function SHALL evaluate to "True" if either of the following two conditions is satisfied: (1) Any XML node from the node-set matched by the first argument is equal according to "op:node-equal" [XF Section 13.1.6] to any XML node from the node-set matched by the second argument. (2) Any attribute and element node below any XML node from the node-set matched by the first argument is equal according to "op:node-equal" [XF Section 13.1.6] to any XML node from the node-set matched by the second argument. NOTE1: The first condition is equivalent to "xpath-node-equal", and guarantees that "xpath-node-equal" is a special case of "xpath-node-match". RECOMMENDATION: accept replacement. (editor: make sure the [XF] references are to the same dated version that XACML 1.0 uses as its standard reference. The meeting was adjourned at 10:52am 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]