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

[Oleg Gryb <oleg_gryb@yahoo.com>]

Yoichi,

In your reasoning I don't really see a fundamental difference between "sign an agreement" and "show a reason of denial" obligations. In the latter case and in my example the "next step" for the user may be signing up a fee-based agreement for the bill payment service.

Yes, explaining the reason might or might not be complex, it might or might not have a practical sense, the user might or might not be interested in additional details. Does it mean in your opinion that such an explanation will never be useful?

I've described the business case that I think is generic enough and that provides enough motivations to have such a feature. As for me, obligations look like the right place to do that, but if it'll be implemented differently, I'll be OK with that too. The main thing is to have a possibility to use expressions for building a response/obligation/explanation or whatever you want to call it.



--- On Thu, 12/11/08, Yoichi Takayama <yoichi@melcoe.mq.edu.au> wrote:

> From: Yoichi Takayama <yoichi@melcoe.mq.edu.au>
> Subject: Re: [xacml-users] Help on Condition ? <-- Obligations
> To: "Bill Parducci" <bill@parducci.net>
> Cc: oleg@gryb.info, "Seth Proctor" <Seth.Proctor@sun.com>, xacml-users@lists.oasis-open.org, "Balaji Kannadassan" <balajika@nortel.com>
> Date: Thursday, December 11, 2008, 6:11 PM
> 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
> >