OASIS eXtensible Access Control Markup Language (XACML) TC

Dear All from the in depth discussions we have had on the call today, I have listed the following issues and their current state of resolution 1. Should there be a BTG state attribute. Unanimously agreed by the call that there should be. 2. Should there be a standardised BTG response from the PDP (vs. user knows by magic that he can break the glass). Majority in favour of this but its not yet unanimous. 3. When the BTG action is granted, should there be either an obligation in the policy to set the BTG state vs. a special purpose application such as a Glass manager that knows it has to set the state. There is no agreement on this issue yet. 4. Should the BTG mechanism only use existing components in standard mode. This was agreed unanimously. 5. Can BTG be made into a more generic model (e.g. to include dynamic roles or alert status) rather than being specific to BTG. David proposed yes, if we replace BTG by the general concept of a third class of user who is entitled to override a Deny if he is willing to take the consequences, then we can remove all mention to BTG and call it Controlled Access Override 6. Should different mechanisms be used for inter organisational use case vs. intra organisational use case. David proposes this issue is out of scope of the discussion since it is not an issue addressed in general by XACML. 7. Should the standardised BTG response (if there is one) contain advice to the user which details the obligations that will be carried out if he decides to override the deny (so the user knows in advance what the outcomes of his override will be). General feeling that this is a good thing. 8. What are the dimensions of the state attribute and should it be standardised how these dimensions are specified? This issue was not discussed in the call today, but has been raised on the list. There seems to be general agreement that the state is multi-dimensional and based on attributes of the subject, action, resource and environment. I would propose that we address issue 5 first in more depth, since this concerns scoping of the work, and whether it is restricted to BTG or to a more general concept of there being some class of user (as specified in the policy) who is able to turn a deny into a grant. regards David -- ***************************************************************** 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.Chadwick@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 *****************************************************************

>
Original Message----- > From: David Chadwick [ mailto:d.w.chadwick@kent.ac.uk ] > Sent: Thursday, April 28, 2011 8:19 PM > To: xacml > Subject: [xacml] BTG issues > > 2. Should there be a standardised BTG response from the PDP (vs. user > knows by magic that he can break the glass). Majority in favour of this > but its not yet unanimous. +1 > 3. When the BTG action is granted, should there be either an obligation > in the policy to set the BTG state vs. a special purpose application > such as a Glass manager that knows it has to set the state. There is no > agreement on this issue yet. I prefer an obligation, since that doesn't require the introduction of yet another component into the architecture. The answer depends on issue 5 as well. If we generalize, does it still make sense to talk about a Glass Manager? > 5. Can BTG be made into a more generic model (e.g. to include dynamic > roles or alert status) rather than being specific to BTG. David > proposed > yes, if we replace BTG by the general concept of a third class of user > who is entitled to override a Deny if he is willing to take the > consequences, then we can remove all mention to BTG and call it > Controlled Access Override Does anyone have a use case other than BTG that would fit the generalization? > 6. Should different mechanisms be used for inter organisational use > case vs. intra organisational use case. David proposes this issue is out of > scope of the discussion since it is not an issue addressed in general > by XACML. I agree it is out of scope. > 7. Should the standardised BTG response (if there is one) contain advice > to the user which details the obligations that will be carried out if he > decides to override the deny (so the user knows in advance what the > outcomes of his override will be). General feeling that this is a good > thing. +1 > 8. What are the dimensions of the state attribute and should it be > standardised how these dimensions are specified? This issue was not > discussed in the call today, but has been raised on the list. There > seems to be general agreement that the state is multi-dimensional and > based on attributes of the subject, action, resource and environment. Does that mean that a doctor must BTG *for every bit of separate information* about a given patient while he's in a hurry trying to save that patient's life?

