[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