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


I agree with Michiharu
Simon

----- Original Message -----
From: "Michiharu Kudoh" <KUDO@jp.ibm.com>
To: "'XACML TC '" <xacml@lists.oasis-open.org>
Sent: Wednesday, October 09, 2002 4:24 AM
Subject: RE: [xacml] 7.7 Obligations


> Based on the discussion on the list,
> - Bill and I are in agreement.
> - Daniel seems to be uncomfortable with an authorization decision like
DENY
> with obligation(s).
> - Polar seems suggesting to include understandable obligations in the
> request context to avoid emitting no-understandable obligations to PEP
from
> PDP.
>
> My opinion is that DENY with obligation (e.g. deny provided access must be
> logged) is still useful for some applications e.g. security policy for a
> firewall server and an authentication server. For example, "DENY with
> notify-admin" means that the access is rejected but the notification of
the
> access must be sent to admin. The TC approved to include this long time
> ago.
>
> For the no-understandable obligations, the Polar's suggestion to include
> understandable obligations in request context might be one option. It
> definitely eliminates the case when the PEP receives non-understandable
> obligation from the PDP. But I have a slight concern. What if there are
> hundreds of obligations the PEP understands? Then I don't think it is an
> efficient way to mandate to include all the understandable obligations in
> each access request because it may make access request very large, even if
> such information is irrelevant to many access requests. Another way would
> be to create a communication protocol between PDP and PEP to exchange a
> list of understandable obligations, but it seems outside the scope of
> XACML. XACML should focus on what decision must be generated in response
to
> what decision request. Therefore,  I would prefer my original definition
> that includes the case when the PEP does not understand the obligation.
>
> Michiharu Kudo
>
> IBM Tokyo Research Laboratory, Internet Technology
> Tel. +81 (46) 215-4642   Fax +81 (46) 273-7428
>
>
>
>
>
> ----------------------------------------------------------------
> 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