RE: XMLP/XMLE Use cases and processing models

Noah,

My point isn't how SOAP could use Encryption in the manner that you suggest.
That is one obvious solution, and I agree that it is a reasonable approach
in many cases.

My point is that XMLE allows the "edge" case that I described.  The
difference between the two is that the example I gave has a xenc processor
required to be the first step (yet is hidden inside a soap message) and your
sample requires that a SOAP intermediary be the first step.  I suggest that
the first case can be made "legal" by having a MIME type.  Another option
would be for xenc to disallow the first case.  I'm trying to be flexible and
search for a way of allowing the syntax to be legal and also allow correct
dispatch.

As an aside, I'm fully in favour of having an explicit processing model.
Targetting actors is one way to get there.  I think that we will find over
time that ordering becomes an issue, fwiw.

Cheers,
Dave

> -----Original Message-----
> From: Noah Mendelsohn [mailto:noah_mendelsohn@us.ibm.com]
> Sent: Monday, February 18, 2002 5:21 PM
> To: david.orchard@bea.com
> Cc: 'www-xenc-xmlp-tf'; 'xml-dist-app'; 'xml-encryption'
> Subject: RE: XMLP/XMLE Use cases and processing models
>
>
> David Orchard suggests:
>
>         <SOAP:Envelope xmlns:soap="..." >
>         <xenc:EncryptedData xmlns:xenc="...">
>         ...
>         </xenc:EncryptedData>
>         </SOAP:Envelope>
>
> 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>
>
> This is valid SOAP, does what you want, and doesn't need a
> non-SOAP media
> type, I think.
>
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
>
>
>
>
>
>
>
> "David Orchard" <david.orchard@bea.com>
> 02/15/2002 08:35 PM
>
>
>         To:     Noah Mendelsohn/Cambridge/IBM@Lotus
>         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>
>         Subject:        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 Monday, 18 February 2002 22:34:29 UTC