OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

Re: [xacml] xacml, policy, issuer, combinator parameters...

  • 1.  Re: [xacml] xacml, policy, issuer, combinator parameters...

    Posted 07-19-2004 23:05
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

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


    Subject: Re: [xacml] xacml, policy, issuer, combinator parameters...


    On Mon, 19 Jul 2004, Frank Siebenlist wrote:
    
    > I simply don't understand why you even want to have a discussion of how
    > a policy "written" by polar becomes "mine".
    
    because it happens all the time.
    
    And given the element, it just makes that sort of thing possible, possibly
    leading to ambigous behavior.
    
    > The reduction: polar *says*
    > A & frank *believes* polar => frank *says* A...  is at the heart of the
    > proposed scheme....
    
    True, the logic of Abadi, Burrows, Lampson, and Wobber, the following is
    valid in all applicable models:
    
    Polar says A
    Frank believes (speaks for) Polar
    
    then
    
    Frank says A
    
    However, we must be really careful about this.
    
    First and foremost, if you have a policy that states "Polar says A", then
    who said that statement? This policy may be a lie. Furthermore, you may
    not even know who Polar is.
    
    So, the fact that Frank *believes* Polar
    
    has no real effect if indeed, Carol says (Polar says A).
    
    So, the question is not that Frank *believes* Polar. It may be one of,
    does Frank *believe* that somebody else says Polar says A.
    
    it gets complicated, but we can work through it.
    
    My point, is that if you put that <Issuer> in the policy, the policy no
    longer just states who has access, but now states somebody else says who
    has access, and there is a complicated question if that should be
    believed, and where it should be believed.
    
    Putting the "issuer" as a combining parameter associated with a
    particular policy states to the combingin algorithm that "this issuer"
    states that "this policy" says who has access. and in the context of "this
    combining algorithm" we have a mechanism for discovering and validating
    the authority chain.
    
    If <Issuer> is to exist within a policy, what does it mean?
    What does it mean in the context of a combining algorithm
    Furthermore, the real question that must be answered, must be
    What does an <Issuer> element mean for *all* combining algorithms?
    
    Cheers,
    -Polar
    
    
    
    
    


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