[COAS-List] Re: [hrac resources]

["David M. Chizmadia" <dmc@tycho.ncsc.mil>]

Juggy,

  With respect to metadata and the issues associated with
its management, see my comments inline, below:

-DMC

-----Original Message-----
From: V. Juggy Jagannathan <juggy@careflow.com>
To: hrac-rfp@cs.fiu.edu <hrac-rfp@cs.fiu.edu>
Cc: coas@cs.fiu.edu <coas@cs.fiu.edu>
Date: Tuesday, August 04, 1998 1:44 PM
Subject: RE: [hrac resources]


>
>some comments inline......
>
>>   <Snipped to save bandwidth...>
>
>Good set of definitions. in the example below, except for the last
item
>(resource) the
>rest are metadata. I am glad you used the term and not me...:-) we
had a
>long discussion on
>the loaded term "metadata".

  I'd have preferred to use the term "label" or "tag", but it
makes sentence structures too hard :-(.  The core point is that
it is the data that provides the necessary context for security
access decisions.

>
>In any case my earlier comment stands. If you have a million
patients, and
>hundres of items of
>interests (individual prescriptions, lab results, discharge
summaries) there
>is a large amout of
>metadata that needs to be managed, represented and referred to as
part of
>enforcing policies.
>Further, most of the information is going to be associated with the
resource
>itself.

  EXACTLY!!!  This actually simplifies life over the assumption
that the RSM is separate from the resource - especially if the
ADO interface only requires that the RSM be passed in.  The ADO
Client would only have to extract the unique instances of RSM and
ask the question: Access_allowed?  The policies are only capturing
the relationships between credentials and RSM.  In general, I
would expect only one set of RSM per RESOURCE and multiple
policies that reflect the effect of different specific values
within the RSM

>
>> >>      owner: Bhssf
>> >>      location: SMH
>> >>      patientID: patients/JohnSmith
>> >>      conceptCode: bloodtests
>> >>      date: August 2
>> >>      instanceID: test 3
>
>Now the question on the table is whether a tree or psuedo tree like
>representation of metadata
>is sufficient/usefull for enforcing policies. Given that the
information
>itself (metadata or not) is going to be stored in a completely
different
>form (attributes in tables or objects) - i am not sure how trees
help.
>
>>
>>So, let's try to answer the following question: "What organization
of
>resource
>>space will allow us to express reasonable authorization policies?"
>

This is one of the places where I think RESOURCE is being used
in place of RSM.  To me, the question has no particular meaning.
reasonable access policies require:
  1. Well defined Credentials,
  2. Well defined Security Metadata, and
  3. Well defined constraints on interactions between 1 and 2.

Put another way, I believe that the policies will impose all
of the organization required upon the RESOURCE (SECURITY
METADATA) space.  The heirarchical examples discussed are
really just pre-defined containment policies among the
components of the RSM.

>
>this is indeed a good question to ask!!!!
>
>
>>In the context of this question, I was thinking about how resource
>space can be
>>organized in the following situation:
>>(it's just an example)
>>
>>Security labels are used to assign a sensitivity level to all
patient
>>information. The following sample set of sensitivity levels is used
>{public,
>>protected, confidential}.
>>
>>Then all public information can be associated with resource:
>>/PID/public.  All confidential data can be associated with resource
>>/PID/public/protected/confidential
>>
>>Where PID is PIDS-compliant patient ID.
>>
>>Do you think such a way of resource organization can satisfy most of
>reasonable
>>policies based on sensitivity level?
>
>in the above case you are simply associating a "sensitivity" label
with a
>particular resource. this can
>be done in one of many ways. For instance, in our discussion in COAS,
i
>believe we will be supporting
>the notion of returning the contextual information (metadata) given a
>resource ID (in COAS we were
>calling it the observation ID or something like that). One can
examine this
>data, and depending on
>a poilicy statement, determine the sensitivity level of that
information.

So you are already looking towards the idea that the ADO Client
would extract and pass the RSM into the HRAC, thus removing the
requirement for the HRAC to be able to interpret the structure
of the RESOURCE and extract the RSM.  THIS IS GOOD!

>
>hope all of this makes sense :-)

It all makes sense - even if I don't agree with all of it!!

>
>- regards
>- juggy
>
>
>----------------
>Broadcast message to hrac-rfp from "V. Juggy Jagannathan"
<juggy@careflow.com>.
>Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list
archive.