[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xacml] 7.7 Obligations
On Wed, 9 Oct 2002, Daniel Engovatov wrote: > > >The PDP knows to send you a response with Permit with a obligation of > >http://www.overXeer.com/obligations/1. However, if the PDP evaluates the > >policy and it gets a Permit with http://www.adiron.com/obligations/45. > >What do you do? > > > The one little problem with this is that it matters very little > whether PDP understands what KIND of obligation it is OK to issue. The > only purpose of obligation existence is whether it can be FULFILLED. > Fulfilling an obligation is an essentially runtime action - so any > PEP/PDP communication protocol designed to affect the decision issued > based on applicability of an obligation will have to be a runtime > feedback protocol. Of the type: > "Here is PERMIT to enter, but sign up first" > "OK, but I forgot my name" > "Well, then DENY" Well, that is not the exact intention of obligations. The difference is sutble. They are not really a "provided that" or "unless", which I think we discussed many ions ago. That is because, you may have access to an object and an obligation to delete a file after 60 days. This kind of leads to a paradox about access. You gave access, but you find out in 59 days that you cannot delete the file. Oppps! So, we said that an application using a PDP, e.g. a PEP, must "understand" the obligation, which means it knows how to deal with the obligation identifer, which is about as best we can do. > Is there any value in such protocol? If you mean a feedback protocol like the one above, I would say "yes", but somehow think it might be too specific to the application as what questions get asked. > It would seem to me that it does not matter at all whether PDP knows > anything about obligations - it is just a result that has a meaning > known to the policy author and the policy consumer - it should not be > part of the standard.. The only part that should be part of the standard is a statement saying that policy author and the policy consumer need to have a common understanding of the meaning of the obligation. Just as the policy author and the policy consumer need to have the same interpreation of the words "Permit" and "Deny". > We should only worry whether it can be unambiguously computed. Brilliantly said. -Polar > Of course you do. If you are going to include those kind of obligations, > where do you think they are going to come from? They are just URIs. > > So, your obligation has a URI: > > http://www.overXeer.com/obligations/1 > > which states that "send with 128 bit encryption, *no* 56 bit > encryption". > > Your PEP sends a request > > <RequestContext> > <subject> > <resource> > <action> > <Understandable Obligations> > <Obligation> http://www.overXeer.com/obligations/1 </Obligation> > <Obligation> http://www.overXeer.com/obligations/2 </Obligation> > <Obligation> http://www.overXeer.com/obligations/3 </Obligation> > <Obligation> http://www.overXeer.com/obligations/4 </Obligation> > </Understanble Obligation> > </RequestContext> > > > The PDP knows to send you a response with Permit with a obligation of > http://www.overXeer.com/obligations/1. However, if the PDP evaluates the > policy and it gets a Permit with http://www.adiron.com/obligations/45. > > What do you do? > > You can easily make the PDP return Deny without knowing anything about > the > PEP. > > > > ---------------------------------------------------------------- > 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