Re: [hrac resources]

[Konstantin Beznosov <beznosov@baptisthealth.net>]

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.

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.

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

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

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

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

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.