Re: Comments on XML Encryption

http://www.w3.org/TR/2001/WD-xml-encryption-req-20010420#sec-Processing

At 16:10 7/15/2001, Orchard, David wrote:
>The XML Encryption Working drafts do not provide sufficient information for
>use in SOAP messages, SOAP headers and by SOAP intermediaries.  The
>intersection of encryption with body and headers, and the processing model
>therein, is underspecified.

Hi David,

Thanks for the comment -- and lunch-time conversation last week at the XML 
Processing Workshop. As we learned at that workshop, this issue is one of 
these cross-layer/WG issues for which both communities (protocol and 
encryption) need to be cognizant of.

>I think that Encryption should allow specification of at least 2 schemas so
>that the document is valid in both encrypted and decrypted states.
>Alternatively, Encryption should state that it is not solving this problem,
>that each application using Encryption must determine

As noted, this is largely stated in our requirements:

http://www.w3.org/TR/2001/WD-xml-encryption-req-20010420#sec-Processing
  2. XML Instance Validity {WS}
      1. Encrypted instances must be well-formed but need not be valid against
         their original definition (i.e. applications that encrypt the element
         structure are purposefully hiding that structure.)
      2. Instance authors that want to validate encrypted instances must do 
one
         of the following:
          1. Write the original schema so as to validate resulting instances
             given the change in its structure and inclusion of element types
             from the XML Encryption namespace.
          2. Provide a post-encryption schema for validating encrypted 
instances.
          3. Only encrypt PCDATA text of element content and place its 
decryption
             and key information in an external document. (This requires
             granular detached /external encryption.)

Consequently, an application could certainly maintain two sets of schema for 
pre/post encryption. Whether this is the job of Encryption, SOAP, or an XML 
Processing Language is a good and hard question... My initial response is to 
say it's not in scope of the XML Encryption spec directly -- as there will 
be many apps -- but I think we're certainly obligated to be able to support 
its requirements:

6. Coordination

The XML Encryption specification should meet the requirements of (so as to
support) or work with the following applications:

   * XW3C XML Signature {Reagle}
   * W3C XML Protocols {Reagle}
   * Oasis XML-Based Security Services TC (SSTC) {Reagle}
   * Synchronized Multimedia Integration Language. {List: Simon}


>6. Does xml encryption augment the infoset in any way?

Earlier we did discuss if we were doing Infoset, XPath nodeset, or XML1.0 
encryption. You'll note in the present specification we are pursuing the 
XML1.0 syntax route. This doesn't appear to cause any problems, so far, but 
I think these questions and the scenarios you clearly laid out can be best 
addressed with implementation experience. I hope the XP WG and SAML TC will 
give consideration to the questions you pose, and I think it's a good idea 
to use scenarios from those domain to test our interop requirements in 
Candidate REC.




--
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 Monday, 16 July 2001 15:44:05 UTC