Hi Remon On 29/04/2011 07:29, remon.sinnema@emc.com wrote: >>
Original Message----- From: David Chadwick >> [ mailto:d.w.chadwick@kent.ac.uk ] Sent: Thursday, April 28, 2011 >> 8:19 PM To: xacml Subject: [xacml] BTG issues >> >> 2. Should there be a standardised BTG response from the PDP (vs. >> user knows by magic that he can break the glass). Majority in >> favour of this but its not yet unanimous. > > +1 > > >> 3. When the BTG action is granted, should there be either an >> obligation in the policy to set the BTG state vs. a special purpose >> application such as a Glass manager that knows it has to set the >> state. There is no agreement on this issue yet. > > I prefer an obligation, since that doesn't require the introduction > of yet another component into the architecture. The answer depends on > issue 5 as well. If we generalize, does it still make sense to talk > about a Glass Manager? > > >> 5. Can BTG be made into a more generic model (e.g. to include >> dynamic roles or alert status) rather than being specific to BTG. >> David proposed yes, if we replace BTG by the general concept of a >> third class of user who is entitled to override a Deny if he is >> willing to take the consequences, then we can remove all mention to >> BTG and call it Controlled Access Override > > Does anyone have a use case other than BTG that would fit the > generalization? How about this one. A police officer is investigating a crime and tries to access the personal information about a suspect. He is denied access to some of the details, but is given override permission if he can enter sufficient (free form) justification which will then be emailed to his superior officer and to the police data protection registrar. He knows that if they dont buy his argument, he will be reprimanded for breach of professional conduct. This is similar to a BTG access by a doctor in a hospital to a patient's medical records, but it does not use the same terminology as some people think this specifically refers to health IT systems. > > >> 6. Should different mechanisms be used for inter organisational >> use case vs. intra organisational use case. David proposes this >> issue is out of scope of the discussion since it is not an issue >> addressed in general by XACML. > > I agree it is out of scope. > > >> 7. Should the standardised BTG response (if there is one) contain >> advice to the user which details the obligations that will be >> carried out if he decides to override the deny (so the user knows >> in advance what the outcomes of his override will be). General >> feeling that this is a good thing. > > +1 > > >> 8. What are the dimensions of the state attribute and should it be >> standardised how these dimensions are specified? This issue was >> not discussed in the call today, but has been raised on the list. >> There seems to be general agreement that the state is >> multi-dimensional and based on attributes of the subject, action, >> resource and environment. > > Does that mean that a doctor must BTG *for every bit of separate > information* about a given patient while he's in a hurry trying to > save that patient's life? This all depends upon the policy. The BTG dimension could be at a very fine granularity so that every doctor has to personally break the glass for every item of information, or it could be at a very coarse granularity so that once one doctor breaks the glass for the database then the entire DB contents are available to all doctors. This is specified in the policy rules. e.g. for fine grained state if role=doctor and btgState[subject(ID),"field1,table1"]=true and resource=field1, table1 of DB then permit access where subject(ID) is a variable taken from the request context and ".." are fixed strings for coarse grained if role=doctor and btgState["doctor,DB"]=true and resource=DB then permit access P.s. I am not suggesting that this is the format that should be used :-) regards David > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > -- ***************************************************************** 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.Chadwick@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 *****************************************************************

Hi David, >
Original Message----- > From: David Chadwick [ mailto:d.w.chadwick@kent.ac.uk ] > Sent: Friday, April 29, 2011 12:36 PM > To: xacml@lists.oasis-open.org > Subject: Re: [xacml] BTG issues > [...] > > Does anyone have a use case other than BTG that would fit the > > generalization? > > How about this one. A police officer is investigating a crime and tries > to access the personal information about a suspect. He is denied access > to some of the details, but is given override permission if he can > enter sufficient (free form) justification which will then be emailed to his > superior officer and to the police data protection registrar. He knows > that if they dont buy his argument, he will be reprimanded for breach > of professional conduct. > > This is similar to a BTG access by a doctor in a hospital to a patient's > medical records, but it does not use the same terminology as some > people think this specifically refers to health IT systems. OK, now that you've demonstrated that there are more use cases like BTG, I think it makes sense to generalize. Unless anyone can think of a reason not to?