OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

Re: [xacml] IIC012: syntax-error or processing-error?

  • 1.  Re: [xacml] IIC012: syntax-error or processing-error?

    Posted 12-04-2002 11:57
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

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


    Subject: Re: [xacml] IIC012: syntax-error or processing-error?


    On Wed, 4 Dec 2002, bill parducci wrote:
    
    > Daniel Engovatov wrote:
    > > I would think it is the syntax-error.  There is nothing wrong about
    > > reporting an incorrectly formed policy and nothing sacred about type
    > > incorrectness.  This is what status codes are for.
    >
    > this is my thinking as well.
    >
    > it seems to me that this conversation ties back into the 'run-time' type
    > checking discussion: on the one hand polar seems to be saying that he
    > will have determined policy malformedness prior to the decision
    > processs, while anne & seth are talking about those cases whereby a
    > problem is discovered during the decision process.
    >
    > if this is true, then in the former case--polar's scenario--the
    > situation of having a problem processing a policy would only likely be
    > the result of some internal misfiring (PAP/PRP <--> PDP
    > miscommunication, etc.) and i would think that this would most assuredly
    > warrant an error code of some sort with an INDETERMINATE decision. the
    > case of the policy being written properly would not occur, so the
    > response in that case is moot.
    
    This case I believe is covered by the combining algorithms specification.
    
    > the latter case--anne & seth's--could arise under similar circumstances
    > as well as by run-time checking issues (poorly written policies). as
    > pointed out in this thread this would warrant an INDETERMINATE result
    > with an error code.
    
    Again, covered by the combining algorithms.
    
    > in both cases i think that the decision is clearly *not* NOTAPPLICABLE
    > because the decision making process has begun using a policy that is
    > undigestible (or in the case of polar's case, attempting to evaluate a
    > policy that has be rendered inoperable by some unplanned event).
    
    If that policy is being dynamically retrived, then you are in effect
    covered by the combining algorithms specification, and none of our
    standard ones say it's Not-APplicable. However, that doesn't stop you from
    defining your own that does.
    
    > otherwise, how does the PDP differentiate between a happily functioning
    > system and one that has, say acess control rights, network issues, etc.
    > with the policy repository?
    
    For the case when you have a single malformed policy to be evaluated
    against a request, the answer is just simply undefined. The implementer
    can choose. Therefore, there should not be a "CONFORMANCE" test for it.
    
    
    > b
    >
    >
    > >
    > > Does your language interpreter or compiler just die in silence if there is a
    > > typo in the code?
    > >
    > >
    > > D;
    > >
    > >