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 proposa l


yes, i agree. i think that this is the only way we will be able to 
effectively define policy scope (the whole 'applicability' thing: the 
former example) and rule evaluation (the latter) in a single schema. i 
had try to propose something similar a while back, but not so well 
thought out (the 'join' vs. 'add' proposal). the trick now is to be able 
to convert this into english :o)

b

Polar Humenn wrote:
> Hi  Bill,
> 
> I think taking a singular evaluation strategy will not work. You need many
> different combinators to get what you want, and we can make some of them
> standard.
> 
> The first and foremost rule/policy combinator I see, is the first
> determinate decision combinator, which is the easiest to evaluate and the
> most intuitive, given the worlds familarity with imperative programming.
> The rules have order, and are listed in order of preference, giving
> implementers the familiar if-then-else-if-then-else-if... strategy.
> 
> take-first-decision-and-obligations
>     Takes the first Permit or Deny decision the specified order.
>     Which means for the Combinator T consisting of Policies
>      P1,...,Pn, this combinator T(S,A,R) (where
>            S=subject,A=action,R=resource) returns
> 
>     Indeterminate if all Pi evaluates to Indeterminate for all i, 1<=i<=n.
>     OR,
>     Permit with Qk obligations,
>         where Pi(S,A,R) evaluates to Indeterminate for all i, 1<=i<k<=n,
>              and Pk(S,A,R) evaluates to Permit with Qk obligations,
>              and k<j
>     OR,
>     Deny with Dj obligations,
>         where Pi(S,A,R) evaluates to Indeterminate for all i, 1<=i<j<=n,
>              and Pj(S,A,R) evaluates to Deny with Dj obligations
>              and j<k.
> 
>     I.e. the rule evaluates to either
> 
>     Permit with Qk obligations
>     Deny with   Dj obligations
>     Indeterminate.
> 
>     This strategy has the effect of only evaluating the needed policies.
>     Other combinators I fear require evaluating all policies, which
>     is okay, but you have to want it.
> 
> The only combinator I see much use for is the following, which is the
> one Bill keeps on about. (All policies must return Permit, (no Denies,
> no Indeterminates).
> 
> all-must-permit
>     MUST evaluate *all* policies regardless.
> 
>     If all rules evaluate to Permit gather all their
>     obligations for Permit, but if one rule emits a Indeterminate
>     or a Deny, only the Deny obligations are gathered.
> 
>     For a set of policies P1,...,Pn, this combinator, C(S,A,R) results in
> 
>     Permit with J obligations
>      if for all Pi(S,A,R) evaluates to Permit
>       where
>         J = { Qi | Pi(S,A,R) evaluates to Permit with Qi obligations,
>                    for all 1<=i<=n }
>     or,
> 
>     Deny with K obligations
>       if *any* Pi(S,A,R) evaluates to
>            Deny with Di obligations or
>            Indeterminate
>        where
>         K = { Di | Pi(S,A,R) evaluates to onDeny with Di obligations,
>                    for all 1<=i<=n }
> 
> 
> Note, any combinator we invent MUST only evaluate to Permit with Q
> obligations or Deny with D obligations.
> 
> Cheers,
> -Polar
> 




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


Powered by eList eXpress LLC