RE: Draft registration of application/soap+xml

This is not the group that is designing encryption.  We can talk about the 
alterations that an intermediary can make to a message, and the processing 
rules for a message.  Over time, various other parties may define a broad 
variety of encryption techniques, within the bounds we set for 
manipulating messages.  The W3C XML Encryption proposal is a building 
block that some such efforts may leverage.

In general, I think that SOAP should permit the definition of "features" 
that will allow intermediaries to make more or less arbitrary changes to 
the content of a relayed message (note that creation of a "feature" is now 
a formally specified means by which anyone can extend the SOAP 
specification for use in particular settings.) If there is need in some 
situation to completely encrypt several headers, attributes and all, we 
should not prohibit the definition of features that do so.  Of course, at 
the next node in the path, such encrypted information will not be (is 
unlikely to be) in a form that SOAP will consider to be a header or body, 
and therefore it will not be processed as such. 

If any feature calls for processing of an encrypted header at a given 
node, then it is up to the specification for that feature to say so.  For 
example, the feature spec could say:

a) Use means XXX to decrypt the incoming message and construct the image 
of a clear text SOAP message.
b) Process that message per the specification of the SOAP framework 
chapter 2, as if it had been the message originally received.

In this manner, a feature can be created to use the power of SOAP, without 
our having to lock down the details of SOAP itself.  Sound right?

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------

Received on Friday, 11 January 2002 21:08:48 UTC