- From: Arshad Noor <arshad.noor@strongauth.com>
- Date: Wed, 08 Apr 2009 03:22:31 -0700
- To: Dieter Menne <dieter.menne@menne-biomed.de>
- CC: xmlschema-dev@w3.org
So, you need to decide what is more important - brevity of schema design, or brevity of information-transfer for a purpose (hospital use vs. calibration, etc.). Not all business cases will have optimal answers. If the client application needs to see the decrypted data, then yes, it must have access to the decryption logic and key. All others can exclude the logic and ignore the ciphertext (encrypted data). Currently, browsers have limited capabilities to work with new key-management schemes; they only understand SSL/TLS and with local ( and proprietary) cryptographic key-stores. So, any display of encrypted data within a browser report must be handled by the web-server before the browser receives the data - but this can be transparent to the browser. (I'm assuming this is what you meant by "encoding"). Arshad Noor StrongAuth, Inc. Dieter Menne wrote: > > Arshad Noor wrote: >> >> By encrypting the data and placing just a reference to the >> key-identifier (using the XML Encryption XSD), you can now >> use a single XSD for your own data and leave the patient >> data in there all the time (minOccurs="1" all the time). > > Interesting point, and it certainly is a solution for the case of the > patient records. For some other stuff like "nice-to-have but better leave > out if not required" (calibration) it is not an options. > > I see the problem in the fact that this required decryption logic on the > client side (but I may be wrong here, correct me please). It is an > attractive feature for the hospitals to use the XML format to display > customized reports; is it possible to transparently tell the browser "get > your encoding if you can"? > > Dieter > >
Received on Wednesday, 8 April 2009 10:23:20 UTC