OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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


> /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]