Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Blended Authentication (AKA "Granular Access Control")
 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@f...> To: "XML DEV" <xml-dev@l...> Sent: Friday, May 09, 2003 4:59 AM Subject: Re: 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> > > 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
