OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

Re: [xacml] Non-standard functions and datatypes as MatchId functions

  • 1.  Re: [xacml] Non-standard functions and datatypes as MatchId functions

    Posted 11-26-2002 15:19
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    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