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,

I guess my only objection is that the paragraph stating what a Matching
element actually is, has been removed completely, and replaced with an
anontomical description of its structure. The other thing that puzzles me
is the term "authorization request attribute".

I would like the following sentence put back (modified for
erudicating "EnvironmentMatch") underneath the bulleted list:

These elements represent boolean expressions over attributes of the
subject, resource, action, respectively.

Then tack the anatomical description onto that, but fix it to mention the
value so we have:

These matching elements represent boolean expressions over attributes of
the subject, resource, action, respectively. A matching element contains a
MatchId attribute that specifies the fucntion to be used in pergorming the
match evaluation, an <AttributeDesignator> or <AttributeSelector> elements
that specifies an authorization request attribute, and an attribute value
that SHALL match the value of the specified authorization request
     ^^^^^       ^^^^^^^^^^^^
attribute.

Q: Do we have "authorization request attribute" defined?

Also, if are now allowing *any* binary boolean function to be used, we
should probably get rid of the paragraph that lists the XACML standard
functions that may be used an a MatchId attribute value.

Cheers,
-Polar


On Tue, 26 Nov 2002, Anne Anderson wrote:

> On 25 November, Polar Humenn writes: Re: [xacml] Non-standard functions and datatypes as MatchId functions
>  > 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...".
>
> Polar,
>
> My guess is that you are comparing this rewording to the current
> text in the 1.0 specification.  We had already agreed to change
> the wording in response to Comments#5 and #12.  That wording is
> attached to
> http://lists.oasis-open.org/archives/xacml/200211/msg00157.html
>
> The changes I to that already approved re-wording are only:
>
> 1. Removed "standard XACML" from following sentence:
>
>  The MatchId attribute SHALL specify a function that compares two
>                                         ^removed: standard XACML
>
> 2. Changed paragraph following the list of XACML standard
> functions that may be used from:
>
> Functions that are strictly within an extension to XACML SHALL
> NOT appear as a value for the MatchId attribute.  Restricting the
> MatchId attribute to XACML standard functions facilitates the use
> of indexing to find the applicable policy for a particular
> authorization request.
>
> Changed to:
>
> Functions that are strictly within an extension to XACML MAY
> appear as a value for the MatchId attribute, and those functions
> MAY use data types that are also extensions.  The function used
> as the value for the MatchId attribute SHOULD  be easily
> indexable.  Use of non-indexable or complex functions may prevent
> efficient evaluation of authorization decision requests.
>
> 3. Added to the very end of the section, in response to your
> comment yesterday that you did not want the example of how to
> state a Match function as an equivalent Apply function to be
> taken as normative:
>
>   This expression of the semantics is NOT normative.
>
> Do you still have objections?
>
> Anne
> --
> 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
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>



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


Powered by eList eXpress LLC