[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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]