Colleagues, Comment #48 below requests that the restriction on MatchId functions be loosened to include functions other than the XACML standard ones, so long as the MatchId function 1) returns #boolean 2) takes AttributeDesignator or AttributeSelector as its first argument (or second, depending on resolution of #57) 3) takes AttributeValue as its second argument (or first, depending on resolution of #57). I have re-worded Appendix A.12 yet again to be consistent with this requested change. The revised A.12 is attached. Please review and comment. Anne ========================================================================= 0048.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00086.html Subject: Resource types From: Paul Andrews <
paandrew@cisco.com> Date: Fri, 22 Nov 2002 10:28:59 -0500 I note that the set of types allowed in a 'resource' element is restricted, as is the match criteria. Given the nature of my employers business I would like to be able to use types and match criteria that have not been defined. My reading of the spec. shows that the accepted answer to that is to move the resource specification to a 'condition' element instead, but that simply begs the question of why a 'resource' element exists in the first place if a 'condition' element can achieve the exact same thing (or conversely, if a condition element can be extended, then why not a 'resource' element). I understand the desire to facilitate indexing, however moving a resource match to a condition makes it difficult, i fnot impossible, to deduce the role played by the arguments to the condition. This in turn makes it hard to automatically translate the XACML representation of a policy into a different representation (as might be necessary if the actual access control were being performed by a legacy system). CATEGORY: Alternative. STATUS: Discussed 11/25/02. RESPONSE: Accepted in general. Change A.12 [again] to allow non-standard functions and datatypes, so long as they return boolean and accept AttributeDesignator as first arg and AttributeValue as second. ACTION ITEM: #48. [Anne Anderson] re-word Section A.12 again. Say functions used "should" be easily indexable. Complicated functions or non-indexable functions will inhibit efficiency of evaluation. ACTIONS: -- Anne H. Anderson Email:
Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692 Attachment: AppendixA12-extfunc.doc Description: Appendix A.12 revised to accept non-standard functions