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


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?

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?

> 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. 
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.
(note that I think BTG profile should nevertheless give recommendations
about how to do that).

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.

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.

/Ludwig



-- 
Ludwig Seitz, PhD             |   Axiomatics AB
Training & Development        |   Skeppsbron 40
Phone: +46 (0)760 44 22 91    |   SE-111 30 Stockholm
Mail: ludwig@axiomatics.com   |   Sweden

This is a digitally signed message part



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]