RE: [hrac resources]

["V. Juggy Jagannathan" <juggy@careflow.com>]

I agree with the analysis below - some inline comments -

> -----Original Message-----
> From: owner-hrac-rfp@cs.fiu.edu [mailto:owner-hrac-rfp@cs.fiu.edu]On
> Behalf Of Konstantin Beznosov
> Sent: Wednesday, August 05, 1998 2:21 PM
> To: hrac-rfp@cs.fiu.edu
> Subject: Re: [hrac resources]
>
>
> see in-lined
>
> > With regard to Juggy and John's comments on the proposed resource
> > structure:
> >
> > I don't wish to speak for the proposers (Bob and Carol) of the resource
> > structure but it was my impression that the proposal was
> directed at the
> > structure of resources not the structure of resource metadata. In other
> > words, each element of a path is a resource with which security metadata
> > (e.g., name/value pairs as John describes) about that element may be
> > associated. The resource structure may be independent of any metadata
> > structure. The resource structure may not have any relationship
> to metadata
> > structure.
> As far as I understood what was said during the meeting and John Barkley's
> words, his interpretation is correct. It remains to hear from Bob
> and Carol of
> cause.


Unfortunately I don't understand this - if we are simply talking about
structring policies, using trees
then I agree it is a different animal. We do need a way to relate Resource
Security Metadata to
actual policies.

What is a resource structure? A resource to me an
observation - a transcribed report, lab results etc. The structure of these
we don't even know
what these will be - could be a block of text, blobs (images), structured
text,
structured data etc.



> One point I would like to make is about distinguishing between resources,
> resource identifiers and resource security metadata.
>
> The original intent of HRAC RFP was to use the notion of a resource as an
> abstract concept in order to avoid naming of any particular
> entities. Since a
> resource can be an any asset valuable to a particular enterprise,
> the RFP was
> using the term "resource" to refer to such assets.
>
> When we began to discuss the subject of resource organization,
> David Chizmadia
> raised the issue of incorrect use of terminology and suggested to
> distinguish
> the notion of resource, its instance, its identifier, and its security
> metadata.
>
> I would claim that the notion of a resource and its instance is
> not the subject
> of interest to this RFP submission at all. What the intended
> (HRAC) service is
> interested in regards to resource is ability:
>
> 1. To relate a resource identifier to a set (or group, or chain) of
> authorization rules, and
>
> 2. To obtain enough data to evaluate those rules and arrive to
> authorization
> decision.

Makes sense.


> As someone might observe, how are resources or their instances
> (in the sense
> that David gave to them) are organized and what they mean, is of
> now interest
> to the submission. The resources are not passed among ADO and its
> clients. What
> can be passed and what can be used for #1 and #2 are either resource
> identifiers, or resource metadata, or both.
>
> When the word "resource" is used on its own in this discussion, I usually
> assume that "resource ID" is meant. However, it's a good idea of David to
> strive for correct usage of terminology and concepts in the discussion.
>
> Let me go back to the numbered list above. Clearly, #1 can be
> done by indexing
> rules by resource identifier (for example flat resource
> identifier space) or
> its parts (for instance, tree-like hierarchies).

It appears that this is more a question of representing and organizing
policies as opposed to
organizing resource metadata or resource space.

>
> Another point I would like to make is about several different
> ways to obtain
> enough data in order to evaluate authorization rules. Maybe if we
> explicitly
> distinguish them and decide what way we want to go, then we can
> concentrate on
> the selected one and refine it.
>
> Data used in rule evaluation (i.e. #2) can be decomposed into
> three groups:

> a. Data pertaining only to the principal credentials (roles,
> groups, access id,
> etc.)

> b. Data pertaining only to the resource identified by the
> resource identifier
> (patient ID associated with this resource in healthcare, for example)

> c. Data derived from a relationship between data from a and data from b
> (relationship between the principal and the patient associated with the
> resource as of the healthcare domain).
>


Completely agree with the above categorization of information needed.


> Resource metadata is the data described in b.
>
> I'm observing three different ways to obtain #b. And this is where our
> discussion is going around. Those 3 ways are as following (I use words
> "metadata" and "data" to mean the same type of data unless specified
> otherwise):
> 1. Pass only resource id to the ADO. In order to obtain the data
> the ADO is
> supposed to go elsewhere and use resource id to find the data.
> 2. Pass only resource id  to the ADO and use it as a carrier of
> the data. Where
> as,
>  a. data syntaxes and semantics of the data are predefined and assumed.
>  b. data syntaxes is not assumed. Data is represented by parsable tag-like
> structures. Semantics of data is predefined elsewhere.
>  c. syntaxes and semantic of data are defined elsewhere and a reference to
> those definitions is passed along the data itself.
>
> Now, how do the proposed so far schemas fit in this categorization?
>
> - Flat space of resource ids and tree-like hierarchy of resource
> ids (without
> any semantical assumptions) fall under group #1 of the list above.
>
> - If a tree-like hierarchy assumes particular semantics (like my careless
> original example /BHS/JohnSmith/...), then it falls under 2.a
>
> - If somebody proposed tag-like data structures (see Tag RFP
> initial submission
> in orbos) or even just simple trates similar to PIDS, that would
> fall under 2.b
>
> - David's notion of a template repository (see his "object model"
> posted about
> 2 weeks ago) falls under 2.c

I finally looked up and read David's object model. My appologies for not
having read that till now :-).

The template notions or using XML sounds interesting.


> Each way has pros and cons. What one (or more than one) should be
> used in this
> submission?
>
> Konstantin

My appologies to Carol and others for arguing so much :-)

- 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.