[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] Non-standard functions and datatypes as MatchId functions
Hi Anne, First of all of the text need not be changed. I find it troublying that many things got changed here. Furthermore, there are no change bars, so I'm having difficulty seeing all that was changed in your proposed text. I think the only thing that is sought after here to address this issue is the relaxation of the functions that can be used for MatchId, which would mean merely removing the restrictions. That can easily be done by removing the following lines: 3497-3503 starting with "The XACML standard functions ...." And removing the last paragraphs after the last example in that section, lines: 3531-3542 starting with "For the match elements...". Cheers, -Polar On Mon, 25 Nov 2002, Anne Anderson wrote: > 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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC