OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

RE: [xacml] Validity periods in SAML Assertions

  • 1.  RE: [xacml] Validity periods in SAML Assertions

    Posted 08-05-2004 18:19
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

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


    Subject: RE: [xacml] Validity periods in SAML Assertions


    >If the result of a rule can have no effect on the evaluation
    >result, regardless of the inputs to the rule, why is the rule
    >being evaluated?
    
    Because its condition may evaluate to false, or "X-override"
    recombination algorithm may ignore it.  Or policy may be written to use
    INTERDERMINATE value for decision making.  It may grant a permit when
    some attribute expires. Or an expired attribute value may represent an
    empty bag.
    
    >Likewise, if the value of some Attribute can have no effect on
    >the evaluation result, why is the constraint that uses the
    >Attribute even present?
    
    Because it may have no effect on a concrete result, but may have it on
    some other result.
    
    >I think both those cases are errors on the part of the policy
    >creation tool.
    
    I think both are very typical use cases.  Context most typically will
    contain more data that is necessary for a concrete decision.
    
    >So, just as with computing Obligations, I think we could say that
    >the validity period of the XACMLAuthzDecision Assertion SHOULD
    >correspond to the intersection of the validity periods of all
    >Assertions that were actually used during the evaluation,
    >regardless of whether their current values made a difference or
    >not.
    
    This will lead to unpredictable decisions.  There is no easy way to tell
    what attributes will be used - as recombination algorithm may short
    circuit evaluation in various ways.
    XACML guarantees a deterministic result given a static set of inputs.
    That's it: determining how the output of the policy will change in time
    is not generally possible by just looking at a subset of context:
    attribute assertions in this case.
    
    >But my question was, what criteria will the context handler use
    >to decide that an attribute assertion is invalid?  Will it be the
    >current-dateTime in the Request or the current time at the PDP?
    >My proposal was to use the latter.
    
    That I agree with.  I completely agree with the first part of your
    proposal.
    I just do not think that we should get into business of computing
    intersections etc.  Decision is a decision as it was computed.  It
    should be left to implementation do determine how this decision will be
    used - we just have no chance to reasonably cover all possible cases.
    


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