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] Re: [xacml-comment] 5.31 Element <AttributeSelector>

Hi, John

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.

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.

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

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

Michiharu Kudo

IBM Tokyo Research Laboratory, Internet Technology
Tel. +81 (46) 215-4642   Fax +81 (46) 273-7428

|         |           John Merrells    |
|         |           <merrells@jiffyso|
|         |           ftware.com>      |
|         |                            |
|         |           2002/12/06 05:16 |
|         |                            |
  |                                                                                                              |
  |       To:       Michiharu Kudoh/Japan/IBM@IBMJP                                                              |
  |       cc:       XACML COMMENT <xacml-comment@lists.oasis-open.org>, XACML TC <xacml@lists.oasis-open.org>    |
  |       Subject:  Re: [xacml-comment] 5.31 Element <AttributeSelector>                                         |
  |                                                                                                              |
  |                                                                                                              |

Michiharu Kudoh wrote:

>"... it must also match the attribute's data-type ..." I think 'it' means
>the value(s) selected by XPath. For example,
>  <Subject>
>    <Attribute AttributeId="...subject-id" DataType
>      <AttributeValue>123</AttributeValue>
>    </Attribute>
>  </Subject>
>  ...
><AttributeSelector RequestContextPath="Subject/Attribute[AttributeId
>= '...subject-id']/AttributeValue"/>
>should return "123" that must be an integer from the DataType attribute.
>When "subject-id" matches two attributes, then the both value must be

In your example the AttributeSelector must include a DataType. I'll
assume that it is
the same type as the attribute that's being selected. So,

The result of executing the given XPath expression within a context
where the Request
node is the context node will be a nodeset containing a single element
node. The node
will have a type of AttributeValue and a value of '123'.

If the example request contained multiple subject attributes with the
given AttributeId
then the result of the expression valuation would be a nodeset
containing multiple
element nodes. Regardless of whatever type is specified by the
and Attributes.

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

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

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
value true.)

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.

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
can not be coerced into that DataType then what should the processor

>I think that the following XPath returns a boolean type: boolean
Nope. I think this is the basis of the problem in the specification.


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

Powered by eList eXpress LLC