RE: XMLP/XMLE Use cases and processing models

Noah,

I completely understand the cases you are talking about, and I agree with
the direction the XMLP wg is going wrt QNames and intermediaries.  My
comments on namespace names have specifically been around the context of
potentially misleading qnames.   I agree the case I mentioned is bizarre,
but part of our job is to examine these corner cases.

After some twists and turns in the discussion, a sample scenario should
illustrate.  For whatever reason, encryption of a portion of a message
occurs.  The downstream processor MUST decrypt the message to have it
conform to a Qname or media type.  Looking at a SOAP/HTTP fragment,

Content-type: application/soap

<SOAP:Envelope xmlns:soap="..." >
<xenc:EncryptedData xmlns:xenc="...">
...
</xenc:EncryptedData>
</SOAP:Envelope>

Now clearly this isn't valid.  My suggestion is that changing the content
type to Content-type: application/xenc-xml solves the issue of content-type
problem.

This is very similar to the xhtml/xslt example that the tag is discussing,
where one perspective is that

<xhtml:html>
<xslt:...>
....
</xslt:...>
</xhtml:html>

SHOULD have a content-type of application/xslt(+xml)

I'm trying to apply the same rule of the xslt example (dispatch based upon
content-type, then qname) to XMLE.  To me, these are very similar
(transformational) cases.

Joseph is strongly pushing back because he believes that XMLE should not try
to enforce behaviour on other applications.  As a result of our discussions,
he has taken an action item to register an xenc content-type.  From my
perspective, I'm trying to get some rules in place for how that content-type
should be used with xmle.  I suggested something along the lines of "When a
content-type is provided for a message, XML Encryption requires that the
application/xenc+xml MUST be used when decryption is required to correctly
interpret the content".  But we didn't get very far with that suggestion.

There is a section in the TAG draft findings on content-type and namespace
disptach [1] that states "It is a serious error for the resource body to be
inconsistent with the assertions made about it by the MIME headers. ", which
I believe is the case in the SOAP example that I mentioned.  These findings
are NOT ratified by the TAG, but I believe it likely that there will be a
statement on this matter.

Cheers,
Dave
[1] http://www.w3.org/2001/tag/2002/0129-mime



> -----Original Message-----
> From: Noah Mendelsohn [mailto:noah_mendelsohn@us.ibm.com]
> Sent: Friday, February 15, 2002 4:27 PM
> To: david.orchard@bea.com
> Cc: imamu; maruyama; reagle; www-xenc-xmlp-tf; xml-dist-app;
> xml-encryption
> Subject: RE: XMLP/XMLE Use cases and processing models
>
>
> David Orchard writes:
>
> >> My concerns have been about the case where a vocabulary that
> >> knows nothing about encryption has a portion of an instance
> >> encrypted, and keeping the namespace name and root element
> >> of the vocabulary as if encryption didn't occur is "fibbing"
> >> about the namespace.  Imagine if SOAP-SEC did NOT know about
> >> encryption, yet had encrypted content, how would a
> >> dispatcher know to decrypt content?  This is also assuming
> >> there is no explicit soap actor.
>
> (speaking for myself, not the Protocls WG)
>
> The designs being worked on in the Protocols WG effectively cover this
> case.  First of all, we would discourage such misuse of the
> QNames that
> identify header blocks.  As described below, the preferred idiom would
> be to repace the original block with one carrying a QName with the
> semantic:  "this is encrypted content.'  The pertinent SOAP mechanisms
> are as follows:
>
> SOAP establishes a normative baseline model which is that an
> intermediary processing a header block must do so in a manner that
> conforms fully and completely to a specification associated with that
> QName (we don't say how such specifications are established...it's
> your responsibility in using a header block to know its
> specification.) [1, 2]
>
> {The above has been true for awhile; the mechanisms in the next few
> paras were recently agreed to, but are not yet in the editors drafts
> of the specifications.}
>
> To handle cases like encryption, we allow an intermediary to remove a
> block, and perhaps replace it with other (e.g. encrypted) content.  In
> such cases, one of two things must be true.  Either a) one of the
> blocks in the inbound message explicitly allowed the change or b)
> [your case] the intermediarly that makes the change must introduce a
> header >>> which has as its specification information sufficient to
> alert downstream nodes to the nature of the change.<<< This can be as
> simple as being careful with the specification associated with the
> QName for the encrypted block itself.  In short, you MUST NOT just
> switch the content on any old block;  you MUST properly use QName
> identified blocks to indicate to downstream nodes any change in
> the normal interpretation of the message.
>
> How would this apply to your challenge above?  First of all, the usage
> you describe is somewhat bizarre, and not intended as the normal way
> of doing things.  We would generally prefer that you remove the
> original unencryped header block and its QName and use a new QName to
> indicate encrypted content.  Still, if you really wanted to put the
> encrypted content under the original (and now misleading) QName,this
> is how it would work: rule b above would require you to introduce a
> second header block,labeled "mustUnderstand" with the semantic "don't
> trust the other QNames in this message...I've overridden their
> traditional meanings."  Again I am NOT encouraging this, but pointing
> out that the message would necessarily contain a warning that this had
> been done.  As the message moved downstream, either a decrypting
> intermediary would act on the alert, do the decryption and put the
> message back together, or the recipient would find a mustUnderstand
> header warning of the problem.  It would either understand how to deal
> with the mess, or would recognized that it did not understand, and
> safely fault.
>
> Bottom line: SOAP normatively requires you to use QNames according to
> an associated specification.  If you really, really want to override
> that, there are controlled and reasonably safe ways of doing so, but I
> see no good reason for users to do misuse the system that way.
>
> [1] http://www.w3.org/TR/2001/WD-soap12-part1-20011217/#muprocessing
> [2] http://www.w3.org/TR/2001/WD-soap12-part1-20011217/#procsoapmsgs
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
>
>
>
>

Received on Saturday, 16 February 2002 01:28:16 UTC