W3C home > Mailing lists > Public > www-xenc-xmlp-tf@w3.org > February 2002

RE: XMLP/XMLE Use cases and processing models

From: David Orchard <david.orchard@bea.com>
Date: Tue, 19 Feb 2002 21:38:04 -0800
To: <reagle@w3.org>, <noah_mendelsohn@us.ibm.com>
Cc: "'www-xenc-xmlp-tf'" <www-xenc-xmlp-tf@w3.org>, "'xml-dist-app'" <xml-dist-app@w3.org>, "'xml-encryption'" <xml-encryption@w3.org>
Message-ID: <003301c1b9d0$c5e09350$3d0ba8c0@beasys.com>
Joseph,

I'm not suggesting that XMLE try to automatically make pre-existing
applications XML Encryption aware.  I don't follow how you get that
extraordinary claim.  I'm suggesting that documents have content-type of
application/xenc+xml for documents containing XMLE where XMLE decryption
MUST be done to interpret the contents according to the namespace names
within.

Imagine I took a SOAP document and encrypted a big chunk of it,ie
<soap:envelope><xenc:encrypteddata>...</xenc:encrypteddata></soap:envelope>.
The SOAP processor knows nothing about the soap document as encryption
happened "afterwards".  When such a document was sent, decryption would be
required first.  After decryption, then a SOAP processor would know what to
do with it.  While this particular document is encrypted, it is NOT a SOAP
document as per the soap namespace name nor media type.

Making such a document have a media-type of application/xenc+xml ensures
that the document can be dispatched to the correct piece of software, which
you can't do if it has media-type application/soap.

Again, this is not changing the SOAP spec in any way.

Cheers,
Dave

> -----Original Message-----
> From: Joseph Reagle [mailto:reagle@w3.org]
> Sent: Tuesday, February 19, 2002 10:43 AM
> To: noah_mendelsohn@us.ibm.com; david.orchard@bea.com
> Cc: 'www-xenc-xmlp-tf'; 'xml-dist-app'; 'xml-encryption'
> Subject: Re: XMLP/XMLE Use cases and processing models
>
>
>
> Exactly. Applications which use to use XML Encryption or
> otherwise expect
> to have elements from other namespaces need to be savvy about
> what they
> want to do (e.g., encrypt the content of a SOAP:Header) and
> how they want
> to do it  (e.g., write a flexible, create a new namespace ,etc.)
> Applications that haven't done this might have to take some
> other steps
> which won't as easy and straightforward but it's their call.
> There's no
> solution that automatically makes all pre-existing XML
> applications XML
> encryption aware or capable in every possible scenario --
> like encryption
> the SOAP header itself.
>
> On Monday 18 February 2002 20:21, noah_mendelsohn@us.ibm.com wrote:
> > which is indeed not valid SOAP, suggesting the need for a
> new media type.
> > But... that's not how you would use SOAP IMO.  I suggest instead:
> >
> >         <SOAP:Envelope xmlns:soap="..." >
> >            <SOAP:Header>
> >                 <xenc:EncryptedData xmlns:xenc="..."
> >                             SOAP:mustUnderstand="true"
> >                             SOAP:role="decryptingIntermediary">
> >                 ...
> >                 </xenc:EncryptedData>
> >            </SOAP:Header>
> >            <SOAP:Body>
> >                 ...leave empty or put dummy element here
> >                 ...if you don't want unencrypted data
> >         </SOAP:Envelope>
>
> --
>
> Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
> W3C Policy Analyst                mailto:reagle@w3.org
> IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
> W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
>
Received on Wednesday, 20 February 2002 02:40:04 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Friday, 25 March 2005 11:21:54 GMT