p.s.
I forgot to say that, as Seth was saying, someone creating a dynamic
show-deny-reason Obligation which forces the user agent to present an
artifact to the end user (which states the reason why access was
denied). This is perfectly legitimate.
I considered something similar in the past. The current Decision is
Yes or No, and I did not think that it was easy to compose some useful
Policy explanation for the end user as to why the access was denied.
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:
> For additional commands, e-mail:
>
