[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Re: [xacml-comment] 5.31 Element <AttributeSelector>
For 0052b, I did not notice that there had some discussion about this in
the Thursday concall.
>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."
>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.
I approve the terminology. I did not think about XACML context handler when
I posted the message. So this resolves the problem described in the second
sentence in my previous message. (but this does not remove the need for the
run-time type checking required in the ResourceContent case because it is
not applicable.)
Michiharu Kudo
IBM Tokyo Research Laboratory, Internet Technology
Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
----- Forwarded by Michiharu Kudoh/Japan/IBM on 2002/12/06 16:15 -----
|---------+---------------------------->
| | Michiharu Kudoh |
| | |
| | 2002/12/06 16:06 |
| | |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------|
| |
| To: John Merrells <merrells@jiffysoftware.com> |
| cc: XACML COMMENT <xacml-comment@lists.oasis-open.org>, XACML TC <xacml@lists.oasis-open.org> |
| From: Michiharu Kudoh/Japan/IBM@IBMJP |
| Subject: Re: [xacml-comment] 5.31 Element <AttributeSelector>(Document link: Michiharu Kudoh) |
| |
| |
| |
| |
| |
>--------------------------------------------------------------------------------------------------------------|
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:
>2.
>"... it must also match the attribute's data-type ..." I think 'it' means
>the value(s) selected by XPath. For example,
>
><Request>
> <Subject>
> <Attribute AttributeId="...subject-id" DataType
="...XMLSchema#integer">
> <AttributeValue>123</AttributeValue>
> </Attribute>
> </Subject>
> ...
></Request>
>
><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
>integers.
>
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,
DataType="...XMLSchema
#integer"
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
AttributeSelector
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
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"]
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.)
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
value
can not be coerced into that DataType then what should the processor
return?
>3.
>I think that the following XPath returns a boolean type: boolean
>("Subject/Attribute[AttributeId='...subject-id']/AttributeValue").
>
Nope. I think this is the basis of the problem in the specification.
John
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC