[xacml] Additional comments for today

[Anne Anderson <Anne.Anderson@Sun.com>]

Appended is an updated summary of #72a-d, and #73a-j.

Anne
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

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.

[John Merrells, responding to Michiharu Kudo]
>For the type correctness, I don't expect that option 1 always
>occurs. So each implementation should enforce the type
>correctness. I mean that the processor just calls some XPath
>processor to retrieve the requested node set irrespective of the
>datatype specified in the selector. After some string
>conversions are performed, the processor checks whether each
>string value can be converted to the datatype specified in the
>selector. Either way, this kind of run-time type checking should
>be implemented for the case of ResourceContent.

Good. The specification text needs to be changed. Currently it
states:

"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. "

>If XPath expression does not include a predicate expression to
>satisfy data type requirement (Subject/Attribute[AttributeId=
>'...subject-id' and DataType"..."]/AttributeValue), it can
>select a node that has different data type. But I think this is
>the problem of the policy specification and not the problem of
>the AttributeSelector specification. Certainly, it would be
>better to add some note about this in the specification.

Yes. If the expression author writes an XPath that selects
multiple attribute values with different DataTypes, then that is
their problem.

It would be good for the specification to point this out for
expression writers.
--------------------------------------------------------------------------
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.

[John Merrells, responding to Michiharu Kudo]
>I think that the semantics of the AttributeSelector should
>conform to the specified version of the XPath. So the conversion
>functions would be ones specified in the corresponding XPath
>specification. In the case of XPath 1.0, each conversion (node
>set to string value and string value to each data type) would be
>the conversion specified in XPath 1.0 even if it may have some
>oddities in it.

I'd suggest that Implementors of XACML will find it easier to
convert a string into an XACML type, than to convert a string
into an XPath type and then into an XACML type. Fisrtly the XPath
conversion functions would have to be exposed through the XPath
processor API. The XPath interface specification does not mandate
this. Also, the string to XACML type constructors should be
readily available. [As the implementor will almost certainly have
implemented these for expression processing.] Secondly, the
specification will have to provide a table that maps the XPath
type system onto the XACML type system.


--------------------------------------------------------------------------
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.

[John Merrells, responding to Michiharu Kudo]
>And I could not find any XACML function definition that converts
>"false" string value to False boolean value in the committee
>specification. Which function are you talking about?

Section '4.3 Boolean Functions': "Function: boolean
boolean(object) ... a string is true if and only if its length is
non-zero"

>If the conversion failed, then "Indeterminate" should be
>returned (optionally with some status code such as
>syntax-error).

This statement should be added to the specification.
--------------------------------------------------------------------------
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).
===========================================================================
0073. http://lists.oasis-open.org/archives/xacml-comment/200212/msg00047.html
Subject: XACML 1.0 Committee Specification Comments
From: "Chopra, Dipak" <dipak.chopra@sap.com>
Date: Mon, 09 Dec 2002 05:44:55 +0100

I reviewed the XACML 1.0 Committee Spec and here is the list of questions/comments.
----------------------------------------------------------------------------------
0073a. Can PAP and PDP exchange Policy Set?

Based on the Section 3.1 Data Flow Model, it seems like only
Policy can be exchanged. If that is the case, how can PDP
evaluate Policy Set as mentioned in Section 7.7 Policy Set
Evaluation?

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

DISCUSSION:
----------------------------------------------------------------------------------
0073b. What is the commonality between different Policy elements
in the same Policy Set?

The requirement on line #354 seems to indicate that the merging
of different Policy elements into Policy Set is governed by "a
given action". Does it mean that the cardinality between Policy
Set and Action is 1 to 1? It seems confusing as schema does not
suggest that.

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

DISCUSSION:
----------------------------------------------------------------------------------
0073c. As Target can have multiple Resource and Action elements,
not every Action is valid for each Resource. But the current
schema allows to provide more non-existent access to resources.

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

DISCUSSION:
----------------------------------------------------------------------------------
0073d. What is the significance of an Obligation with
FulfillOn="Deny"?

Which use case needs this feature?

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

DISCUSSION:
----------------------------------------------------------------------------------
0073e. Line #2675, scope can be "Descendants" or "Children" as
mentioned on lines #2907, 2908 in the case of multiple results.

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

DISCUSSION:
----------------------------------------------------------------------------------
0073f. Section 7.6 Policy Evaluation.

The table should be Policy truth table.

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

DISCUSSION:
----------------------------------------------------------------------------------
0073g. Section 7.7 Policy Set Evaluation.

The table should be Policy Set truth table.

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

DISCUSSION:
----------------------------------------------------------------------------------
0073h. In this table, what is the meaning of "Effect" of Policy.

As far as schema is concerned, Policy does not have this
attribute. Only Rule has Effect element. Probably the right
statement "At least one policy value has the calculated effect
value".

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

DISCUSSION:
----------------------------------------------------------------------------------
0073i. Line #2907, 2908.

It seems like authorization decision MAY include multiple results
based on the structure of resource sub-tree. I think this
mechanism provides more information than requested. PEP is
requesting if this subject(s) has the specified access
(actions(s)) on the specified resource and its child nodes. The
response should be one result. Why would PEP want to get detailed
result information for each sub-node under resource? PEP must
know about the structure (if there is any) of the requested
resource and accordingly request for authorization decision from
PDP. Based on that response, PEP should be able to allow or
disallow the request. On line #2968, it says only one Decision
element, which is not right based on lines #2907, 2908.

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

DISCUSSION:
----------------------------------------------------------------------------------
0073j. There are two different types of resources.

Functionality resource and data-instance resource. For example,
ManagePO resource can be used to create/delete/modify an instance
of PO. So ManagePO is a type of functionality type resource and
instance of PO is a data-instance type resource. If we need to
mandate that this action of this data-instance type resource can
only be permitted by this functionality-type resource, how do we
enforce that?

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

DISCUSSION:
=====================================================================================