The "Blended Authentication" thread has been running for a while at
XML-DEV. Archive link below. The following is just one of the latest posts;
it seems reasonable to forward this and inject it into the Yak tribe as
fodder for consideration as people mull over authentication, identity,
trust, and reputation. (01)
>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> (02)
---------------------------------------------------------------------------
XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor (03)
Build smarter kids globally to reduce the need for smarter bombs. (04)
--
This message is archived at: (05)
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=tools-yak&i=5.1.1.6.0.20030509102506.03b61898@thinkalong.com (06)
|