MHonArc v2.5.2 -->
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