[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Comments for discussion 21 November 2002
Attached is a text file containing a summary of all unresolved comments received on the xacml-comment mailing list. I have not included comments on the Conformance Tests, since they are not "official" yet (I have fixed each test comment submitted, however, and have responded to the commenter and to the xacml-comment list). We may want to start addressing Conformance Test comments formally after the final set of tests (final in terms of coverage, not in terms of correctness :-) is posted to the XACML TC web page. Anne -- 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
Title: Comments on XACML 1.0 Committee Specification
Maintainer: Anne Anderson
Version: 1.1, 02/11/20 (yy/mm/dd)
Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.Comments112002.txt
This file contains a link to every unresolved comment received on
the xacml-comment@lists.oasis-open.org mailing list reporting any
kind of problem with the specification since the public review
was announced on November 8, 2002. Each comment is broken down
into specific sub-comments, and the response to each is
described, along with any actions to be taken by the TC.
This version of the file contains e-mail up through
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00060.html
ACTION ITEM: [Anne Anderson, due 21 November 2002] Submit a
proposed re-wording of Section A.12 to make it more clear, but
without changing existing schema or semantics. [DONE:
http://lists.oasis-open.org/archives/xacml/200211/msg00146.html]
CATEGORIES
----------
Editorial: Formatting error or formatting inconsistency.
Inconsistent: Specification says one thing in one place and
another thing in another place.
Incomplete: Specification omits information required for full
specification of a feature.
Incorrect: Specification describes functionality that will not
work due to external or internal constraints.
Unclear: Description of feature is not clear or is ambiguous.
Undesirable: Feature is not desirable.
Alternative: Proposed alternative to a feature
======================================================================
COMMENTS
======================================================================
0012. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00015.htm
Subject: Section A12
From: John Merrells <merrells@jiffysoftware.com>
Date: Thu, 14 Nov 2002 01:03:04 -0800
I'm finding section A12 difficult to understand. I think the information
could
be more clearly presented.
1) It introduces the Target element and its immediate child elements, and
then the standard functions that can be used for a MatchID. But then a
couple of paragraphs later it says that the only functions that can appear
in a MatchID of a Target child are a different bunch of functions. This is
confusing.
2) <i>type</i>-match appears as a standard function. (And does not appear
in the conformance tables.) The subsequent paragraph starts "The evaluation
semantics for a match is as follows...' But is this referring to the
standard
match functions as a whole, or just the behaviour of the <i>type</i>-match
function itself. If not then where's the definition of <i>type</i>-match ?
3) The text and the examples refer to the special match functions before
they've actually been defined.
I think a reorg of section A12 would improve the legibility quite a bit.
And followup in
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00016.html:
> 2) <i>type</i>-match appears as a standard function. (And does not appear
> in the conformance tables.) The subsequent paragraph starts "The
> evaluation
> semantics for a match is as follows...' But is this referring to the
> standard
> match functions as a whole, or just the behaviour of the
> <i>type</i>-match
> function itself. If not then where's the definition of
> <i>type</i>-match ?
I think I've worked out that the <i>type</i> place holder in the list of the
standard match functions is not meant to stand in for all the types
recognized
by xacml, but is meant as a kind of wildcard to refer to the functions
actually
specified. So <i>type</i>-match doesn't mean integer-match, double-match,
etc, but actually just rfc822Name-match and x500Name-match.I think other
readers might be confused by this too.
CATEGORY: Unclear.
STATUS: Discussed 14 November 2002.
RESPONSE: Approved. We agreed that this section is unclear and
needs to be re-worded.
ACTION ITEM: [Anne Anderson, due 21 November 2002] Submit a
proposed re-wording of Section A.12 to make it more clear, but
without changing existing schema or semantics. [DONE: http://lists.oasis-open.org/archives/xacml/200211/msg00146.html]
ACTIONS:
=========================================================================
0013. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00032.html
Subject: The PolicySet Schema (Line 1759--1762)
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Mon, 18 Nov 2002 15:02:24 +0900
A minor comment on Line 1759--1762.
I found the type of two attributes (PolicySetId and
PolicyCombiningAlgId) specified by a long URI
http://www.w3.org/2001/XMLSchema#anyURI
I'm not sure this is wrong, but I can say it's strange in the
sense that the qname xs:anyURI is used in other schema
descriptions (e.g., Line 1819, 1889).
I think it's better to replace the long URI with the (short) qname.
CATEGORY: Inconsistent.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
0014. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00033.html
Subject: No description about the PolicyDefaults element
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Mon, 18 Nov 2002 15:48:16 +0900
The <PolicySetDefaults> element is described in Section 5.3, but
I could find no section describing the <PolicyDefaults> element.
As a result, no syntax is defined for it in the specification
document. Is this okay?
CATEGORY: Incomplete.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
0015. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00034.html
Subject: conformance tests (NotApplicatble or Not-Applicabale)
From: John Merrells <merrells@jiffysoftware.com>
Date: Sun, 17 Nov 2002 23:32:46 -0800
The spec says 'Not-Applicable', but the tests
(eg. IIB003Response.xml) say 'NotApplicable'.
CATEGORY: Inconsistent.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
DISCUSSION:
[Anne Anderson] I believe the specification is incorrect here.
The schema uses "NotApplicable". Recommend changing all
instances of "Not-Applicable" in the specification to
"NotApplicable".
=========================================================================
0016. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00035.html
Subject: NotApplicable From: Seth Proctor <seth.proctor@sun.com>
Date: Mon, 18 Nov 2002 10:07:50 -0500
The schema uses "NotApplicable" in a Decision, but the spec says
that it's "Not-applicable" ... I'm pretty sure the schema is
correct here, right?
CATEGORY: Inconsistent.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
DISCUSSION:
[Anne Anderson] This is really the same issue as in 0015.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00034.html
=========================================================================
0017. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00036.html
Subject: Another A.12 comment
From: Seth Proctor <seth.proctor@sun.com>
Date: Mon, 18 Nov 2002 10:09:47 -0500
Section A.12 (which I know Anne is re-working) makes several
mentions of the EnvironmentMatch type ... there is no such type,
so this should probably be removed from A.12
CATEGORY: Inconsistent.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
DISCUSSION:
[Anne Anderson] The new draft of A.12 that I submitted in
http://lists.oasis-open.org/archives/xacml/200211/msg00146.html
omits mention of EnvironmentMatch elements.
=========================================================================
0018. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00039.html
Subject: xacml:Policy:XpathVersion mandatory-to-implement?
From: Anne Anderson <Anne.Anderson@Sun.com>
Date: Mon, 18 Nov 2002 11:45:24 -0500 (EST)
In Section 10.3.1, "xacml:Policy:XpathVersion" is listed as
mandatory-to-implement.
------------------------------------------------------------------------
0018a. This should be spelled "XPathVersion"
CATEGORY: Inconsistent.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
------------------------------------------------------------------------
0018b. This should not be mandatory-to-implement, since support for
XPath functionality and the containing PolicyDefaults are not
mandatory-to-implement.
CATEGORY: Inconsistent.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
------------------------------------------------------------------------
0018c. 10.3.1 should contain "xacml:Policy:PolicyDefaults", and it
should be marked not mandatory-to-implement
CATEGORY: Inconsistent.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
0019. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00040.html
Subject: Incomplete: behavior if <Obligations> present but notsupported
From: Anne Anderson <Anne.Anderson@Sun.com>
Date: Mon, 18 Nov 2002 13:25:13 -0500 (EST)
The behavior of a PDP that does not support the optional
<Obligations> element when presented with a Policy containing
<Obligations> is not specified.
Possible behavior: if a Policy or PolicySet is Applicable to a
Request and the Policy or PolicySet contains <Obligations>, but
the PDP does not support <Obligations>, that the PDP MUST return
"Deny".
CATEGORY: Incomplete.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
0020. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00041.html
Subject: INCOMPLETE: behavior when XPath encountered,but not supported
From: Anne Anderson <Anne.Anderson@Sun.com>
Date: Mon, 18 Nov 2002 13:37:35 -0500 (EST)
The behavior of a PDP that does not support the optional XPath
*Defaults, selectors, functions, etc. when presented with a
policy containing such elements is not specified.
In some cases, the XPath elements may appear in a <Target>
element, making it impossible to determine whether or not a
PolicySet, Policy, or Rule is applicable.
In other cases, the <Target> element may not require any XPath
functionality, and a PolicySet, Policy, or Rule may be
applicable, but evaluating the <Condition> in the Rule may
require XPath functionality.
Possible behavior: If, during evaluation of a Request, any
unsupported element is encountered, then the PDP MUST return a
result of Indeterminate.
CATEGORY: Incomplete.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
0021. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00042.html
Subject: C.3 First-Applicable policy-combining alg inconsistent
From: Anne Anderson <Anne.Anderson@Sun.com>
Date: Mon, 18 Nov 2002 16:29:27 -0500 (EST)
In the description of the policy-combining algorithm for
FirstApplicable, lines 4752-4754 say: if error occurs while
evaluating a policy, then evaluation shall continue looking for
an applicable policy, returning Indeterminate only if no
applicable policy found.
But lines 4755-4758 say: if error occurs while evaluation a
policy, then evaluation shall halt and policy set shall evaluate
to "Indeterminate".
Lines 4752-4754 should be deleted. That would be consistent with
the pseudo-code and with the "safety" of not allowing any
"Permit" if there is an Indeterminate that should have returned a
Deny.
CATEGORY: Inconsistent.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
DISCUSSION:
[bill parducci] do you mean the pEp? the pDp need not understand
an Obligation since it is imposed upon the pEp as part of
enforcement of the decision, not on the pDp as a consequence of
making the decision.
e.g.
decision: PERMIT
obligation: STRONGENCRYPT
=========================================================================
0022. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00044.html
Subject: Section 5.24
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Tue, 19 Nov 2002 14:31:14 +0900
There is no description about the child element
<xacml:SubjectAttributeDesignator> in Section 5.24.
Some description should be added between Lines 2162 and 2163.
CATEGORY: Incomplete.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
0023. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00045.html
Subject: Line 308: The SAML prefix
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Tue, 19 Nov 2002 14:41:02 +0900
In Line 308, the SAML prefix (saml:) is mentioned, but it never
appears anywhere in the document. The line should be removed.
CATEGORY: Inconsistent.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
0024. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00046.html
Subject: Comments on the prefix xf
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Tue, 19 Nov 2002 14:56:39 +0900
In Line 1295, the QName xf:yearMonthDuration should be replaced by the
correct URI.
In Line 1345, the QName xf:yearMonthDuration should be replaced by the
correct URI.
Appendix A14.7:
In Lines 3759, 3766, 3773, 3782, 3790, 3796,
the QName xf:yearMonthDuration should be replaced by the correct URI.
CATEGORY: Inconsistent.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
0025. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00047.html
Subject: Line numbering is inconsistent
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Tue, 19 Nov 2002 15:08:56 +0900
Line numbering is inconsistent between the PDF file and the Word
file.
I have downloaded them from:
http://www.oasis-open.org/committees/xacml/repository/cs-xacml-core-01.doc
http://www.oasis-open.org/committees/xacml/repository/cs-xacml-core-01.pdf
An example:
In the PDF file Line 43 is a blank line.
In the Word file Line 43 is about the copyright.
CATEGORY: Inconsistent.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
0026. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00048.html
Subject:The type of the RequestContextPath attribute
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Tue, 19 Nov 2002 15:34:25 +0900
The current type of the RequestContextPath attribute is
xs:anyURI. (Section 5.31) I don't think that a valid XPath
expression is always a valid URI (according to RFC2396). So I
think the type should be xs:string rather than xs:anyURI. Please
correct me if I'm wrong.
In the XML-Signature specification, the type of XPath expressions
is xs:string.
CATEGORY: Incorrect.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
0027. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00049.html
Subject: Function Identifiers in Section 10.3.8
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Tue, 19 Nov 2002 21:11:44 +0900
Section 10.3.8 uses QName as function identifiers.
Don't use the namespace prefix "function" and replace all the qnames with
the corresponding URIs.
Remove line 3302 (xmlns:function="urn:oasis:names:tc:xacml:1.0:function").
CATEGORY: Inconsistent.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
0028. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00050.html
Subject: equality & set/bag functions
From: Seth Proctor <seth.proctor@sun.com>
Date: Tue, 19 Nov 2002 17:34:32 -0500
The set and bag functions (along with others), are defined as
type-[name] where this is expanded to include one function for
each standard type. Presumably this includes the two duration
attribute types. One of the bag functions and several of the set
functions also specify that their definitions are based on using
the type-equal function for the coresponding type. The equality
functions, however, are defined individually for each type, and
no equal functions are defined for the two duration types.
So, the question: should there be equality functions defined for
the two duration types, or should certain type-[name] functions
not be able to handle the two duration types? It seems like one
of those two must change to make this work.
CATEGORY: Incomplete.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
DISCUSSION:
[Polar Humenn] I don't see why not. But it will have to be
specified, such as whether 360 seconds is really equal to 6
minutes, etc.
=========================================================================
0029. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00053.html
Subject: The prefix "function:" is used in Section 4 Examples
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Wed, 20 Nov 2002 12:34:21 +0900
The namespace prefix "function:" is used in the explanation for
the examples in Section 4. There are too many places where it is
used and so I cannot list all here. All should be replaced with
the correct URIs.
E.g.,
function:string-equal
Function:string-equal (Capital F is used)
function:and
function:string-one-and-only
function:date-less-or-equal
function:date-one-and-only
CATEGORY: Inconsistent.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
0030. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00054.html
Subject: The prefix "function:" is used in Appendix A
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Wed, 20 Nov 2002 12:39:38 +0900
The namespace prefix "function:" is used in Appendix A.
There are too many places where it is used and so I cannot list all here.
All should be replaced with the correct URIs.
CATEGORY: Inconsistent.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
0031. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00055.html
Subject: The default value of the MustBePresent attribute(Section 5.26)
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Wed, 20 Nov 2002 16:08:50 +0900
The defaut value "false" of the MustBePresent attribute is NOT specified in
the schema in Section 5.26.
It should be added.
CATEGORY: Inconsistent.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
0032. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00058.html
Subject: Problems understanding XACML spec
From: Graham Klyne <GK@NineByNine.org>
Date: Wed, 20 Nov 2002 13:40:25 +0000
I'm having a really hard time understanding what you're trying to
say in the XACML spec:
http://www.oasis-open.org/committees/xacml/repository/draft-xacml-schema-policy-18d.doc
ACTIONS: Anne Anderson sent Graham Klyne a message explaining
that the public review is being held with respect to XACML 1.0,
and not draft 18d.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00060.html
Comments may still apply, since they are fairly general, so I
have listed them below.
------------------------------------------------------------------------
0032a. The description of a rule seems to be inadequately motivated.
CATEGORY: Unclear.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
------------------------------------------------------------------------
0032b. The description in section 2 (background) says "The <Rule>
element contains a boolean expression that can be evaluated in
isolation..." which doesn't do anything to prepare me for the
description I find in section 3.3.1. I'm finding it particularly
hard to see
(a) what this Boolean expression is evaluated over (it seems to
have something to do with the rule target), and
(b) how the Boolean result relates to the evaluation of the rule.
I can see that a Boolean true results in Permit or Deny
depending on the value of the rule's effect field, but what
happens if the Boolean value is false?
As far as I can tell, understanding this is crucial to
understanding all the other stuiff about combining rules and
policies.
CATEGORY: Unclear.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
------------------------------------------------------------------------
0032c. Under what circumstances is a rule found to be
"NotApplicable"?
CATEGORY: Unclear.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
------------------------------------------------------------------------
0032d. I also find the reference to the fact that a rule may
"inherit" target information from a policy is particularly
obscure.
It seems to me that the idea of a rule is fundamental to
understanding this specification, but that vital idea is not
adequately explained.
It may be that the information is present somewhere in this document, but
it is a big and complicated document and I can't tell what's
important.
CATEGORY: Unclear.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
------------------------------------------------------------------------
0032e. I think more attention needs to be paid to the order in
which concepts are introduced. I would expect section 2 to deal
with this, but it seems some important ideas are not being
adequately explained.
CATEGORY: Unclear.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
------------------------------------------------------------------------
0032f. I also think there's an over-dependence in the text on
abbreviations that are introduced in the glossary. There are
many special terms, and ordinary words used with special
meaning, and it's not reasonable to assume that someone not
familiar with them to absorb them on one pass through the
glossary.
CATEGORY: Unclear.
STATUS: Not yet discussed.
RESPONSE:
ACTIONS:
=========================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC