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

On 26/11/2010 08:32, Ludwig Seitz wrote:
> On Thu, 2010-11-25 at 17:05 +0000, David Chadwick wrote:
>> Hi Ludwig
>>
>> The model you have appears to be that each user must BTG himself, and
>> then he is given the BTG attribute after agreeing to this. But this is
>> not the model we have, and it is not the model of BTG in general (e.g. a
>> fire door in a hotel).
>
> You claim your model represents the model of BTG in general. Can you
> support these claims?

Yes in so far as it has been implemented and we have not yet come across 
any BTG requirement that it cannot satisfy. So in that respect it is as 
general as the HL7 model (which is not a universal standard either)


>
> In a previous mail Mike Davis seems to suggest your model is different
> from HL7's requirements, and currently the requirements from HL7 are as
> close as it gets for "a model of BTG in general".
>
>> Our model is state based, ie. there is a BTG state that is initially
>> false (corresponding to unbroken glass) and can be set to true
>> (corresponding to broken glass) by a defined class of user in the policy.
>>
>> Another class of user (typically a manager) can reset the state to false
>> (ie repair the glass).
>
> I see no difference between a BTG state and a BTG attribute. Could you
> please explain where you see a difference?

Clearly none if the attribute holds the state!
But in your attribute model you did not say how the attribute value was 
set to different values. This was added in our model.


>
>> this model is much more general and flexible since it can be applied to
>> individuals (as in your case) or to roles (e.g. doctors) or to any
>> combination of attribute holding subjects.
>>
>> Furthermore the glass state
>> can be applied to a single resource or a group of resources. To a single
>> action or a group of actions. You can find details in last years ACSAC
>> conference
>>
>
> I'm all in favor of a flexible BTG model, but from what you present here
> I fail to see how that cannot be done within the current XACML (v3) core
> standard.

This is not the issue. The issue is, can we have a standard defined way 
of doing it. You suggest using Advice to signal BTG, so I say we should 
have a profile to standardise the contents of the BTG Advice. But I also 
request a standard way of doing it in XACMLv2 as well, and Advice cannot 
do that.


> There is absolutely no requirement for a BTG attribute to be associated
> with a specific subject or resource. What this comes down to, is a
> question of attribute management, and that's outside the scope of XACML.

Actually it is in a twilight world, since you have PIPs which manage 
attributes, but you dont describe how they work. So you sort of 
acknowledge that attribute management is needed, but then dont say how 
to do it. What we are wanting to do, is for a specific type of access 
control - BTG - is allow the XACML infrastructure (context handler, 
PIPs, obligation service etc) to manage the BTG attribute/state so that 
applications dont need to. But in order to do this we need to 
standardise more of the protocol between the PEP and the XACML 
infrastructure so that BTG can be handled by the infrastructure, thereby 
reducing the load on applications.

> (note that I think BTG profile should nevertheless give recommendations
> about how to do that).
>

which is what we tried to do in a general way in the draft profile.


> My point remains: You seem to derive the necessity to make changes to
> the core standard from your BTG model. I am not convinced they are
> necessary to realize your BTG model.

Clearly no changes are needed to XACML if you dump all the work on the 
PEP and the application. This is the status quo today. What we would 
like to achieve is that the application independent code can take some 
of the burden off the PEP. This is the motivation for the profile.

>
> There is a more important problem though: Before coming up with
> solutions for BTG, we need a good definition of what the requirements
> for BTG really are. Right now we are starting with a solution and are
> trying to make the requirements fit, and that seems like a bad approach
> to me.

If you care to read our ACSAC paper you will find a set of requirement 
there which were derived from the hospital. So we started with a set of 
requirements and derived an application independent way of satisfying them.

regards

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]