The attached file contains only those comments that have not yet been resolved. It includes e-mail up through
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00153.html and
http://lists.oasis-open.org/archives/xacml/200212/msg00043.html -- 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.22, 02/12/04 (yy/mm/dd) Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.Comments.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 or schemas 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/msg00153.html and
http://lists.oasis-open.org/archives/xacml/200212/msg00043.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 ====================================================================== 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 ------------------------------------------------------------------------ 0032a. The description of a rule seems to be inadequately motivated. 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 stuff about combining rules and policies. CATEGORY: Unclear. STATUS: Discussed 11/21/02. RESPONSE: Needs to be clarified. Proposed text attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html , Subject: FW:Draft OS v1.0 Dated 29th Nov 2002, From: Carlisle Adams, Date: Fri, 29 Nov 2002 TC members should read this. Unless there are objections, this will be used as the resolution to Comment 32a. ACTIONS: ========================================================================= 0044.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00081.html Subject: There is no Section describing<SubjectAttributeDesignator> From: Satoshi Hada <
SATOSHIH@jp.ibm.com> Date: Fri, 22 Nov 2002 15:48:16 +0900 There is no section describing <SubjectAttributeDesignator>. As a result, although the term "present" is defined for other attribute designators (action, resource, environment), there is no definition of "present" for subject attribute designator. Is this okay? CATEGORY: Incomplete. SEE ALSO: #22 STATUS: Discussed 11/25/02. RESPONSE: Rename 5.30 "Complex type SubjectAttributeDesignatorType" to "Element <SubjectAttributeDesignator>". Re-word this section so that it provides information in a format consistent with the descriptions of ResourceAttributeDesignator, ActionAttributeDesignator, and EnvironmentAttributeDesignator. ACTION ITEM: #44. [Simon Godik] compare 5.30 with 5.27-29 and propose consistent wording. 12/02/02 no progress, but will be done shortly ACTIONS: ========================================================================= 0052.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00097.html Subject: 5.31 Element <AttributeSelector> From: John Merrells <
merrells@jiffysoftware.com> Date: Sun, 24 Nov 2002 17:54:08 -0800 ------------------------------------------------------------------------ 0052a. "The AttributeSelector element's RequestContextPath XML attribute SHALL contain a legal XPath expression over the <xacml-context:Request> element." The phrase 'over the' made me think for a while. This could be made clearer by using the 'context node' term from the XPath specification. XPath evaluation occurs with respect to a context node, the context node for this XPath expression is the <xacml-context:Request> element. CATEGORY: Unclear. SEE ALSO: #59 STATUS: Discussed 11/25/02, 12/02/02 RESPONSE: ACTION ITEM: 52a. [Michiharu Kudo] Need Michiharu's opinion as an XPath expert. ACTIONS: DISCUSSION: [TC Comments Subcommittee Meeting 12/02/02] Reasonable to use "context node". Does XPath expression start with the <Subject>, <Resource>, <Action>, or <Environment> element, or with <Request>? XACML parser should not need to know semantics of the XPath expression, and it should be passed off to an external library. This requires that the expression start with the root of the document. But, if the implementation is to handle "notional" Request, the XACML implementation will HAVE to parse these. Request element is always implied. XPath expression in Target implies Subject, Resource, or Action. XPath expression in Condition implies only Request. Implementations can pre-pend Request/[Subject Resource Action] depending on whether the expression appears in a Target or in a Condition if they want to make use of an XPath library. But what if the XPath expression is an absolute expression? Or if it uses .. to back up and go down a different path? [Seth Proctor] > Does XPath expression start with the <Subject>, <Resource>, > <Action>, or <Environment> element, or with <Request>, or, in > the case of <Target> elements, with the path following > <Subject>, <Resource>, or <Action>? The XPath expression should be valid against the document, so it should always start with the root of the document, Request. You may want to specify that for attributes resolved outside the physical request document, it is legal to start with some other root (which may aid the attribute resolver), but otherwise you should require a valid XPath expression against the request document. > -Request element is always implied. XPath expression in Target > implies Subject, Resource, or Action. XPath expression in > Condition implies only Request. Implementations can pre-pend > Request/[Subject Resource Action] depending on whether the > expression appears in a Target or in a Condition if they want to > make use of an XPath library. > > -But what if the XPath expression is an absolute expression? Or > if it uses .. to back up and go down a different path? Making the implementation guess at some pre-pending string is a very bad idea. The second item above points out some of the reasons why. I can think of no reason why it's easier or cleaner to allow this. The spec says now that the expression must be valid against the request, and I think that's the right way to go. Specify only that the expression must be valid, and then it's always handled correctly. [Anne Anderson, responding to Seth Proctor] You don't have to "guess". If the AttributeSelector occurs in a Target Subject, then pre-pend "Request/Subject. If the AttributeSelector occurs in a Target Resource, then pre-pend Request/Resource, etc. If the AttributeSelector occurs in a Condition, then prepend Request/. Such pre-pending is just for an implementation that somehow is able to use an XPath library even though, as far as I know, no such library would be able to deal with the "notional" Request Context and be helpful in resolving attributes not supplied in the physical request. Since a conforming implementation must deal with such attributes, a conforming implementation will probably have to parse XPath expressions itself (possible with some help), and can validate the expression according to the XACML-specified root. By specifying the particular roots, we can ensure that the Attribute being selected is in the correct element (i.e. is of the correct type). Any implementation that prepends strings must check to be sure that the expression does not use .. to back up over the pre-pended string. >Hrm. I think the new language is more confusing than the old language, since >it's just defining an AD/AS, but it doesn't say that that's what it's doing. >Still, it makes it clearer that a PDP should be able to look outside the >physcial document for attribute values. One thing this still doesn't address >is the issue of when it has to look elsewhere: if values are found in the >physical document, does it still have to do a search? If a value is found at >one location, must the CH continue on, doing an exhaustive search? If this >is left undefined, then different implementations can produce different >results from the same request. We could clarify using language similar to that used in describing the environment attributes: current-time, etc. [Seth Proctor, responding to Anne Anderson] > You don't have to "guess". If the AttributeSelector occurs in > a Target Subject, then pre-pend "Request/Subject. If the > AttributeSelector occurs in a Target Resource, then pre-pend > Request/Resource, etc. If the AttributeSelector occurs in a > Condition, then prepend Request/. Well, you do have to "guess" since, as the original comments pointed out, the expression may already have been absolute, or may contain back pointers or other XPath wierdness. You can parse the expression, figure out what it has, and then do some pre-pending, but that's slower, and means you can't as easily use existing libraries (see next comment). If you require a valid XPath expression from the start, you don't need to worry about this, though you should probably check that you're pointing into the right part of the request (which _can_ be done with most libraries). > Such pre-pending is just for an implementation that somehow is > able to use an XPath library even though, as far as I know, no > such library would be able to deal with the "notional" Request > Context and be helpful in resolving attributes not supplied in > the physical request. Since a conforming implementation must > deal with such attributes, a conforming implementation will > probably have to parse XPath expressions itself (possible with > some help), and can validate the expression according to the > XACML-specified root. Not true. A conforming implementation that uses AttributeSelectors must be able to look in the physical request document, and if nothing is found, it should pass the request on to the Context Handler. In this case, the first step can be done with an off-the-shelf XPath library, and if that fails, the expression can be passed to the Context Handler, which can choose what to do next. I'm not saying that this is the way it must be done, but it's certainly reasonable to expect that implementors will use existing libraries for this step (and probably use them in part for the next step). [Polar Humenn, responding to Seth Proctor] I knew this would come back to bite. The original intent for the AttributeSelector was to be able to look into the resource, should the resource or anything else exist as an XML document. Somehow, it got mucked into looking into the RequestContext, because the context is specified in XML, ho hum. As far as I'm concerned the "selector" shouldn't be able to look in the RequestContext at all, greatly simplifing matters. The RequestContext is kept "notional", but specified in XML for the lack of a using a good interface language. I think the AttributeSelector should only be used to look into XML based resources using XPATH, and not into the request context. That is why we have the *AttributeDesignator stuff. ------------------------------------------------------------------------ 0052b. "In the case where the XPath expression matches attributes in the request context by AttributeId, it must also match the attribute's data-type with the selector's DataType." Does the 'it' above mean the XPath expression? So, it's saying that if you write an xpath expression to select an attribute from the context, and the expression includes a predicate for matching with an AttributeID, then that expression MUST also include a predicate that matches the selectors data type with the data type of the selected attribute...? CATEGORY: Unclear. SEE ALSO: #59 STATUS: Discussed 11/25/02. RESPONSE: ACTION ITEM: 52b. [Michiharu Kudo] Need Michiharu's opinion as an XPath expert. ACTIONS: ------------------------------------------------------------------------ 0052c. "In the case of using XPath 1.0, the value of the XPath expression is either a node-set, string value, numeric value, or boolean value." This may seem a quibble, and it probably is, but even though the XPath specification says that the result of an expression can be a primitive... I do not believe there's any way to form an expression that actually returns one. In my experience all XPath 1.0 expressions return a node-set. (I'd be very interested to be corrected on this point. I just looked in the o'reilly xpath book and it has some examples that are plain literal values like, 2002, or "hello", but if you follow the grammar of the language they're just not valid expressions.) CATEGORY: Unclear. SEE ALSO: #59 STATUS: Discussed 11/25/02. RESPONSE: ACTION ITEM: 52c. [Michiharu Kudo] Need Michiharu's opinion as an XPath expert. ACTIONS: ------------------------------------------------------------------------ 0052d. "If the XPath 1.0 expression evaluates to a node-set, then each node may consist of a string, numeric or boolean value, or a child node (i.e. structured node). In this case, each node is logically converted to string data by applying the "string" function defined in the XPath 1.0 specification, resulting in a sequence of string data." This is correct in spirit, but not actually correct. In XPath 1.0 an expression evaluates to a node-set. There are seven kinds of node (root, element, text, attribute, namespace, processing instruction, and comment). The XPath specification describes a way of determining a <b>string-value</b> for each type of node. CATEGORY: Unclear. SEE ALSO: #59 STATUS: Discussed 11/25/02. RESPONSE: ACTION ITEM: 52d. [Michiharu Kudo] Need Michiharu's opinion as an XPath expert. ACTIONS: ========================================================================== 0059.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00129.html Subject: XACML questions ... From: Gene Thurston [ mailto:
gthurston@amberpoint.com ] Sent: Wednesday, November 20, 2002 8:21 PM I was working with the latest XACML draft, and I had a few questions, mostly around the optional XPath capability outlined in it: ------------------------------------------------------------------------ 0059b. When used inside a <SubjectMatch> element, is the XPath expression found in the <AttributeSelector> evaluated over the entire context document, or just over the <Subjects> sub-tree? CATEGORY: Unclear. STATUS: Discussed 12/02/02. SEE ALSO: #52 RESPONSE: Depends on resolution to #52. ACTIONS: ------------------------------------------------------------------------ 0059c. Same question for <ResourceMatch> and <ActionMatch>? CATEGORY: Unclear. STATUS: Discussed 12/02/02. SEE ALSO: #52 RESPONSE: Depends on resolution to #52. ACTIONS: ------------------------------------------------------------------------ 0059d. If the answer to the above is that the XPath expressions are always evaluated over the entire context document, then what are the semantics if such an expression inside, say, a <SubjectMatch> element evaluates to something outside the <Subjects> sub-tree? Is this just, "OK" (as I suspect), or is there supposed to be something special about the fact that it was inside a <SubjectMatch> so we shouldn?t match anything outside the subject?s attributes? CATEGORY: Unclear. STATUS: Discussed 12/02/02. SEE ALSO: #52 RESPONSE: Depends on resolution to #52. ACTIONS: ------------------------------------------------------------------------ 0059e. If it is "OK", then there is no difference between <SubjectMatch>, <ResourceMatch>, or <ActionMatch>, and perhaps there should be a generic <AttributeSelectorMatch> or something similar? CATEGORY: Inconsistent STATUS: Discussed 12/02/02. SEE ALSO: #52 RESPONSE: Depends on resolution to #52. ACTIONS: ------------------------------------------------------------------------ DISCUSSION FOR ALL: [Tim Moses, responding to Gene directly] I'll pass your questions on to the XACML comment list, in order to ensure that they get recorded and addressed, and that any lack of clarity is corrected. Basically, attributes of subjects, resources and actions (but not environment) may appear in a policy's target. A policy is applicable to a request if at least one of its subject matches is true AND at least one of its resource matches is true AND at least on of its action matches is true. AttributeSelector may be used in any of these match types. In the case of a subject match, for instance, the "context" node for the XPath expression is xacml-context/Subject. And similarly for the other types. On the other hand, AttributeSelector may also be used in an Apply element to define an argument to an expression. In this case, the "context" node for the XPath expression is the whole xacml:context. So, it can select any attribute of any entity (subject, resource, action or environment), but it has to explicitly indicate which type of entity is intended. [John Merrells, responding to Tim Moses] > AttributeSelector may be used in any of these match types. In the > case of a subject match, for instance, the "context" node for the > XPath expression is xacml-context/Subject. And similarly for the > other types. Whoa... the spec doesn't say that. The spec says that for an AttributeSelector the context node for the evaluation of the XPath expression is the Request element... !?! ========================================================================== 0063.
http://lists.oasis-open.org/archives/xacml-comment/200212/msg00008.html Subject: SubjectCategory XML attribute:string or URI? From: Anne Anderson <
Anne.Anderson@Sun.com> Date: Tue, 03 Dec 2002 11:20:45 -0500 (EST) I recommend we change the type of the SubjectCategory XML attribute in both the Policy and, based on the 12/02/02 change, in the Context. RATIONALE: All the values we have defined for SubjectCategory are URIs. It is very important that custom SubjectCategory values not collide with each other. When subject-category was an XACML attribute, it probably made sense for the Policy SubjectCategory XML attribute to be a string since we specified that string-equals comparison was to be done. But the actual syntax of the SubjectCategory value should be something that is likely to be unique, and can be made not to collide with other values, and now that we are specifying that syntax, I believe it should be a URI. CATEGORY: Alternative. SEE ALSO: STATUS: Not yet discussed. RESPONSE: ACTIONS: DISCUSSION: ========================================================================== 0064.
http://lists.oasis-open.org/archives/xacml-comment/200212/msg00014.html Subject: <StatusCode Value= type> From: Anne Anderson <
Anne.Anderson@Sun.com> Date: Tue, 03 Dec 2002 15:30:59 -0500 (EST) In the current schema, the type of the StatusCode Value XML attribute is specified as xs:QName. I believe it should be xs:anyURI to agree with our previous decisions about avoiding use of QNames except within schemas to refer to other schema elements. CATEGORY: Inconsistent. SEE ALSO: STATUS: Not yet discussed. RESPONSE: ACTIONS: DISCUSSION: ========================================================================== 0065.
http://lists.oasis-open.org/archives/xacml-comment/200212/msg00015.html Subject: resource question & comment From: Seth Proctor <
seth.proctor@sun.com> Date: Tue, 03 Dec 2002 17:43:31 -0500 ------------------------------------------------------------------------------- 0065a. Comment: In section 7.8, the urns for the scope types are called out, but the resource id is referred to simply as 'ResourceId' and not by its complete urn. This should reference the urn for resource-id (I suspect this is left over from when the Resource section of a Request actually had a ResourceId). CATEGORY: Inconsistent. SEE ALSO: STATUS: Not yet discussed. RESPONSE: ACTIONS: DISCUSSION: ------------------------------------------------------------------------- 0065b. Question: In the ResultType, there is a ResourceId XML attribute, but it's of type anyURI. Should this be a string instead? Many systems allow things like spaces in path names, which is illegal in a URI. I realize that these can be escaped in URIs, but that may be extra processing for the application to do. I don't care either way, but I thought I'd bring it up. CATEGORY: Alternative. SEE ALSO: STATUS: Not yet discussed. RESPONSE: ACTIONS: DISCUSSION: ========================================================================== 0066.
http://lists.oasis-open.org/archives/xacml-comment/200212/msg00016.html Subject: another resource question From: Seth Proctor <
seth.proctor@sun.com> Date: Tue, 03 Dec 2002 18:08:04 -0500 Section 7.8 doesn't say anything about error conditions, and I'm wondering if it should. I know that some things are out of scope and shouldn't be considered (eg, if only some Descendants could be resolved, the app-specific code should decide whether or not this is an error). But what should happen if there is some unrecoverable error in the process of discovering the resource list? Should the PDP return an error, or should it evaluate with the single resource that was provided in the Request? I would hope it could return an error, but 7.8 doesn't say anything about this. CATEGORY: Incomplete. SEE ALSO: STATUS: Not yet discussed. RESPONSE: ACTIONS: DISCUSSION: [Bill Parducci] i believe that the behavior is a return of INDETERMINATE with a status code of '[...]processing-error' (now that status codes are no longer optional). ========================================================================== 0067.
http://lists.oasis-open.org/archives/xacml-comment/200212/msg00018.html Subject:Section 8.2 "Extensible XACML attribute types" needsrevision From: Anne Anderson <
Anne.Anderson@Sun.com> Date: Wed, 04 Dec 2002 08:15:42 -0500 (EST) Section 8.2 is a bit garbled, and now that we have SubjectCategory as an XML attribute instead of an XACML Attribute, it needs re-wording anyway. Here is my proposal: 1. Eliminate Section 8.2. Now that subject-category is not an XACML attribute, there are no longer any XACML-defined AttributeIds that have pre-defined, but extensible, values. 2. Add "SubjectCategory" to the list of "Extensible XML attribute types" in Section 8.1. CATEGORY: Incorrect. SEE ALSO: STATUS: Not yet discussed. RESPONSE: ACTIONS: DISCUSSION: ========================================================================== 0068.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00134.html Subject: D002 From: John Merrells <
merrells@jiffysoftware.com> Date: Tue, 26 Nov 2002 17:35:05 -0800 [Same comment submitted for D024] The policy uses string-equal as if the args were (bag<string>,string), this should probably be using the any-of method... <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:conformance-tests:bogus" DataType="
http://www.w3.org/2001/XMLSchema#string"/ > <AttributeValue DataType="
http://www.w3.org/2001/XMLSchema#string" ;;>Zaphod Beeblebrox</AttributeValue> CATEGORY: Incorrect. SEE ALSO: STATUS: Not yet discussed. RESPONSE: ACTIONS: DISCUSSION: [Anne Anderson] As in D002, this Condition was intended to produce an Indeterminate result (by passing the wrong argument type to the function) in order to test the requirements of the "first-applicable" algorithm, which says that a Permit or Deny result will be returned even if an Indeterminate result follows. [Polar Humenn, responding to Anne Anderson] The condition that John is referring to in urn:oasis:names:tc:xacml:1.0:conformance-test:IID024:policy3 in test D024 is not type correct and therefore is not a valid policy, and therefore not a valid policy set. Although it might niavely parse through the policy-schema, it should not even be evaluated, because it is not type correct. [Anne Anderson, responding to Polar] Polar, I disagree. In my opinion, the type checking for arguments to functions should be done at the time the function is evaluated, not at the time the policy is parsed. Since we have not specified the type-correctness of XACML functions using XML, the type correctness must be checked after the policy is parsed by the XML parser. It could be done as a second, XACML-specific parsing step, but I believe it is probably cleaner to have the type checking done at the time the function is evaluated. This may make it easier to deal with plug-in custom functions. [Simon Godik, responding to Anne Anderson] In my opinion, compile-time policy type-checking is essential (although not normative) for the xacml implementation. If you do not have typechecking done you are never sure what is going to happen at run-time. I do not think that run-time type-checking is 'clean', I think it is 'wrong'. Static typechecker will reject policies you may find appropriate just because they pass schema validation. [Daniel Engovatov, responding to Simon Godik] It seems to me that we are not talking about the same "time". XACML does not specify (and can not specify) the content of the context at "compile" time - i.e. policy exists independent of the context. How can it be guaranteed to be typechecked simultaneously (though it certainly can be done, in particular implementations that do have control over context and do not have external function extensions)? Only certain arguments can be always typechecked in advance (such as static value specified in policy, or <apply> elements). This is actually why it is important to NOT have polymorphic functions in condition, so that <apply> element always has a predefined type, even if its arguments are retrieved from context in the runtime.. [Polar Humenn, responding to Anne Anderson] > Polar, I disagree. In my opinion, the type checking for > arguments to functions should be done at the time the function > is evaluated, not at the time the policy is parsed. Hmmm. so, we must be calling every policy that merely passes the policy schema a "valid" policy? That's like saying that class Josed { String ridiculous(String s) { return 1 + s; } } is a valid Java class definition. Try to evaluate that. > Since we have not specified the type-correctness of XACML > functions using XML, the type correctness must be checked after > the policy is parsed by the XML parser. Well there is no way to describe type correctness in XML through the use of a schema. That technology is far less advanced than the idea. The schema is merely a syntax grammar. That's why we have the document. To describe the semantics that cannot be described in XML. > It could be done as a second, XACML-specific parsing step, but > I believe it is probably cleaner to have the type checking done > at the time the function is evaluated. This may make it easier > to deal with plug-in custom functions. Now, doesn't that force a PDP to accept BAD policies? I wouldn't call that "security savvy". Any policy that has something wrong with it, like a type error is extremely suspect and leaves me no assurance as to its correctness of its other parts. Are we forcing PDP's to accept policy sets with nonsensical policies, accept policies with nonsensical rules, accept rules with nonsensical conditions, and accept conditions with nonsensical elements, for example, within an AND or and OR, of which only depending on certain input you find them invalid? IMHO, horrible! If XACML forces my PDP to accept Policy Sets that merely validate against a parse tree but cannot come to some semantic meaning or integrity of evaluation, then why bother with the types at all? In fact, why even bother validating against the policy or request schema? Do we have conformance tests for Policies and RequestContext that do not conform to the schemas? If not, why not? If so, what do they evaluate to? A conformance test for: <?xml version="1.0" encoding="UTF-8"?> <Policy/> against <?xml version="1.0" encoding="UTF-8"?> <RequestContext/> Both structures are valid XML, aren't they? What would a compliant valid PDP evaluate this scenario to? [Daniel Engovatov, responding to Polar Humenn] > Both structures are valid XML, aren't they? What would a > compliant valid PDP evaluate this scenario to? They are not, not according to this schema: <xs:element name="Policy" type="xacml:PolicyType"/> <xs:complexType name="PolicyType"> <xs:sequence> <xs:element ref="xacml:Description" minOccurs="0"/> <xs:element ref="xacml:PolicyDefaults" minOccurs="0"/> <xs:element ref="xacml:Target"/> <xs:element ref="xacml:Rule" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="xacml:Obligations" minOccurs="0"/> </xs:sequence> <xs:attribute name="PolicyId" type="xs:anyURI" use="required"/> <xs:attribute name="RuleCombiningAlgId" type="xs:anyURI" use="required"/> </xs:complexType> In any case it is not the issue of the document validity - but the issue that the policy exists (and can be "compiled" and accepted independent of the data context, in the general case. [Polar Humenn, responding to Daniel Engovatov] > It seems to me that we are not talking about the same > "time". XACML does not specify (and can not specify) the > content of the context at "compile" time - i.e. policy exists > independent of the context. That is true. > How can it be guaranteed to be typechecked simultaneously > (though it certainly can be done, in particular implementations > that do have control over context and do not have external > function extensions)? Easily. The Policy is typechecked unto itself, as is the RequestContext. The attributes in the context are all typed, and selection from the policy is based on type. If attribute A of type T is in the context, but the policy is looking for attribute A of type U, then the sought after attribute isn't there. Everything works. > Only certain arguments can be always typechecked in advance > (such as static value specified in policy, or <apply> > elements). All arguments can be type checked in advance. > This is actually why it is important to NOT have polymorphic > functions in condition, so that <apply> element always has a > predefined type, even if its arguments are retrieved from > context in the runtime.. D; The theory of type systems and polymorphic functions allows complete typing of every element of an expression. [Daniel Engovatov, responding to Polar Humenn] >All arguments can be type checked in advance. Define "advance"? Yes, it is typechecked before the decision is made. The exact sequence of said operations is implementation dependent. That's why I said we are talking about different definition of time. My point was that the policy document MAY be tested and accepted INDEPENDENT of context data type verification. In implementation that is concerned about efficiency that may be a key distinction. >The theory of type systems and polymorphic functions allows >complete typing of every element of an expression. The practice of implementation of said systems cause a great deal of PITA for extension API development, that being the reason of such language being rather unpopular. [Polar Humenn, responding to Daniel Engovatov] I didn't say whether the scenario was valid XACML, but it valid XML, isn't it? Isn't that enough criteria? Some SAX/DOM parser can handle it, right? My point is, if we actually have conformance tests for badly formed policies of a certain ilk, then why not have conformance tests for other badly formed policies? > Define "advance"? It was your term. > Yes, it is typechecked before the decision is made. The exact > sequence of said operations is implementation dependent. > That's why I said we are talking about different definition of > time. > > My point was that the policy document MAY be tested and > accepted INDEPENDENT of context data type verification. Yes, but I was not referring to the context data. The actual policy was not type correct, and hence not well formed. ========================================================================== 0069.
http://lists.oasis-open.org/archives/xacml/200212/msg00027.html Subject: IIC012: syntax-error or processing-error? * From: Anne Anderson <
Anne.Anderson@Sun.com> * To: XACML TC <
xacml@lists.oasis-open.org> * Date: Wed, 04 Dec 2002 08:58:43 -0500 (EST) Conformance Test IIC012 is intended to test for the error case in which a Condition FunctionId uses a function that does not return a Boolean result. The <Condition is: <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:integer-subtract"> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:integer-one-and-only"> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:conformance-test:age" DataType="
http://www.w3.org/2001/XMLSchema#integer"/ > </Apply> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:integer-one-and-only"> <EnvironmentAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:conformance-test:bart-simpson-age" DataType="
http://www.w3.org/2001/XMLSchema#integer"/ > </Apply> </Condition> Question: should the StatusCode Value from evaluating this Policy be "urn:...:status:syntax-error" (since it is a type error), or "urn:...:status:processing-error"? I'm leaning toward syntax-error. What do others think? CATEGORY: Unclear. SEE ALSO: STATUS: Not yet discussed. RESPONSE: ACTIONS: DISCUSSION: [Polar Humenn] This is the same problem as D024. This policy is not well formed. It is type incorrect. There should be no status code, because it should not even be hinted at that it should be evaluated. [Anne Anderson, responding to Polar Humenn] Well, we are required to return a Status Code, and we have a Status Code called "syntax-error", which certainly does not imply that the policy was evaluated. I think this exactly fits what you want to convey. [Polar Humenn, responding to Anne Anderson] What I am worried about is the implication is that all PDPs must return an Indeterminate with a status code of syntax-error if asked to evaluate this policy to be compliant with the standard. You can't configure my PDP with a badly formed policy, so there is no hope in god's country of it even passing this conformance test! Maybe there should be two sets of conformance tests. One set for testing acceptance of well and badly formed policies, and the other set for the evaluation of well formed Request Contexts and Policies. [Anne Anderson, responding to Polar Humenn] The specification does not say that the PDP generates the actual Response sent back to the PEP. The specification says that the Context Handler is responsible for translating the input format into an internal representation consistent with a Request, and for translating the Response output into the format expected by the PEP. I think in this case the ContextHandler will be responsible for generating the Response with Indeterminate and syntax-error as the Value for the Status Code. [Seth Proctor, responding to Anne Anderson] Let me suggest this: the result should be NotApplicable. This is an invalid policy, so the PDP should be unable to parse it. Sine the PDP should reject the policy, there will be no available policy to service the request. Hence, the NotApplicable result. This gets back to a similar thread we started a couple of weeks ago about when to return messages about bad policies (ie, is the policy paresed on PDP startup, on request processing, etc.). I think in general it's hard to define what to do in some of these cases, because different implementators will handle this differently. I want my PDP to reject the invalid policy, therefore it will never be available to a request, and will result in NotApplicable. But that's my choice. It's unclear to me whether the spec allows a PDP to parse and use an invalid policy, which is essentially what's required to get Indeterminate in this case. There is, of course, another side to this. If a request comes into the PDP that causes a policy to be fetched and parsed for the first time, and if that policy is the only applicable policy, then an error in the policy could be reported back to the PEP. Why? Because you might want to make it clear that there was a policy for the request, but it was invalid. This might be useful for diagnostic reasons, but I can't think of any other use for this distinction. The spec doesn't really nail this point down, so it's hard to know for sure what the tests should assume. It's also hard to define whether or not this is the case that the tests are exercising. [Polar Humenn, responding to Anne Anderson] PDP, ContextHandler, PEP, without interfaces, what does it really matter? You wouldn't even get this far with a bad policy. For instance, my PDP will be automatically configured out of the box with a default policy that is guarranteed and assured to be correct (i.e. always "Deny", always "Permit", etc, maybe according to some configuration file). The PDP will be configured with policies through its administration interface (not defined by XACML), and will not accept a badly formed policy, and the previous policy will remain in place. So, the "ContextHandler" (whateveer that is) will never answer the request to a badly formed policy, because you cannot get the badly formed policy into the system. It will always work against the currently configured policy, which is guarranteed to be correctly formed. We should NOT be stating to PDP vendors that to be compliant, they must evaluate badly formed policies. [Polar Humenn, responding to Seth Proctor] You make some good points. and you are right to say that your PDP will return "Not-Applicable" for this policy. In fact, you'd be right if you wanted to return Deny, Permit, or Indeterminate, as well. The fact is that the answer for badly formed policies is "undefined". In my previous example, some one can configure the PDP initially to be "Deny", "Permit", "Not-applicable", or even possibly "Indetermiante with not-configured". So if you take operation of the conformance tests to be: 1. Load Policy to PDP 2. Load Request to Context Handler 3. Make request. For a bad policy, some PDPs might accept the policy and return Indeterminate with syntax-error. Yours would return Not-Applicable. Mine would be whatever it was set to before, because the badly formed policy would never get into the PDP. So, in essence, we don't and shouldn't define what happens in this case. Now, for your "another side", of which you ellude to here: > There is, of course, another side to this. If a request comes > into the PDP that causes a policy to be fetched and parsed for > the first time, and if that policy is the only applicable > policy, then an error in the policy could be reported back to > the PEP. Why? Because you might want to make it clear that > there was a policy for the request, but it was invalid. This > might be useful for diagnostic reasons, but I can't think of > any other use for this distinction. The spec doesn't really > nail this point down, so it's hard to know for sure what the > tests should assume. It's also hard to define whether or not > this is the case that the tests are exercising. This case is actually covered in the policy combining algorithms: "If an error occurs while evaluating the target of a policy, or a reference to a policy is considered invalid or the policy evaluation results in "Indeterminate", then the policy set SHALL evaluate to "Indeterminate"." which is in all of the combinging algorithm specifications. In this case, retrieving an "invalid" policy will result in an indeterminate. However, the status code is not specified, but that could be a meriad of factors, such as the policy reference is down, the policy behind the reference is invalid, etc. However, it is still up to the PDP adminstrative interface to decide whether all referenced policies are correct at load time and decide not to accept. If you take the more dynamcic case, that may defer the answer, but it is covered. [Seth Proctor, responding to Polar Humenn] > "If an error occurs while evaluating the target of a policy, or > a reference to a policy is considered invalid or the policy > evaluation results in "Indeterminate", then the policy set > SHALL evaluate to "Indeterminate"." By my reading, this only covers some of the cases. I see three reasons for an error in the quoted text: 1. An error occurs while evaluating the target of a policy 2. A reference to a policy is considered invalid 3. Policy evaluation returns Indeterminate Reasons 1 and 3 refer to policies that have been successfully parsed by the PDP. If the policy is invalid, then we [1] won't try target evaluation, and we won't get an error on policy evaluation. That leaves reason 2, which I believe only refers to a PolicyIdReference or a PolicySetIdReference. So, my original comments about run-time retrieval still apply. If I have a module in my PDP which lets me, for example, talk to an LDAP service to get policies, and a request comes in that applies to one and only one policy in the directory, but that policy is invalid, what should I do? The quoted text does not say anything about this case. I may choose to say I couldn't find any valid policies, so I return NA, or I could say I found an invalid policy, and return SyntaxError. It may be that case 2 is supposed to apply to this problem as well, in which case I think the text should be re-worked to make that clearer. In any case, I certainly agree with you that there are several scenarios where it is up to the implementor what to do. I think you explained that clearly in the your last email, so I won't repeat any of it here :) [Daniel Engovatov] I would think it is the syntax-error. There is nothing wrong about reporting an incorrectly formed policy and nothing sacred about type incorrectness. This is what status codes are for. Does your language interpreter or compiler just die in silence if there is a typo in the code? [Polar Humenn, responding to Seth Proctor] > > "If an error occurs while evaluating the target of a policy, > > or a reference to a policy is considered invalid or the > > policy evaluation results in "Indeterminate", then the policy > > set SHALL evaluate to "Indeterminate"." > > By my reading, this only covers some of the cases. I see three > reasons for an error in the quoted text: > > 1. An error occurs while evaluating the target of a policy > 2. A reference to a policy is considered invalid > 3. Policy evaluation returns Indeterminate > > Reasons 1 and 3 refer to policies that have been successfully > parsed by the PDP. If the policy is invalid, then we [1] won't > try target evaluation, and we won't get an error on policy > evaluation. In some cases, target evaluation will be through indexing, in which you must retrieve all the policies and the policies must have been parsed beforehand, so you will know if the containing policy is really valid or not due to its consitutents. In the case where policy behind the reference is considered valid before proven invalid, then you are effectively evaluating the targets of the policy as you retreive them, in which case the "error" will happen during evaluation of that particular target. The next case is if the reference is not valid. [Polar Humenn, responding to Daniel Engovatov] I'm not saying that you shouldn't return an indeterminate with a status code of syntax error. Go ahead! I'm just not for conforming to that result. [Daniel Engovatov, responding to Polar Humenn] A question: do we state that PDP is indeed processing XACML policy and request directly? In an implementation PDP may never even see the policy in question: errors in the policy document are beeing taken care by PAP and transformed in some other internal format, while the request context is processed by PEP and context handler. PDP may read and process the policy in an entirely different format - thus it can not pass this conformance test. [Polar Humenn, responding to Daniel Engovatov] I agree. [Bill Parducci, responding to Daniel Engovatov] > I would think it is the syntax-error. There is nothing wrong > about reporting an incorrectly formed policy and nothing sacred > about type incorrectness. This is what status codes are for. this is my thinking as well. it seems to me that this conversation ties back into the 'run-time' type checking discussion: on the one hand polar seems to be saying that he will have determined policy malformedness prior to the decision processs, while anne & seth are talking about those cases whereby a problem is discovered during the decision process. if this is true, then in the former case--polar's scenario--the situation of having a problem processing a policy would only likely be the result of some internal misfiring (PAP/PRP <--> PDP miscommunication, etc.) and i would think that this would most assuredly warrant an error code of some sort with an INDETERMINATE decision. the case of the policy being written properly would not occur, so the response in that case is moot. the latter case--anne & seth's--could arise under similar circumstances as well as by run-time checking issues (poorly written policies). as pointed out in this thread this would warrant an INDETERMINATE result with an error code. in both cases i think that the decision is clearly *not* NOTAPPLICABLE because the decision making process has begun using a policy that is undigestible (or in the case of polar's case, attempting to evaluate a policy that has be rendered inoperable by some unplanned event). otherwise, how does the PDP differentiate between a happily functioning system and one that has, say acess control rights, network issues, etc. with the policy repository? [Polar Humenn, responding to Bill Parducci] > if this is true, then in the former case--polar's scenario--the > situation of having a problem processing a policy would only > likely be the result of some internal misfiring (PAP/PRP <--> > PDP miscommunication, etc.) and i would think that this would > most assuredly warrant an error code of some sort with an > INDETERMINATE decision. the case of the policy being written > properly would not occur, so the response in that case is moot. This case I believe is covered by the combining algorithms specification. > the latter case--anne & seth's--could arise under similar > circumstances as well as by run-time checking issues (poorly > written policies). as pointed out in this thread this would > warrant an INDETERMINATE result with an error code. Again, covered by the combining algorithms. > in both cases i think that the decision is clearly *not* > NOTAPPLICABLE because the decision making process has begun > using a policy that is undigestible (or in the case of polar's > case, attempting to evaluate a policy that has be rendered > inoperable by some unplanned event). If that policy is being dynamically retrived, then you are in effect covered by the combining algorithms specification, and none of our standard ones say it's Not-APplicable. However, that doesn't stop you from defining your own that does. > otherwise, how does the PDP differentiate between a happily > functioning system and one that has, say acess control rights, > network issues, etc. with the policy repository? For the case when you have a single malformed policy to be evaluated against a request, the answer is just simply undefined. The implementer can choose. Therefore, there should not be a "CONFORMANCE" test for it.