[
Lists Home |
Date Index |
Thread Index
]
The purpose of my example was to make more concrete and personal the issue
under discussion. I'm still not sure how the principles you describe apply
to this kind of case, where there are legal and regulatory requirements
about who may have access to which data. Could you explain more fully?
The hospital medical records system must know of the existence of the
corporate entities at least which are authorized to examine subsets of their
records using some kind of matching criteria. The hospital may or may not
have some kind of legal contract (possibly enforced or not in the
interaction of their software systems) with each health insurance provider
spelling out terms of use of the data (in order to meet the hospital's legal
obligations, etc). Whether or not there is some easy and automatic way to
meet these contract terms in the implementation (using certificates or
something), somewhere, someone, entered some token in the records of your
surgery specifying your insurance provider, so someone involved with System
B is aware of the existence of System A, at least in the abstract.
Similarly, System A must associate a medical claim it receives that refers
to the hospital with System B (this could be using some kind of URL), and it
is thus aware that System B exists and is a provider of a certain kind of
data. It is also aware (perhaps by some kind of hardcoding, or perhaps by
looking at the URL) that it needs to provide certain kinds of authentication
and authorization tokens in order to gain access to System B's data. These
considerations seem inescapable to me. Am I missing something?
My previous note was not attempting to criticize the systems you design or
the principles under which they are designed, but to correct your
characterization, inaccurate in several areas of substance, of what I had
proposed.
Jeff
----- Original Message -----
From: "W. E. Perry" <wperry@fiduciary.com>
To: "XML DEV" <xml-dev@lists.xml.org>
Sent: Friday, May 09, 2003 4:59 AM
Subject: Re: [xml-dev] Blended Authentication (AKA "Granular Access
Control")
> Jeff Greif wrote:
>
> > Thus, the parties have agreed only on the criteria for acceptability of
> > particpants, not the comprehensive list. They have not agreed on the
scope of
> > functionality -- System B has imposed requirements, and will give
information
> > to System A if the request meets those requirements.
>
> I think that you are describing one sort of system architecture and I am
> describing another. The salient differences are that in your architecture
>
> -- Systems A and B know of each other's existence and have at least
general
> understanding of the nature of each other's functionality--enough for each
of
> them to understand the border or the difference between their respective
> functions
>
> -- Systems A and B both present public interfaces which, if specific,
> disclosed input requirements are satisfied, will prompt the system to
execute
> its particular function. What may not be so publicly understood is the
outcome
> of that function--that is, the data product which the system publishes or
> otherwise makes available. The interaction of each of these systems with
their
> public users is designed around what they consume (the input interface)
rather
> than what they produce
>
> whereas in the design I propose
>
> --systems do not need to know who consumes what they produce, nor for
what
> purpose or with what semantics, and certainly do not know such things a
priori
> as the basis of their relationships with those consuming systems. In my
> architecture the relationship between autonomous systems (or indeed any
> functional nodes) is always 'webbed', never linear, always
uni-directional,
> never bi-directional, because a bi-directional exchange would require that
a
> system knew what was downstream of it, and with what semantics attached to
its
> processing of the data shared between those systems
>
> --systems publish their output in a form retrievable by,
paradigmatically,
> an http GET. Systems do not publicize nor predictably respond to input
> interfaces. A significant part of a system's necessary expertise is
knowing
> where among published data outputs to find the data which it requires as
input
> and how to instantiate what it finds into the form which it requires for
its own
> processing.
>
> > There may be no agreement whatever between System A and System B.
System B
> > may simply announce that certain data are available under certain
conditions
> > of authorization and authentication, to any party who can meet them.
The
> > particular scenario of Joe examining your hospital records, as a legal
> > representative of your health service provider, just meets the publicly
stated
> > preconditions for access to System B.
>
> That is in large part an overview of a system built according to my
principles.
> I think that when you flesh out what you describe here with implementation
> details you will find that you have something *very* different from what
Joe and
> John and probably even you envision. Many people do react in horror when
they
> see systems built to these principles or realized their implications for
> (lacking a more precise term) the expected cartelization of function among
> systems know a priori to one another.
>
> Respectfully,
>
> Walter Perry
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>
|
