Issues to make decisions about during the conference call

[Konstantin Beznosov <beznosov@baptisthealth.net>]

Hi,

I've put together a list of things we need to make decisions on according to
the recent e-mail exchange. Any one is welcome to add new items. Let's
priorities them as a first thing in the conference call:

A. PolicyEvaluatorAdmin

 Carol's description of the issue: This interface is problematic to describe
because it assumes something about the underlying access control system... it
assumes that the proprietary administrative interface allows policies to be
identifyable (in the current spec by name).  Some ACL based systems do not
name policy which makes this interface useless for the intended purpose.
In addition, it begs the question of how a healthcare software vendors product
would understand how to select an appropropriate policy from a list of named
policies provided by HRAC.

Carol's proposal: I would like to remove this interface from the initial
submission and revisit the entire subject of how to allow an application to
define the access policy for a dynamically created resource for the final
submission.

Konstantin's proposal: I suggest to leave it the way it is now and see what
other people (i.e. outside of the submission team) comment on it.



B. DynamicAttributeService get_dynamic_attributes()

Carol's description of the issue: This method takes a PolicyEvaluatorList as an
input parameter... however there are no  methods on PolicyEvaluator that make
sense for a DynamicAttributeService to call.  Since we agreed that
PolicyEvaluators are "replaceables" - they may be provided by different vendors
and implement different access policies, it isn't reasonable to expect that
hidden methods here would be very useful.  :-)   


Carol's proposal: I suggest we remove this parameter for the initial submission
and revisit the performance considerations that were the catalyst for providing
these refs to the DynamicAttributeService there after the initial submission. 

C. DynamicAttributeService

Carol's description of the issue: We agreed that the dynamic attribute service
would encapsulate any "callbacks" to the application when necessary.  This
would be for the purpose of determining how to create the new AttributeList
that includes the appropriate static and dynamic attributes to be passed to the
other HRAC evaluator objects.  We also agreed - I think - that
DynamicAttributeService  is a "singleton" object.  

Carol's proposal: I believe we need to consider providing a standard way that a
3rd party application vendor can register a dynamic attribute evaluator with
the DynamicAttributeService for a ResourceName.


Konstantin's proposal: It should be a part of admin interface on
DynamicAttributeService. I think we agreed to postpone specification of that
interface until the revised submission.

D. struct DecisionResult{}:

John's description of the issue: In the current draft, struct DecisionResult{}
contains PolicyName as opposed to PolicyEvaluator.

E. PolicyEvaluator::evaluate():

John's description of the issue: In the current draft,
PolicyEvaluator::evaluate() returns DecisionResult as opposed to Ternary
(defined as Trinary in Austin IDL)

F. Names of sequences types:

Konstantin's description of the issue: types that express mean "many" are
called in the submission in variety of ways: Multiple<X>, <X>List, <X>s. Where
<X> is the name of the type expressing one item (for example, PolicyName).

Carol's proposal: I propose we follow the pattern followed by Pids and Lexicon
and use XSeq (although this isn't my personal favorite). I suggest we also use
a little common sense and not typedef AttributeList to AttributeSeq, however
:-)

G. ResourceName in set_default_evaluator and set_default_combinator:

Konstantin's description of the issue: page 18, operations
set_default_evaluator and set_default_combinator: either both of them or none
should have parameter of type "ResourceName".


Carol's explanation: This isn't a typo, although it raises an issue I'd like to
discuss.  

The default combinator could be for all ResourceNames (the enterprise might
use a simple "ANY" combinator).  An apply_combinator for a resourcename
overrides the "system" default as there is only one for a ResourceName.
This avoids having to applying combinators for all ResourceNames
individually.  

PolicyEvalutors are different because there are many.  The way that Bob
described these methods working is that applying a default resets the
ResourceName to only have the single evaluator and then you have to apply
each of additional evaluators individually.  It is this  implied reset that
means you can't do a set_default_evaluator without specifing a
ResourceName.... or at least you need a set_default that specifies a
ResourceName.   Personally, I'd prefer to add a remove_evaluators or
reset_evaluators method and stop the overloading of functionality in the
methods (here and elsewhere).... we should discuss... but as written, this
isn't a typo.


H. names of operation parameters

Konstantin's description of the issue: Through out the IDL: sometimes
parameters of operations are named with full names like "requested_access" and
some times in cryptic names like "rname". I suggest to use full names to name
operation parameters. This comment is very optional.

Carol's explanation: Again, all I ask is consensus before I rip thru the IDL...
some people like the long names, others the short ones.... I can go either way.
 If we reach consensus I'll do a global search and replace... I was just being
lazy with my typing to get the idl to compile. 

I. PolicyEvaluatorAdmin a readonly attribute

Carol's description of the issue: Currently the PolicyEvaluatorAdmin inherits
from PolicyEvaluator.

Carol's proposal: I would like to make PolicyEvaluatorAdmin a readonly
attribute of PolicyEvaluator and not use inheritance.  This object ref could be
nil for implementations that don't support the admin interface.


Konstantin


----------------
Broadcast message to hrac-rfp from Konstantin Beznosov <beznosov@baptisthealth.net>.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.