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] Proposed semantics for operations involving INDETERMI NATE



On Tue, 23 Jul 2002, Daniel Engovatov wrote:

> To the end of allowing to communicate "Not available" from "Not
> applicable"

The result is "Indeterminate", which fits both of those cases.

> That is a result of policy evaluation - three distinct.
> pricipally different outcomes: decision/no applicable rules/could not
> evaluate. You may do at the external protocol layer. I suggest we
> provide standard way of doing that between PDP and PEP, not just leave
> it hanging.

I disagree. We currently have three values, and we have argued about this
before, and I'd rather not rehash old news to take it all the way back and
then back around to the point where we are now.

There are three response values from a policy evaluation, Permit, Deny,
Indeterminate. We do allow Advice for Indeterminate.

> >let's
> >assume that there is a throw deep within the bowels of some external
> >function during policy evaluation. what is the PEP supposed to do with
> >that information?
>
> What's it is supposed to do with GRANT? Or DENY?

The results are "Permit" and "Deny". The PEP asks for an Access Decision.
In a system where it makes sense, the PEP will have some resource to
secure, some entity possibly wishing to access it, and the PEP will form
in a protocol of its choosing a request to the PDP giving the resource id,
the subject information, any other assertions it cares to give the PDP
that is relavent to the access descision query. The PDP merely returns an
response, which is conveyed in the protocol consistent with the request.
The PEP interprets that response.

> Whatever is appropriate in a concrete application - that's not part of
> policy discription and policy query protocols.  We may state that PEP
> may treat ERROR==UNDETERMINATE by default, but not providing a way to
> convey this fundamentally different state in the response is not
> helpful in my opinion.

We are defining the policy, not the exact PEP<->PDP exchanges in the
strict sense. That is too complicated for this work right now, as
architectures may vary. We are looking for specification and consistent
evaluation of a single composed policy.

> You will have exceptions. That's a fact.  In one form or another.

Exceptions should be caught at appropriate places and handled accordingly
to the semantics of the entity with in the architecture.  We are not
definiting a General Purpose programming language.

The PDP should catch all of its operational glitches and return a proper
PDP result accordingly. The Indeterminate response may contain some Advice
that may convey some information in that regard.

-Polar

> Not having a clear strategy what to do with this will not make it more
> robust or secure.
>
> Daniel.
>
>
>
>



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


Powered by eList eXpress LLC