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: [xacml] Non-standard functions and datatypes as MatchId functions


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



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


Powered by eList eXpress LLC