Re: [xacml] re: Attribute Selector example

[Simon Godik <simon@godik.com>]

Michiharu,
You are correct, xpath-expr return type is the same as attribute-selector,
which is a node-set. I was under impression that we have this function
defined.
I'm not sure what to do with string-equal receiving output of
attribute-selector.
May be the right thing to do is to use general-string-equal(object a, object
b)
function that you proposed some time ago.

Simon

----- Original Message -----
From: "Michiharu Kudoh" <KUDO@jp.ibm.com>
To: <xacml@lists.oasis-open.org>
Sent: Sunday, August 25, 2002 12:50 AM
Subject: Re: [xacml] re: Attribute Selector example


>
> Simon
>
> I see that you meant function:node-match-1 in the example. I agree that it
> is another way to specify the same policy. The difference in our opinions
> would be relevant to how to handle XPath related function and data types
in
> XACML. In your example, you said that <AttributeSelector> can be
translated
> into 'function:xpath-expr' in Condition. If that is the case, what is the
> return type of the xpath-expr function? It must be the same with the
return
> type of <AttributeSelector>, right? Besides, In line 821-830, string-equal
> function receives a return value of the <AttributeSelector>. What data is
> handed to the string-equal function?
>
> Michiharu
>
> IBM Tokyo Research Laboratory, Internet Technology
> Tel. +81 (46) 215-4642   Fax +81 (46) 273-7428
>
>
>
>
>
>                       Simon Godik
>                       <simon@godik.com>        To:
xacml@lists.oasis-open.org
>                                                cc:
>                       2002/08/25 13:43         Subject:  [xacml] re:
Attribute Selector example
>
>
>
>
>
>
> Michiharu,
>
> I see that you want to compute the node-set of xpath expression specified
> in
> the request-context before passing it to the node-match function.
>
> Of course, something like that could be accomplished in the condition
> with 'xpath-expr' function:
> <Apply FunctionId="function:node-match">
>     <Apply FunctionId="function:xpath-expr">
>         <ResourceAttributeDesignator
>             AttributeId="urn:oasis:names:tc:xacml:1.0:resource:xpath"
>             DataType="xs:string"/>
>     </Apply>
>     <AttributeSelector RequestContextPath="..."/>
> </Apply>
>
> You want to do the same thing in the target.
>
> I'm not completely sold on your syntax for AttributeSelector. I'd prefer
> this extension:
> <AttributeSelector indirect="true"> (or IndirectAttributeSelector)
>     <ResourceAttributeDesignator AttributeId
> ="urn:oasis:names:tc:xacml:1.0:resource:xpath"
>         DataType="xsi:string"/>
> </AttributeSelector>
>
> Better yet to relax 'match' element to allow 'apply' children.
>
> Another approach:
> I think that complication is in 'node-match' function definition that
takes
> --results--
> of xpath expression. That forces you to produce this result, so you
> need additional semantics in attribute-selector.
>
> Consider different function that takes --xpath-expressions-- as arguments
> (as in examples in section 3). Than you do not have to produce node sets
> before calling this function and no change in schema is needed.
>
> Suppose that node-match-1 has exact same semantics as node-match but
> take 2 xpath expressions: xpath-expr-request and xpath-expr-rule:
> node-match-1(xpath-expr-req, xpath-expr-rule).
>
> You can use it in the target:
> <ResourceMatch MatchId="function:node-match-1">
>     <ResourceAttributeDesignator
>         AttributeId="urn:oasis:names:tc:xacml:1.0:resource:xpath"
>         DataType="xsi:string"/>
>     <AttributeValue DataType="xsi:string">//md:record</AttributeValue>
> </ResourceMatch>
>
> Simon
>
>
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>