OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: Re: [xacml] Discussion summary and revised post-condition proposal


while i understand the logic in principle, in this specific case i 
suggested that it is a deny because of the tag '<All-must-permit>'. this 
is quite specific ('all' clearly do not permit). if it were an <and>, 
then i would agree with carlise's outcome.

b

Michiharu Kudoh wrote:
> I think the original question from Polar leads two arguments:  "how to
> compute obligation(s) in the composed policy?" and "how to determine the
> permission in the composed policy?". For the first argument, I think that
> responses from both Carlisle and Bill show the reasonable semantics. The
> difference is related to the interpretation of <All-must-permit> predicate
> and "Indeterminate". I think this is the issue of the second argument. I am
> not sure how we should determine the permission that has Indeterminate even
> in the case no obligations are used.
> 
> I am not sure whether this helps our discussion, SAML defines the semantics
> of <Condition> element as follows:
> 
> -If any condition evaluates to Invalid, the assertion status is Invalid.
> -If no condition evaluates to Invalid and one or more conditions evaluate
> to Indeterminate, the assertion status is Indeterminate.
> -If no conditions are supplied or all the specified conditions evaluate to
> Valid, the assertion status is Valid.
> 
> Condition uses a set of values Valid, Invalid, and Indeterminate, and it
> seems to give those values a priority like Invalid > Indeterminate > Valid.
> If we translate Valid->Permit and Invalid->Deny, then the answer of Policy
> C becomes equivalent to Carlisle's idea.
> 
> Michiharu
> 
> IBM Tokyo Research Laboratory, Internet Technology
> Tel. +81 (46) 215-4642   Fax +81 (46) 273-7428
> 
> 
> 
> From: Carlisle Adams <carlisle.adams@entrust.com> on 2002/02/22 06:42
> 
> To:   "'bill parducci'" <bill@parducci.net>
> cc:   XACML TC <xacml@lists.oasis-open.org>
> Subject:  RE: [xacml] Discussion summary and revised post-condition proposa
>       l
> 
> 
> 
> 
> 
> Hi Bill,
> 
> I suppose it could go either way, but my feeling was that if the PDP
> couldn't get an answer regarding Policy A, then it couldn't give an answer
> regarding Policy C.  If more information was available, or if some server
> somewhere wasn't down, or whatever, the PDP would be able to evaluate
> Policy A and Policy B and return a Permit/Deny answer.  As it is, however,
> it has to return indeterminate because it just doesn't know.
> 
> I can see the argument saying that "All-must-permit" means "if you get
> anything other than permit, you must deny".  I could certainly live with
> that interpretation if others prefer it.  This comes back to defining the
> 3- or 4-valued logic for each of our combinators since, at least in our
> current syntax, the combinator is likely to be <and> rather than
> <All-must-permit>...
> 
> Carlisle.
> 
>    ----------
>    From:   bill parducci[SMTP:bill@parducci.net]
>    Sent:   Thursday, February 21, 2002 4:25 PM
>    To:     XACML TC
>    Subject:        Re: [xacml] Discussion summary and revised
>    post-condition proposa       l
> 
>    Carlisle Adams wrote:
> 
>     > Hi,
>     >
>     > I've filled in the column for Policy C below.
> 
>    [...]
> 
>     >       Policy A      Policy B     Policy C
>     >       ------------------------------------
>     >       Permit        Permit                Permit:  P, R, and D
>     >       Permit        Deny                  Deny:  S, E
>     >       Permit        Indeterminate    Indeterminate:  no obligations
>     >       Deny          Permit                Deny:  Q, E
>     >       Deny          Deny                  Deny:  Q, S, E
>     >       Deny          Indeterminate    Deny:  Q, E
>     >       Indeterminate Permit                Indeterminate:  no
>    obligations
>     >       Indeterminate Deny                  Deny:  S, E
>     >       Indeterminate Indeterminate    Indeterminate:  no obligations
> 
>    curious as to how you arrived at these:
> 
>     >       Policy A      Policy B     Policy C
>     >       ------------------------------------
>     >       Permit        Indeterminate    Indeterminate:  no obligations
>     >       Indeterminate Permit           Indeterminate:  no obligations
>     >       Indeterminate Indeterminate    Indeterminate:  no obligations
> 
>    given that policy C has this:
> 
>    >         <All-must-permit>
>    >               Policy-A
>    >               Policy-B
>    >         </all-must-permit>
> 
>    my read is that these would be resolved thus:
> 
>            Policy A      Policy B     Policy C
>            ------------------------------------
>            Permit        Indeterminate    Deny: E
>            Indeterminate Permit           Deny: E
>            Indeterminate Indeterminate    Deny: E
> 
>    b
> 
>    p.s. great example, polar!
> 
>    ----------------------------------------------------------------
>    To subscribe or unsubscribe from this elist use the subscription
>    manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> 
> 
> 
> 
> 
> ----------------------------------------------------------------
> 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