W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2002

Re: XMLP/XMLE Use cases and processing models

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>
Message-ID: <OFA6F99BAE.83B69FA1-ON49256B5E.0054A7A0@LocalDomain>


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

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:06 GMT