[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Draft BTG Profile
Hi Ludwig answers below On 24/11/2010 08:48, Ludwig Seitz wrote: > On Tue, 2010-11-23 at 17:06 +0000, David Chadwick wrote: >> Dear List >> >> about a year ago we discussed the standardisation of the Break The Glass >> response (see Seth Proctor's message of 17 Dec 2009) and decided that a >> profile to standardise the BTG response would be useful. Unfortunately >> Seth left Sun before we got around to writing it. >> >> Consequently Stijn Lievens and myself from Kent have produced a first >> version (attached) for your consideration. I know its not in the correct >> format yet, but we can fix that once the technical content has been agreed. >> >> Comments appreciated > > Hi David, > > I have some questions related to the proposed approach: > > 1.) You propose to introduce a new status code. Why not simply use > Advice instead? It seems a bit superfluous to add new elements to the > standard when there are suitable elements in the standard already. the whole purpose of standardising the status code is so that different implementations can interwork without having to find out what the status code or Advice element is that is being set by a particular PDP. > > 2.) You propose to introduce a new element called<Consequences>. Why > not use either Advice or Obligation with AttributeAssignments instead? We have used the syntax of Obligations, because this is what they are. But with one difference. They are future obligations that will come into effect if some future event happens. We did not want to call them obligations, since the semantic of these is quote "An operation specified in a policy or policy set that should be performed by the PEP in conjunction with the enforcement of an authorization decision" They are not to be enforced now along with the current authz decision, so semantically they cannot be called obligations. Consequences sounded like the correct semantic to apply to them. Advice is too weak. Advice can be ignored, whereas consequences cannot be. > > General question: > From the document you provided I cannot see the necessity for > introducing new elements into the standard. Could you try to explain > which functionality are you want to achieve that cannot be realized with > the existing features of the standard? 1. A standard way of specifying this response type. By its very nature it needs to be in the standard. 2. A standard way of indicating future obligations. > > A small nitpick: In 2.3 you write: "... and if the response is Grant it > will update the BTG state information ...". This should be "Permit" > instead of "Grant". > thanks, got it David > > /Ludwig > -- ***************************************************************** 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]