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] Boolean Policy resolution


>     A Combinator expression in which some, but not all of the
>     Predicates to which it applies evaluates to NOT-APPLICABLE is
>     evaluated as if the NOT-APPLICABLE Predicates were removed
>     from the Combinator expression.


kinda pulls the teeth from an AND clause, doesn't it?


>     The set of Combinators may be extended by [specifying a name
>     for the new Combinator, a URI that is associated with the
>     semantics of the new Combinator, and a type that specifies
>     the way the URI is to be interpreted.  Not all XACML PDPs
>     will be able to interpret all extensions, but any PDP that
>     can handle the specified type and can access the specified
>     URI can handle the specified extended Combinator.]


what is the behavior of the PDP if it cannot resolve the extension?


> Base Policy: the <xacml:applicablePolicy> element that specifies
>     the <xacml:policy> element that a PDP will use [by default]
>     to evaluate all Access Requests.
> 
>     [Alternative 1:
>     A PDP MAY have multiple Base Policies, but such Base Policies
>     SHOULD have non-overlapping <xacml:target> elements.  This
>     specification does not specify the order in which multiple
>     Base Policies are evaluated, or the result if two or more
>     Base Policies have overlapping <xacml:target> elements.
> 
>     Alternative 2:
>     Base Policies have restricted <target> elements that are
>     easily compared for overlap.  In this alternative, the case
>     where base policies overlap is an ERROR.  Note that the 0.8
>     syntax favors this alternative and allows Alternative 3.
> 
>     Alternative 3:
>     There is only one Base Policy and it has no <target> because
>     applies to all Resource or it has a <target> element that
>     completely specifies the set of resources which this PDP is
>     prepared to handle.]


it seems that in reality you are going to need to have #3 to provide 
resolution to conflicts arising from #1 whether it is called a base 
policy or PDP default policy, etc.


>     [A Base Policy for evaluating a particular Access Request may
>     be specified as part of the Access Request.  If a PDP has no
>     default Base Policy, then the result of evaluating an Access
>     Request that does not specify a Base Policy to use is FALSE
>     (deny access).]


i personally, believe that we cannot support interoperability without a 
default policy. anything that affects the outcome of a decision must be 
determinable and a default policy definitely falls into that category.

b



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


Powered by eList eXpress LLC