-----Original Message----- From: xacml-return-2280-martin.smith=dhs....@lists.oasis-open.org [mailto:xacml-return-2280-martin.smith=dhs....@lists.oasis-open.org] On Behalf Of David Chadwick Sent: Monday, November 29, 2010 7:21 AM To: Rich.Levinson Cc: Ludwig Seitz; xacml Subject: Re: [xacml] Draft BTG Profile

Hi Rich

On 28/11/2010 20:41, Rich.Levinson wrote:

and state information. It is important to bear in mind which element is updating the BTG state (or attribute).

If the PDP understands that BTG is a special attribute (or state variable) then it can act in a special way when it is mentioned.

If the PDP does not understand BTG then no changes are needed to the XACML specification (scenario iii) below).

There are 3 scenarios, namely

1) PDP understands BTG and keeps the BTG state ii) PDP understands BTG but does not keep the state iii) PDP does not understand BTG

I believe that your description below is addressing scenario ii) only (correct me if I am wrong)

but

Rather I would say that these obligations are future obligations that the PEP must enforce if the user decides to BTG. If the user does not BTG, then no obligation enforcement is necessary. But if the user does BTG, then the state has to be changed by the PEP, and it is the changing

of the state that requires these obligations to be enforced. If they cannot be enforced the state should not be changed. E.g. If the obligation says to log this and email the manager, and the PEP is not able to do this, then the glass should not be broken, since no-one can be informed about it and the user will not have any explaining to do later. (Note that in our design we have the concept of Fallback obligations which are to be performed if the primary obligations cannot be, in order to try to address this issue, but this is a second level issue to the current problem.)

This is a very interesting take on the scenario. What you are suggesting

here is that the BTG obligations should only be enforced when the user actually exits the hotel through the firedoor. What I am suggesting above is that the obligations are enforced when the user breaks the glass, regardless of whether he decides to subsequently exit the hotel or not. This is an interesting conceptual point that should be discussed

further, because clearly it effects which obligations should be enforced

when. It also effects how many times the obligations are enforced. In your scenario they are enforced for everyone who subsequently leaves the

hotel by the firedoor, in my scenario they are only enforced on the person who breaks the glass. This again is an interesting conceptual point. If I exit a hotel via an open fire door, should I have to explain

this later to someone. If I view a patient record, which is for say a VIP and someone has previously broken the glass for me, should I have to

explain this later. If I break the glass on a VIP record but I do not actually view the record, should I have to explain this later to someone?

You are most probably correct. The reason I proposed Consequences in our

draft instead of Obligations, was that they were future obligations on a

subsequent action rather than the current one, whereas with your model above there is no need for future actions since you perform the obligations each time the user accesses the resource and not when the user breaks the glass.

regards

david

XACML.

***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security School of Computing, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W....@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5