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: Re: [xacml] re: Attribute Selector example


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?


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                                                                 
                      2002/08/25 13:43         Subject:  [xacml] re: Attribute Selector example                                                     


I see that you want to compute the node-set of xpath expression specified
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">
    <AttributeSelector RequestContextPath="..."/>

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

Better yet to relax 'match' element to allow 'apply' children.

Another approach:
I think that complication is in 'node-match' function definition that takes
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">
    <AttributeValue DataType="xsi:string">//md:record</AttributeValue>


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

Powered by eList eXpress LLC