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

[Yoichi Takayama <yoichi@melcoe.mq.edu.au>]

Hi,

I don't want Obligation to be used for informing the end users the
reason why something was denied. It has its own use.

I want to keep the Obligation to be used as a condition for Policy-
based decision making process.

However, this Obligation condition is different from what works on the
server side with PDP and other Policy elements (they are the "normal"
conditions).

This is a client side condition. For example, PDP has already ruled
that this user will be granted access and returned the results to the
user side. However, the Obligation says that the user must sign the
license agreement before it can proceed. Therefore, the Obligation
expresses something that the PDP, Policies and the server-side
variables alone may not determine.

Then, the XACML and Obligation compliant client must present the
license page to the end user and return the user agreeing or not to
the PDP side. Then, the all conditions are met and the user may
proceed to the next step.

An XACML system must allow this two-step permission process to work.

If someone wants to know the reason why some policy denied access as
the DPD Decision, in my opinion, there should be some additional
element with the Decision to explain what Policy denied access
(however, expressing such may become complex if that was a result of
combinations of policies - or it may not make a practical sense at all
to the end user if it was rejected by some seemingly unrelated matter).

Alternatively, the end user may ask "why" to get an additional answer?

Seth, I have not been following V3 development. Are there changes on
Obligations from that of V1 and 2? Also, are there good use cases for
the element? In your opinion, the Obligation is the place for the
policy decision reason to be attached? Isn't there some other better
place for such?

Thanks,
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 11/12/2008, at 11:11 AM, Bill Parducci wrote:

> There is a current proposal to create dynamic Obligations within V3.  
> We are just working through a discussion re: if Obligations should  
> handle the "decision advice" aspects or if we should have a specific  
> attribute for indicating why decision was made.
>
> b
>
> On Dec 11, 2008, at 9:42 AM, Oleg Gryb wrote:
>
>> In regards specific requirements, please do consider adding  
>> expressions to obligations as I and other people had suggested in  
>> the past. It would make the obligations more dynamic. Example: I  
>> want to return an error message: "The access to the bill pay  
>> service has been denied because you exceeded the total maximum of  
>> $10000 in 6-month period" where $10000 and 6-month are environment  
>> attributes. I didn't find a way of creating such an obligation  
>> within current spec.
>
>
> ---------------------------------------------------------------------
> 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