[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HRAC decision object locality constrained?



Konstantin,

I think you contradicted yourself! WRT QoP let me juxtapose a couple of
your comment without (I hope) bashing context:

>there is no intent to use ADO as "QoP policy enforcer." ...
>A simple rule could be like this ".... if QoP >= Confidentiality"
>For such a rule, ADO's decision logic will look at the QoP and make decision
>accordingly.

What you call "making a decision accordingly" is exactly what I mean by
enforcing a policy. Your ADO wants information about the level/kind of
protection (e.g. is it confidential) in order to decide if that meets the
access requirement for *quality* of protection. If not (e.g. conf is
required but there isn't any for this request) then your ADO would reject a
request, right? The QoP *policy* is the set of rules about when you should
or should't honor a request based on the level of protection it is. This
kind of policy is very different from the "what level of protection will I
use here," it is more like "did the other party use the right level of
protection for my needs?"

Sooooo, I think that you ADO seems to be enforcing QoP policy. And coupling
a general kind of policy like QoP with some policies that meet more
specialized needs, well, it seems unneeded. Not necessaily unwise or
impractical, just not actually needful. 

My opinion that QoP is its own distinct area, should be dealt with as such,
and in the ideal secure ORB of the future it would be possible to add (when
needed) a QoP policy enforcer as another one in a series of policy
enforcers that must rule on a request.

I'd be interested to hear supporting or opposing views.

EJS
===
----------------
Broadcast message to hrac-rfp from John Sebes <ejs@tis.com>.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.