[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
HRAC conference call 7/14/98: minutes
Attached
Konstantin
-----------------------------------
Distributed Computing Architect
Baptist Health Systems of South Florida
voice: 305.596.1960 x6469
Minutes of the HRAC RFP response submitters team conference call
Date: July, 14 1998
Time: 2:00PM -- 3:40 PM Eastern time
Compiled by Konstantin Beznosov
Participants:
Carol Burt -- 2AB,
David Chizmadia -- NSA,
Bret Hartman -- Concept 5,
Bob Blakley -- NIST,
Bart de Greef -- Philips,
V. Juggy Jagannathan -- CareFlow|Net,
Gregg Tally -- Network Associates (TIS Labs),
Andre Srinivasan -- Inprise,
Konstantin Beznosov -- BHSSF
The following issues were discussed:
1. Decision interface
- IDL code
- Exceptions
- Return value from multiple_actions_access_allowed()
- Structure of resource parameters in
*_access_allowed() operations
2. Object model from Orlando meeting
3. Helsinki meeting of the submitting team
4. Action items for the next conference call (August, 11)
-------------------------------------------------------
Details:
Below is the summary of what was said and conclusions the way I
understood. Those who think that something essential is missing from
the minutes or something is presented here inaccurately, please send to
the list or directly to me your comments/feedback/corrections and I'll
incorporate them in the minutes text.
1. Decision interface (Access Decision Object -- ADO)
- IDL code
- Exceptions
No consensus is reached. The issue here is what way we want to
go with exceptions. Three possible directions are identified:
1. Methods raise no exceptions
2. Methods raise exceptions
a. Methods raise only system exceptions (like NO_PERMISSION, BAD_PARAM,
NOT_IMPLEMENT)
b. Methods raise system and application exceptions
The following questions were asked (to the best of my memory):
- Is is appropriate to raise exceptions when the ADO client
just wants to know "yes or no" (for *_access_allowed() methods)?
- What good do exceptions do for *_access_allowed() methods?
- Is not it better to return always "no" instead of an
exception?
- Can it be the matter of policy whether *_access_allowed()
methods raise exceptions or just return "no" when exceptional
situation happens?
- How is an ADO client supposed to act if it gets an exception?
- What does an exception mean in the IDL code of a
specification adopted by the OMG: "condition/event x implies
exception y" or "exception y implies condition/event x"?
- Should the response to HRAC RFP follow the ideology of the
CORBASEC spec in terms of exceptions (which is different from
other OMG specs"? Why yes or why not?
- Isn't is tedious for an application developer to receive an
exception instead of a sequence of answers and have to do all
over again when the method multiple_actions_access_allowed() is
used.
The following steps were suggested:
- Check with other OMG specs and see if they use application
exceptions, system only exceptions, or they try to avoid using
exceptions at all.
- Propose the semantics of exceptions raised by
*_access_allowed() methods and to see if such semantics will
actually be useful for anyone.
- Come up with a more useful way to raise exceptions in
multiple_actions_access_allowed()
- Return value from multiple_actions_access_allowed()
It was suggested by Carol to replace current return value type
with sequence<boolean>. There were no objections.
- Structure of resource parameters in
*_access_allowed() operations
There was discussion on whether type Resource should have any
structure, and if yes then what. No consensus was reached.
There were several issues raised:
- How does the ADO find such information about the resource as (for
instance) a clearance level associated with the resource, the
patient associated with the resource, a group the resource
belongs to (if resources are grouped somehow).
- We can end up doing content-based access control, which the
RFP did not ask for.
There were several suggestions made:
- To make type Resource to be at least a sequence of strings.
- To make it a hierarchical structure.
- To make it a hierarchical structure with ability to contain
any other type.
- To keep it just opaque.
- To organize resource space into a hierarchy similar to naming
service and allow the ADO to find the place of the resource in
such a hierarchy.
- To let the ADO clients to organize the recourses in whatever
hierarchy they want and traverse the hierarchy step by step using
access_allowed() or multiple_actions_access_allowed().
Apparently, this topic is much less understood for us to reach
consensus in one conference call.
2. Object model from Orlando meeting
It was decided to discuss the model over e-mail and in the next
conference call when Bob will participate in the call. One obvious
question was asked "What is the difference between items in the
picture with thick boundaries and thin ones?"
Also, there was typo of the project PCASSO found in the picture.
The project web side is
http://medicine.ucsd.edu/pcasso/
3. Helsinki meeting of the submitting team
Carol, Bret and David will be in Helsinki. Konstantin might be
too.
David Chismadia offered to use one of the reserved for SecSIG
rooms during the meeting. Konstantin suggested to have at least
1/2 day meeting of the submission team in Helsinki.
4. Action items for the next conference call (August, 11)
1.Old item from the previous conference call:
Konstantin to send to the mail list several use cases that
show how the policies that he sent earlier has to be enforced by
a clinical application.
2.David offered to come up with alternative decision interface.
3.Every one to send feedback on the object model from Orlando
meeting to the mail list.
--------------------------------------------------------------------