RE: XMLP/XMLE Use cases and processing models

David Orchard writes:

>> Imagine I took a SOAP document and encrypted a big chunk of it,ie:

>> <soap:envelope>
>>      <xenc:encrypteddata>...</xenc:encrypteddata>
>> </soap:envelope>.

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

I beg to differ.  The envelope you show is assuredly not legal SOAP.  I 
would recommend against anyone using this idiom.

There are of course an unbounded number of ways that one might consider 
sending a message that conveys:  "I'll tell you that this is a SOAP 
envelope, but the contents of this entire envelope are encrypted."  I 
think that's what the above is trying to convey.  I suggest that the 
example above is not a particularly good use of XML, Namespaces (it 
violates the definition of soap:envelope) or SOAP (it's surely illegal 
SOAP.)  SOAP provides mechanisms which are reasonably carefully crafted to 
achieve what you want, in a much more controlled and namespace-compatible 
manner.  I suggest we focus on those, and design MIME types accordingly. 
Thank you!

Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

"David Orchard" <>
02/20/2002 12:38 AM

        To:     <>, Noah Mendelsohn/Cambridge/IBM@Lotus
        cc:     "'www-xenc-xmlp-tf'" <>, "'xml-dist-app'" 
<>, "'xml-encryption'" <>
        Subject:        RE: XMLP/XMLE Use cases and processing models


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

Imagine I took a SOAP document and encrypted a big chunk of it,ie
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 
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, 
you can't do if it has media-type application/soap.

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


> -----Original Message-----
> From: Joseph Reagle []
> Sent: Tuesday, February 19, 2002 10:43 AM
> To:;
> 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, 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.       
> W3C Policy Analyst      
> IETF/W3C XML-Signature Co-Chair
> W3C XML Encryption Chair

Received on Wednesday, 20 February 2002 10:57:00 UTC