I have some reservations about David's BTG proposal, primarily because the semantics are not well specified, and because it muddies the distinction between what should happen within the XACML system, and what should happen outside of XACML. Obligations, as currently defined, require the PEP to take some action prior to executing or acting on the PDP's decision for a particular request. The proposed BTG obligation is entirely different: it says "you can't have access, but you can break the glass if you choose". We added Advice in XACML 3 to accommodate this sort of message-passing--messages which may or may not have anything to do with the original request or the decision. I don't think the TC should encourage the use of Obligations for anything other than what they are: an obligation to discharge certain actions regarding the PDP's decision. This is the only way to assure predictable system behavior--or to detect a faulty system. As we discussed on the last call, the scope and definition of "glass" should be specified. If not, we are just standardizing some features of the request/response protocol without knowing what effect these features have, either on the PDP or the PEP. Does the glass cover a specific request, a specific class of subjects, a class of resources, or what? Or is glass-condition just another attribute in the request context, whose effective meaning is given by the policy rules? However you define glass-condition, it will have to be implemented as a XACML attribute in the request context, or as some extra-xacml functionality. Either way, you are now using the XACML request mechanism to change the policy evaluation state directly. While this isn't prohibited by the standard, it makes it harder to reason about the behavior of the system. David's "BreakTheGlass" action-id is egregious in that it is not just a request for permission to do something (outside the XACML system)--it is a directive to change the state of the policy evaluation with regard to a particular (non-XACML) resource, subject, or action. Now, if state is maintained in PEP, you could say this is a normal request, but nevertheless it has muddied the distinction between requests for permission to do something (outside of XACML) and directives to do something "inside" of XACML. I would favor one of two alternative approaches (or some combination): 1. Simply return an Obligation (along with a Permit decision) if the requestor is authorized to "break the glass". The PEP would be obliged to display the list of consequences associated with accessing the resource, and the user could choose to accept the consequences and see the resource, or cancel the request. The consequences could include changing the state of the system to allow access to other resources, or allow other people to see the same resource, or whatever the business meaning of "break the glass" carries in a specific application. The obligations would be discharged outside the XACML system. (I'm not sure that this approach really warrants a standard profile, unless we just want to provide a distinguished obligation id value for BTG.) 2. Write policies specifically to allow "break-the-glass" actions to certain subjects in certain conditions. The PEP would request permission to break the glass, and if allowed would use some non-XACML mechanism to change the policy evaluation state. Obligations could be returned with the decision to advise user of the consequences. Then the application would request access to the desired resource. (Again I question whether this is worthy of standardization, unless we want to name a distinguished "break-the-glass" action id.) Either of these approaches would meet the BTG use case without altering the semantics or conventional usage of XACML. Regards, --Paul >
Original Message----- > From: David Chadwick [ mailto:d.w.chadwick@kent.ac.uk ] > Sent: Thursday, February 10, 2011 05:22 > To: xacml@lists.oasis-open.org > Subject: Re: [xacml] Proposed Agenda 10 February 2011 TC Meeting > > Dear All, > > in preparation for this evening's call, I attach a revised version of > the BTG profile for you consideration > > regards > > David > <snip>