RE: CipherReference + Transforms meaning

Blair wrote...
>I don't agree completely.  One of the reasons to use the reference +
>transforms version of CipherData is to handle external, and possibly
>non-XML, data.  The last sentence below implies it is an XML fragment.
>It could just as easily be compressed video (an example you used in the
>past).  In this case, the decrypted data would simply be handed to the
>application.  
>
>This does raise an issue that should be resolved prior to finalizing
>wording.  We have always agreed that the decrypted XML replaces the
>EncryptedData element in the document when: 1)the CipherValue contains
>the encrypted representation; and 2)the type is Element or
>Element-Content.  Should the rules be the same when using the
>CipherReference + Transforms if the type is given as Element or
>Element-Content?  Or does use of the latter representation imply the
>decrypted data is always treated as external to the document containing
>the EncryptedData element?  Should we standardize on one interpretation
>or provide a way to express both?

Yes, I would use the same rules for CipherValue and CipherReference: the
choice between the two should simply be whether the encrypted data (be it
XML or not) is stored inline or not.  Whether you get the data from <CipherValue>
or <CipherReference> is immaterial.

Well, what if the data is not XML, you can't pop a binary GIF into and XML
instance?  Right!  One has to know whether the encrypted data (which could
be an XML fragment) is supposed to be expanded inline or not.  We could
use an attribute on <EncryptedData> or, my preference, is to use the <EncryptedDataManifest>
element I described way back in "http://lists.w3.org/Archives/Public/xml-encryption/2001Mar/0006.html"
(ignore the encrypted attribute value stuff).

The purpose of the <EncryptedDataManifest> element is to say "hey, there
is some external data that has been encrypted for this element".  Note that
this is different from saying "the encrypted XML fragment that belongs here
is stored externally" (which is what <CipherReference> does).

<EncryptedDataManifest> would contain one or more <EncryptedData> elements
(for each external data item), if an <EncryptedDataManifest> element is
the root element, it means that there is no parent XML instance, just that
a number of items have been encrypted and <EncryptedDataManifest> is the
container for them.  <EncryptedKey> elements can also go into the <EncryptedDataManifest>
element.

At the time <EncryptedDataManifest> was being discussed, the list concensus
was that XML Encryption should NOT provide this functionality, the application
should provide its own mechanism for distinguishing between data to be expanded
inline or stored externally.  My view is that having XML Encryption provide
at least a basic mechanism will greatly enhance interoperability.

Ed

Received on Thursday, 14 June 2001 10:26:15 UTC