[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] BTG issues
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 *****************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]