OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [xacml] Updated Comments for 12/9/02 Meeting


The 12/9/02 Comments Subcommittee meeting and the 12/12/02 TC
meeting are VERY important.
- At the Subcommittee meeting, we MUST resolve all remaining
  comments (including any that come in between now and Sunday).
- At the TC meeting, we MUST have at least 2/3 of the TC members
  present in order to vote to approve the 1.0 Specification.
  Please make arrangements to call in: the vote will be held at
  the beginning of the 2-hour scheduled time (after the roll
  call).

Appended are the unresolved comments up to this time.  Remember
to check for any additional ones that come in over the weekend!

Anne Anderson
-- 
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

SUMMARY
=======

This version of the file contains e-mail up through
http://lists.oasis-open.org/archives/xacml-comment/200212/msg00044.html
and
http://lists.oasis-open.org/archives/xacml/200212/msg00065.html

ACTION ITEMS:
52b. [Tim] develop text changes to implement the response.
     [Michiharu] review Tim's text changes for correct use of
     XPath terminology.
DUE: 12/09/02

The unresolved comments are:
- 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."
  Status: resolved in intent; waiting for wording.

- 0066. http://lists.oasis-open.org/archives/xacml-comment/200212/msg00016.html
  Subject: another resource question From: Seth Proctor
  Status: resolved in intent; waiting for wording to be developed
          and approved.
- 0068. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00134.html
  Subject:  D002
  Status: Issue is policy type checking, whether it is relevant
          to a Request evaluation, and if so, what the Result
          should be.
- 0069. http://lists.oasis-open.org/archives/xacml/200212/msg00027.html
  Subject: IIC012: syntax-error or processing-error?
  Status: same as #68

- 0071. http://lists.oasis-open.org/archives/xacml-comment/200212/msg00035.html
  Subject: Element <Description>
  Status: not yet discussed

- 0072. http://lists.oasis-open.org/archives/xacml-comment/200212/msg00039.html
  Subject: 5.31 Element <AttributeSelector>
  Status: not yet discussed. I believe most of the sub-comments
  have been resolved, but 72d may require some discussion.
   
UNRESOLVED COMMENTS
===================
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.
STATUS: Response resolved 12/05/02.
RESPONSE: "it" means the XACML context handler.  The XACML
context handler must filter the values returned by the XPath
expression based on matching the DataType, returning only those
that match the DataType to the PDP.
ACTION ITEM: #52b [Tim] come up with wording; [Michiharu] approve
terminology. DUE 12/9/02.
ACTIONS: 
==========================================================================
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.
STATUS: Response resolved 12/05/02. Implementation of the ACTION
to be reviewed and approved 12/9/02.
RESPONSE: Allow for <Decision>s to be returned about resources
that could not be discovered.  Do this by returning a <Decision>
with the ResourceId of the hierarchical element that could not be
resolved or completely resolved, with an error <Status> on that
<Decision>.  Other <Decision>s on hierarchical elements, even if
they are descendants of the element that has the error, may have
non-error <Status> in the same Response.
ACTIONS: In Section 7.8, add wording to effect the above.  In the
next to last paragraph of Section 7.8, pdf:2909-2911, remove the
sentence starting with "In this case, the <Status> element SHOULD
be..."

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).
==========================================================================
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: #69
STATUS: Not yet discussed.
RESPONSE: 
ACTIONS:

DISCUSSION:
[long discussion on xacml@lists.oasis-open.org not included here.]

Issue is whether type checking in a policy is done by the XACML
PDP at the time a policy is evaluated or before the policy is
ever passed to the XACML PDP.  If policy type checking is done by
the XACML PDP, then D002 (as originally formed) should return a
syntax-error.  If type checking is done before a policy is ever
made available to the XACML PDP, then Conformance Test D002 (as
originally formed) is meaningless, because the policy above would
fail type checking and thus never be passed to the XACML PDP and
would never be available for evaluation at the time a Request is
received.

If type checking is done before a policy is ever presented to a
PDP, then how are errors detected?  How does the PEP know, for
example, that NotApplicable was returned because the policy that
was supposed to apply had a syntax error?  Or must these types of
errors be detected and handled by another part of the access
control system, such as the PAP interface to the XACML PDP?

[Anne Anderson]
Are there any objections to the following resolution to the type
and syntax checking debate, at least with respect to the
Conformance Tests?  This may not resolve the issue completely,
but I feel we need to decide as soon as possible what the
Conformance Tests will do so that implementations can attest to
"successfully using" this coming week.

1) I have added the following "Special Instructions" to the two
   tests that test that an invalid policy will never be used to
   return a Permit, Deny, or NotApplicable result.

- Special Instructions for Test Case II.A.4

  The policy for this test is not schema-compliant: it contains a
  syntax error.

  If a policy with invalid syntax MAY EVER be evaluated by the
  implementation's XACML PDP at the time a Request is received,
  then this test MUST be passed.  In this case, the result MUST be
  consistent with the supplied IIA004Response.xml file: it returns
  a Decision of Indeterminate with a StatusCode value of
  "urn:oasis:names:tc:xacml:1.0:status:syntax-error".

  If the implementation's XACML PDP CAN NEVER attempt to evaluate a
  policy with invalid syntax, then the implementation MUST
  demonstrate that the policy in IIA004Policy.xml will be rejected
  by whatever entity is responsible for validating policy syntax in
  the system in which the XACML PDP will be used.  In this case,
  the supplied Request and Response files are not relevant and may
  be ignored.

