[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Minutes for XACML TC Focus Group 19 June 2003
Satoshi,
On 23 June, Satoshi Hada writes: Re: [xacml] Minutes for XACML TC Focus Group 19 June 2003
> >> - 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.
>
For some reason, my copy of the XACML schema is not the same as
the one on the web site, and I apologize for any confusion this
has caused in my answers to questions. My copy says
<xs:attribute name="SubjectCategory" type="xs:string"
use="optional" .../>
But the one on the web site says "type="xs:anyURI". I don't
remember this change being made.
Since the schema says anyURI, your question is more of any issue
than I had been thinking.
> 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?
I'll check with Seth. Our implementation should conform to the
specification, and should change if it does not.
> Maybe, the specification document should define the precise meaning of
> "string-equality".
Our definition of string-equality is 'The function SHALL return
"True" if and only if the value of both of its arguments are of
equal length and each string is determined to be equal
byte-by-byte according to the function "integer-equal"'.
> >> 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) ?
No. When the XACML TC discussed this, we agreed that comparisons
would be done using "string-equal". Now that I realize the
schema was changed so the SubjectCategory type is "anyURI", I am
more willing to revisit this.
What are current implementations (besides Sun's XACML
Implementation) doing?
-Anne
> 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
>
>
>
>
--
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]