[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xacml] 7.7 Obligations
It seems to me that obligation is really a specific decision, thus should be part of the rule/policy recombination algorithm. The fact that its analysis may/must happen on the PEP side is just a nuisance. When obligations are used we have five different evaluation outcomes PERMIT, DENY, INDETERMINATE, NONAPPLICABLE and PERMIT WITH OBLIGATION. We should not mandate what to do with it - just like we do not mandate how to implement all recombination algorithms, but just state that this outcome must be recognized by a system that implements obligations. Daniel;; -----Original Message----- From: Polar Humenn [mailto:polar@syr.edu] Sent: Monday, October 07, 2002 12:51 PM To: bill parducci Cc: 'XACML TC ' Subject: Re: [xacml] 7.7 Obligations On Mon, 7 Oct 2002, bill parducci wrote: > that would be a contradiction to the decision made by the group some > months ago, and for good reason in my mind: if nothing can be assumed > about the intended use of the azn results, there is little hope of > reproducible access control. Decision or no decision, how does it make sense? What is a PEP? We know what a PDP is. It takes a well formed input and evaluates it against a well formed policy and yields a well formed result semantically consistent with the input and policy. There is a notion of conformity and compliance. Furthermore that compliances is based on mathematic principles. A PEP is merely a point in some application somewhere, that may or may not even call on a PDP, PRP, or a PIP. So, how can you place any coformance requirements on it? Are you going to call an application PEP compliant? Who would care? If you want to have compliance points based on obligations, they should be placed on the component we are defining, the PDP, to give you the correct decision. If the intended behavior is to deny access for non-understandable obligcations, perhaps, we should say that the PDP should be configured with "understandable" obligations, and to answer Deny if a decision of Permit comes up with any obligations not in the "understandable" set. Alternatively, we can put "understandable" obligations in the RequestContext, and the evaluation depends on those "understandable" obligations in the same manner. Cheers, -Polar > this is position also consistent with the solving the functionality > introduced in the original use case submitted by michiharu. > > b > > Polar Humenn wrote: > > > It appears to me that this document merely describes a language, such that > > when a formula of the language is well formed, when evaluated against a > > specific valid input, yields a consistent result. > > > > What the PEP does with that result is up to the PEP. This advice should be > > non-normative. The normative part should only outline the specific manner > > in which obligations are collected in a particular way, according to the > > language, and delivered in the result. > > > > Cheers, > > -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