- From: Takeshi Imamura <IMAMU@jp.ibm.com>
- Date: Wed, 13 Feb 2002 01:19:41 +0900
- To: "David Orchard" <david.orchard@bea.com>, reagle@w3.org
- Cc: "'xenc'" <xml-encryption@w3.org>, <www-xenc-xmlp-tf@w3.org>, <xml-dist-app@w3.org>, "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>
>> Questions >> ---------- >> 1. I have anticipated that the intermediary has to know about the >> receiver schema and must expose the "merged" schema or a schema without >> the unencrypted credit card info to senders. There is tight coupling >> there, but how else would the intermediary know which messages and which >> portions to decrypt? Is this valid or does XMLE expect that a SOAP >> encrypting/decrypting intermediary would not know about the receiver >> schemas nor would it expose a "merged" schema? This assumes the first or >> second solution in the processing requirements (3.2.2) [1]. > >I'd be interested in some of the xenc implementors thoughts on this since >they best know how they want to process the data. However, given my >ignorance I could see a few options: > >1. The namespace is changed to indicate the change of the instance. This >means you will have to have a namespace for every encrypted variant. This >is probably fine for some applications (e.g., they know they only care >about encrypting the credit-card data and nothing else so creating a new >namespace and schema isn't very difficult.) Others may care less about >validation and more about flexibility. >2. One "pre-scan's" the document looking for xenc:* elements. For example, >during parsing (e.g., XNI [1]) one could flag such instances that trigger >subsequent action. >3. The encryption is "baked" in to the application context. For instance, >if you know that you'll be sending credit card data over an open network >there needn't be choice between the credit card data in the plain and the >encrypted form. The credit card is *always* sent encrypted and the >recipient is always decrypted at the other end. >4. Meta-data is used to indicate the some of the data has been encrypted. >For instance, to make option 3 a little more flexible, one could create a >SOAP confidentiality header that indicates a decryptor actor with >mustUnderstand="1". > >In these options there are two issues: (1) how to know if parts of the >document have been encrypted, (2) how to know which agent is supposed to do >the decryption. These issues are not only ones of XML Encryption but can be ones of others. So we should address them as generally and extensiblly as possible. From such a point of view, I think option 4 (e.g., [1]) looks the most reasonable. [1] http://lists.w3.org/Archives/Public/www-xenc-xmlp-tf/2001Dec/0001.html Thanks, Takeshi IMAMURA Tokyo Research Laboratory IBM Research imamu@jp.ibm.com
Received on Tuesday, 12 February 2002 11:29:00 UTC