[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Comments for discussion at TC meeting 12/05/02
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC