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] 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