- Special Instructions for Test Case II.C.3

  The policy for this test contains a static type error.

  If a policy with static type errors MAY EVER be evaluated by the
  implementation's XACML PDP at the time a Request is received,
  then this test MUST be passed.  In this case, the result MUST be
  consistent with the supplied IIC003Response.xml file: it returns
  a Decision of Indeterminate with a StatusCode value of
  "urn:oasis:names:tc:xacml:1.0:status:processing-error".

  If the implementation's XACML PDP CAN NEVER attempt to evaluate a
  policy with static type errors at the time a Request is received,
  then the implementation MUST demonstrate that the policy in
  IIA004Policy.xml will be rejected by whatever entity is
  responsible for validating policy syntax in the system in which
  the XACML PDP will be used.  In this case, the supplied Request
  and Response files are not relevant and may be ignored.
==========================================================================
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>
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: #68
STATUS: Not yet discussed.
RESPONSE: 
ACTIONS:

DISCUSSION:
Long discussion on xacml@lists.oasis-open.org
See #68.
==========================================================================
0071. http://lists.oasis-open.org/archives/xacml-comment/200212/msg00035.html
Subject: Element <Description>
From: Anne Anderson <Anne.Anderson@Sun.com>
Date: Thu, 05 Dec 2002 14:02:39 -0500 (EST)
--------------------------------------------------------------------------
0071a. In Section 5.20 "Element <Policy>" under the description of the
   <Description> sub-element, add "See 5.2 Element
   <Description>."

CATEGORY: Unclear.
STATUS: Not yet discussed.
RESPONSE: 
ACTIONS: 
--------------------------------------------------------------------------
0071b. In Section 5.2 "Element <Description>", change first sentence
   from:

     The <Description> element is used for a free-form
     description of the <PolicySet> element and <Policy>
     element.

   to:
   
     The <Description> element is used for a free-form
     description of the <PolicySet>, <Policy>, and <Rule>
     elements.

CATEGORY: Incomplete.
STATUS: Not yet discussed.
RESPONSE: 
ACTIONS: 
===========================================================================
0072. http://lists.oasis-open.org/archives/xacml-comment/200212/msg00039.html
Subject: 5.31 Element <AttributeSelector>
From: John Merrells <merrells@jiffysoftware.com>
Date: Thu, 05 Dec 2002 12:16:38 -0800
------------------------------------------------------------------------
0072a. If you want to enforce type correctness

between the selector and the values then you have these
choices... 1) The author of the XPath expression must write the
expression so that it matches both the AttributeId and the
DataType.

Subject/Attribute[AttributeId= '...subject-id' and DataType"..."]/AttributeValue

or, 2) the processor must enforce the type correctness. Option 1
is clearly error prone as people just won't bother, option 2
could be quite hard.  [Although using the AttributeValue as the
context node you could say "../@DataType"]

CATEGORY: Incomplete.
STATUS: Not yet discussed.
RESPONSE: 
ACTIONS: 

DISCUSSION:
[Anne Anderson]
I think we specified option 2 in the resolution to 0052b:

The XACML context handler must filter the values returned by the
XPath expression based on matching the DataType, returning only
those that match the DataType to the PDP.
--------------------------------------------------------------------------
0072b. How is the selected node converted into a value?

You can convert a node into a string-value, as defined in the
XPath spec. You then have a choice of using the string to value
conversions that are defined in XPath, or use the conversions as
defined in XACML. I would specify as the later, as XPath has some
oddities in this area. (ie. The string 'false' has the boolen
value true.)

CATEGORY: Incomplete.
STATUS: Not yet discussed.
RESPONSE: 
ACTIONS: 

DISCUSSION:
[Anne Anderson]
I believe this is clearly specified in Section 5.33,
pdf:2404-2415:
XPath 1.0: apply "string" function
XPath 2.0: use xf:string accessor function.
--------------------------------------------------------------------------
0072c. The next problem is working out which type to convert the string-value into.

If we assume that the author or processor has checked that the
selector and value types match then we can use the DataType
specified in the selector.

CATEGORY: Incomplete.
STATUS: Not yet discussed.
RESPONSE: 
ACTIONS: 

DISCUSSION:
[Anne Anderson]
I believe this is specified in the response to #52b: The XACML
context handler must filter the values returned by the XPath
expression based on matching the DataType, returning only those
that match the DataType to the PDP.
--------------------------------------------------------------------------
0072d. Another example that should be explored is an XPath
expression executed over the ResourceContent.

In this case there are no DataTypes provided with the values, so
there's no type checking that can be performed. We can only
assume that the value provided is a valid representation for a an
instance of the value of DataType specified in the selector. If
the value can not be coerced into that DataType then what should
the processor return?

CATEGORY: Incomplete.
STATUS: Not yet discussed.
RESPONSE: 
ACTIONS: 

DISCUSSION:
[Michiharu Kudo]
In the case of ResourceContent, the selected node set and resultant string
value(s) must be checked against the data type specified in the selector.
If the conversion failed, then "Indeterminate" should be returned
(optionally with some status code such as syntax-error).
===========================================================================



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC