Questions:
>> - 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.
It seems to me that
SUN's implementation uses URI-equality
rather than string-equality for subject-category comparison:
http://sunxacml.sourceforge.net/javadoc/com/sun/xacml/EvaluationCtx.html
http://sunxacml.sourceforge.net/javadoc/com/sun/xacml/EvaluationCtx.html#getSubjectAttribute(java.net.URI,%20java.net.URI,%20java.net.URI,%20java.net.URI)
Does this comform to the specification?
Maybe, the specification document should define the precise meaning of
"string-equality".
>> RECOMMENDATION: accept proposal; continue to use string-equality.
>> The type of the XML SubjectCategory attribute is "xs:string".
Does this mean the XACML schema will be changed so that
the type of the "SubjectCategory" attribute is xs:string (not xs:anyURI) ?
Satoshi Hada
IBM Tokyo Research Laboratory
mailto:satoshih@jp.ibm.com
|---------+---------------------------->
| | Anne Anderson |
| | <Anne.Anderson@Su|
| | n.com> |
| | |
| | 2003/06/20 00:09 |
| | Please respond to|
| | Anne.Anderson |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------|
| |
| To: XACML TC <xacml@lists.oasis-open.org> |
| cc: |
| Subject: [xacml] 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
You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php