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] 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,

3531-3542 starting with "For the match elements...".


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.
> --
> 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