On Mon, 2003-09-22 at 10:42, David Forslund wrote: > Well sure, but you need to do some digging. All of this is implemented in > OpenEMed using the open source ORB OpenORB (on sourceforge.net), > which provides full support for it. By simply changing the environment, > we can switch to using SSL and full security and encryption without > changing our code. If the application needs to know who the person > is making the request and the person doing the responding to see > if they have the right permissions, then the RAD has to be turned on > which enables the full checking of credentials. This is all implemented > and works in CORBA, and is all open source.
Are you saying is that the commonality between users has to be at the interface level i.e. everyone needs to use CORBA? If so, I think that is unrealistic.
The commonality has to be higher level than CORBA. One must agree on the communications protocol, be it CORBA, http, or whatever. This has nothing to do with security. Security then is put on top of the agreed upon communication protocol. CORBA happens to make that very easy, because it is done in an "orthogonal" manner. I can build and run my entire application and then add security without having to modify a line of code.
> Sure, but the issue isn't only security it is what you are using for your > underlying > communications infrastructure.
We are assuming the Internet i.e. an insecure TCP/IP network.
This is not what I'm talking about. You will need some level above that to exchange messages.
> The biggest problem I find is the variation
> in security policies which prevents security interoperatiblity independent
> of whether CORBA is being used or not. Security interoperability is the
> big challenge. Adding some new protocol to handle it doesn't help. Using
> standards does. It is these standards that we encourage. For example,
> there is something called CSIv2 which is a standard, and if implemented,
> enables
> folks to talk together securely including quoting of credentials. It seems
> that
> interoperability is so far down on people's list of things that are
> important that
> it isn't recognized.
I agree, although standards ultimately need to define or nominate protocols to enable things to be done. CSIv2 seems to be specific to CORBA and J2EE -is that correct?
that is correct, but it is the only standard for accomplishing quoted credentials.
CORBA makes essentially no restriction on platform or language.
The problem is a simple one: - many thousands of healthcare providers, not organisationally connected in any particular way except that they serve the same population of people - all connected to the Internet, some permanently via broadband, some intermittently via modem - many, many disparate systems - need to be able to exchange HL7 messages and other "payloads" with each other securely and reliably and as rapidly as possible.
Why does everyone need to exchange HL7 messages? This only adds to
confusion. Data only needs to be "exchanged" when needed. Someone
needs some information on a patient and needs to look the person up and
discover who has the relevant information. This requires a higher level semantics
than HL7 usually provides. It doesn't provide service discover, nor does it
provide security. Disparate systems is what CORBA was designed for.
The semantics of "payloads" and the semantics of appropriate questions to ask
to obtain a "payload" is what the standards we have been using are all about.
We want no restriction on platform or programming language. Lately XML
seems to be filling that niche and can be easily used for that purpose, but
there is not yet any equivalent to CSIv2 in XML and the other parts are several
years behind in development and standardization. We can easily, however,
translate our standard interfaces into XML, but not easily with security.
- each healthcare provider's information ssytem needs to be able to interface with the message transport mechanism via a simple, lightweight API
What does one mean by a simple, lightweight API? I think that is in the eye of the beholder. I need to be able to express the semantics of a question and ask it of an individual system or a set of systems.
- each healthcare provider needs to be able to maintain their own entries (including public keys) in a shared directory of message delivery addresses
This implies a certain technical solution. They need to be able to location services and identities of participants.
- a means of validating public keys is required.
Yes. This is unrelated to the actual communication protocol.
Now there are (many) standards for each of the individual parts of this problem (eg X509). But are there higher-level standards, or pseudo-standards in use which combine these into a complete interoperable system?
That is what CSIv2 is about.
The issue is much bigger than that, however. Each organization we have
dealt with has different security regulations and procedures. Spanning
those is the real problem, even if we use the same communication infrastructure.
Thanks for the discussion.
Dave
--
Tim C
PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0
