Hello Andrew,
Wednesday, February 8, 2006, 8:55:30 AM, you wrote: >> I am pleased that NEHTA have finally given us something to go on, and I >> am relieved that they are pushing us to adopt what I think is a great >> technology. I think we need some more specifics however, otherwise there will be as many brands of eSOAP as there are of people SOAP. Its like saying we are going to message in "ASCII" - you need PIT and HL7 to define structure within ASCII and we need wsdl to define structure within SOAP. AP> Agreed, this is a really useful, concrete plan for how things AP> should work, using some excellent technology. >> I have only two questions about their strategy: >> 1. Not using SSL...? AP> As I understand it, SSL has a very subtle problem AP> which is that the PKI certificates AP> are consumed at lower layers in the establishment of AP> the HTTPS connection ,and are hence not available for AP> non-repudiation of the actual payload. So whilst we AP> can connect and mutually authenticate to each AP> other, once the connection is finished, the only proof AP> we had of each others identity, or proof of the content AP> of the message is whatever we have logged in our AP> systems. And that may be fine, and is certainly as AP> much as most systems are doing today. But the The certificates are used for the transport and the messages come out without any proof of who it was from when you are asked the question down the track. If you use client certificates you know at the time but have no record of it other than logs, and logs do not provide legal proof. AP> WS Security standard actually allows the payload AP> to be signed and encrypted, allowing both ends AP> to mutually authenticate, but also keep a signed AP> record of the message payload. AP> I think this is generally considered the way to go AP> (especially in health where non-repudiation of AP> messages may be important) But you do not need SOAP to do that, you can encrypt the message and sign it and send it via SOAP, HTTP, EMail, floppy disc. Our SOAP spec uses a digitally signed and encrypted payload. We use three layers, an optional inner "in message" digital signature that lasts forever and encryption and digital signatures for EACH message in the transport layer. The inner signature need not use the same technology as the transport layers (as only HESA PKI makes it legal we use that but can do it with PGP and GNUPG). Its the inner layer that provides non-repudiation (as its optional as specialists do not need this to send to GPs). As the inner layer is vaid HL7 there is no difficulty in keeping the signature and it can be evaluated at any time in the future, in fact we do it every time we display it. The outer layers are for transport security and authentication. We (ie Medical-Objects) can also apply this scheme recursively, where there are multiple transports in a chain of responsibility pattern. ie we keep adding digital signature and encryption envelopes to the original message or what we call our "Tunnelling protocol". As the message is routed to the destination the layers are stripped off until it gets to the final recipient. AP> Andrew AP> _______________________________________________ AP> Gpcg_talk mailing list AP> [email protected] AP> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk -- Best regards, Andrew mailto:[EMAIL PROTECTED] Andrew McIntyre Buderim Gastroenterology Centre www.buderimgastro.com.au PH: 07 54455055 FAX: 54455047 _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
