[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC