RE: Attribute encryption, Schema validation, role of XSLT, scope of XML Encryption document

I just wanted to summarize my positions on a number of topics that
have been intertwined during the past few days.

1.  Should XML Encryption prescribe how to encrypt attributes?

Both elements and attributes are defined by XML for structuring
information and real-life applications do use attributes frequently.
I think it would be very controversial in the XML world to 
not support the encryption of attributes unless it is really
infeasible to do so.

One view that has been expressed is that XSLT could be used when 
encrypting attributes; basically by converting the attributes into
elements and proceeding accoriding to the current spec.  I both
like and dislike this approach.  I like it because if it works for
attributes, it can easily work for all sorts of XML substructures.
But I dislike it because, like Takeshi, I have concerns about
bringing in high-level functionality for processes that will often
need to work in low-level environments, eg. parsers.  Hence,
my hope is that the EncryptedDataManifest approach I've described
will be an adequate compromise between needed functionality and 
complexity as it should work well for both attributes and external
arbitrary data.


2. What about schema validation?

I operate on the general belief that many systems need to test the 
validity of XML instances only at certain conjunctures and that
many processes in an XML system will only need access to 
specific parts of an XML instance.  And as long as the XPath to
those parts remains valid, those processes will remain happy.
That said, though many XML systems will be able to introduce 
XML Encryption without schema changes, many will find it 
advantageous to  modify their schemas to recognize the 
XML Encryption namespace.

Ultimately, I would like to see validators able to indicate
1) Just whether a certain subtree is valid or not.  
2) Be able to exclude subtrees marked as obfuscated.  This would
entail the XML Schema WG to perhaps define an xml-prefixed
attribute for defining obfuscated subtrees.
Note that the above two proposals would not be required by XML
Encryption in version 1.0, just future considerations because 
I expect we will ned to liason with Schema and DOM groups to 
make Schema and DOM XML-Encryption-aware.


3. How will XSLT work with XML Encryption?

I am emphatic that XSLT and XML Encryption must work well together.
However, at this time, I do NOT see a need for XML Encryption to 
provide a mechanism for XSLT such as XML Signature does (as many may
recall, I was a prime agitator FOR including XSLT capabilities in
XML Signature.)  Here's why.  XSLT in XML Signature is used to extract
a subset of a resource's dataset for hashing while leaving the dataset
intact.  In encryption, there is NO need to leave the dataset intact,
in fact, the need is quite the opposite: we want to thoroughly mangle
certain bits of the dataset without losing the outer context of the 
mangled bits.  In the end, this approach is complementary and helpful 
to the XSLT mechanism in XML Signature.

So how will XSLT work with XML Encryption?  Generally,
the way to use XSLT with XML Encryption is to design a stylesheet with
templates that match the replaces the data to be encrypted with 
<EncryptedData> elements.  On the decryption side, one just needs a 
generic stylesheet that matches on <EncryptedData> elements and, using
programming extensions, replaces the <EncryptedData> with the plaintext
XML.

Once we have XML Encryption toolkits, I think experience will validate
the above point of view to the satisfaction of most people.


4. What should be the scope of the XML Encryption document?

Version 1.0 of XML Encryption should meet the encryption needs 
of the common, basic encryption needs of XML systems.  Certain 
applications will have relatively unique needs that will require
proprietary additions to XML Encryption.  Because XML Encryption
will often need to be integrated at a lower level, eg. parsers,
than XML Signature, it makes sense for at least version 1.0 to 
focus its scope carefully; to not do too much or too little.

From the data perspective, I see encryption of whole elements,
element content, attribute values, and external, arbitrary data,
as just the right scope for version 1.0.

Ed