OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml-users] Help on Condition ? <-- Obligations


Thanks, Seth and Bill.

As Rule or Status automatically generating some expressions as to why  
the Decision was Deny, as I said, it may be difficult for PEP to  
predict and use what may be meaningful, and decide what to do with it.  
With the same Policy (or Policy Set), sometimes it may be not used at  
all (if the e.g. Reason is trivial), used as information-only or to  
trigger some user actions. Policy writer and complying PEP must be  
very well aware of all the result combinations to consider to get it  
all right take advantage of this feature, although I admit, as a  
programmer, this may offer most comprehensive general-purpose  
mechanism to take advantage of.

Bill, I think that the difference between this and the Obligation may  
be that the Obligation MUST be complied otherwise the Action in the  
original Request should not be executed on the Resource, whereas  
Status (attached with Reason) may be up to the PEP to use or not  
(although in both cases, as you pointed out, how PEP handles it is  
pretty much implementation dependent) at this stage. Or, do we create  
Obligation message for the Status?

Also, the Obligation can be applied to only the final outcome of the  
Rules, that were logically combined, either Permit or Deny. Only two  
Obligations per Policy. (Obligation may be forwarded to upper Policy  
Set etc. So it is possible to have combined Obligations as a result  
from rather simple and well-defined Policy in terms of the number of  
Rules and the logic used). However, the Policy writer has to predict  
only two possible outcomes only to deal with possible Obligations per  
Policy. Of course, this prevents the Obligation to look into the  
Reason why the Decision was made, this may be sometime desired if the  
logical combinations of Rules to make the Decision is complex.

Yoichi
--------------------------------------------------------------------------
Yoichi Takayama, PhD
Senior Research Fellow
RAMP Project
MELCOE (Macquarie E-Learning Centre of Excellence)
MACQUARIE UNIVERSITY

Phone: +61 (0)2 9850 9073
Fax: +61 (0)2 9850 6527
www.mq.edu.au
www.melcoe.mq.edu.au/projects/RAMP/
--------------------------------------------------------------------------
MACQUARIE UNIVERSITY: CRICOS Provider No 00002J

This message is intended for the addressee named and may contain  
confidential information.  If you are not the intended recipient,  
please delete it and notify the sender. Views expressed in this  
message are those of the individual sender, and are not necessarily  
the views of Macquarie E-Learning Centre Of Excellence (MELCOE) or  
Macquarie University.

On 15/12/2008, at 11:35 AM, Oleg Gryb wrote:

> I would be OK with any solution that allows sending an expression in  
> a XACML response.
>
> The second thought is "Why would we need obligations at all if we  
> can send an arbitrary expression back?" What PEP should do with  
> Obligations is not clearly defined anyway (at least it's not in  
> normative sections). It means that obligation processing is very  
> much implementation-specific now. It will remain implementation- 
> specific if we use an arbitrary optional expression that can be sent  
> back by PDP and analyzed by PEP.
>
> What PEP is going to do with that is up to PEP. Where exactly we put  
> the expression does not seem very important to me.
>
>
>
>
> --- On Mon, 12/15/08, Seth Proctor <Seth.Proctor@sun.com> wrote:
>
>> From: Seth Proctor <Seth.Proctor@sun.com>
>> Subject: Re: [xacml-users] Help on Condition ? <-- Obligations
>> To: xacml-users@lists.oasis-open.org
>> Date: Monday, December 15, 2008, 2:18 PM
>> I've been holding back on this discussion because
>> I'm still somewhat unsure
>> what I think of the issue. Generally, I agree with what
>> Bill has suggested,
>> that the notion of an "Obligation" is really
>> different than what we want
>> for notification, and while it can be used here it's
>> further confusing an
>> already (in my opinion) complex feature. On the other hand,
>> I hate to
>> introduce a new mechanism at this point, or rush to push
>> Obligations into
>> Rules without fully understanding what the impact here
>> would be.
>>
>> I do very much believe that notification is a strong
>> use-case. With that
>> in mind, I wonder what others would think about using the
>> Status element
>> for this application. My experience is that Status
>> doesn't get used much,
>> since you can't include any detail except on
>> Indeterminate, and even
>> then there's no abaility for a policy writer to provide
>> status details.
>> What about allowing Detail with a Status of Deny, and
>> adding a new
>> attribute (or something) to Rule that let you define the
>> Detail? I'm
>> making this up as I go along, but it seems like it might
>> get us what
>> we want without having to invent anything too new or
>> confusing.
>>
>> Thoughts?
>>
>>
>> seth
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> xacml-users-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail:
>> xacml-users-help@lists.oasis-open.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-users-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-users-help@lists.oasis-open.org
>

smime.p7s



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]