OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

RE: [xacml] Change request: separating round, abs,floor and othe r function.

  • 1.  RE: [xacml] Change request: separating round, abs,floor and othe r function.

    Posted 08-22-2002 14:25
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

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


    Subject: RE: [xacml] Change request: separating round, abs,floor and othe r function.


    On Thu, 22 Aug 2002, Daniel Engovatov wrote:
    
    >
    > >to make sure that the result is a singleton. That is inforced by the rule
    > >logic, and not by ERROR at the time of evaluation.
    >
    > I would have to disagree that this is important enough to intriduce
    > such additional complexity.
    
    It's actually simpliciticy.
    
    > We agreed that we have to handle errors in evaluation anyway (not just
    > invalid sequence length, but invalid syntax, division by zero, or
    > whatever else an extension function may require to be communicated as
    > "unable to compute" state)
    
    "handle" errors when they are unavoidable, such as divide by zero. It's
    another thing to write policies depending on them.
    
    > While we can enforce such limited type safety for standard functions - in
    > the way you described
    > - it may not be possible to enforce for extension functions.
    
    I don't care about extension functions. Once you've gone beyond the
    specified ones, the whole evaluation stragegy is up to you and you can do
    what ever you want.
    
    > As we have this mechanism in place - I do not think there is anything
    > wrong with using this for checking for correct sequence length - it
    > will not affect speed or security in any way.
    
    I don't want people writing policies relying on exceptional ERRORs.
    
    > XACML function can be interpreted INTERNALLY, within implementation,
    > to have such length enforcement logic - PAP can deal with that if
    > needed.
    
    I'm looking for a formal language that can be verified, typechecked, and
    reasoned about. No PDPs, no PAPs, no PEPs. Just language.
    
    > Daniel..
    >
    > ----------------------------------------------------------------
    > 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