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
> 
> 

From arshad.noor@s... Wed Apr 08 10:40:23 2009
Received: from maggie.w3.org ([