I strongly prefer number 2. I don't see the problem, though, with
processing multiple levels of encryption. The outer iteration, as defined
in the processing rules for decryptIncludedNodes(X, R), just has us select
an EncryptedData element e in X. Since the result of decryptXML(X, e, C)
replaces X, the next loop of the outer iteration begins with a new X and is
free to select an EncryptedData element e that was not in X at the start of
the previous iteration. If decryptIncludedNodes(X, R) continues until no e
can be selected, then multiple levels of encryption can be successfully
handled.
Ari
>Regardless, I think the current model requires at minimum one of
>the following changes:
>
>1. Stay with the current processing model; that is, for each
>EncryptedData we serialize, wrap, decrypt, insert, parse.
>In this case, we need to respecify Except. The URIs "#foo" and
>"#xpointer(/path/to/enc:EncryptedData)" are same-document references;
>they will never identify nodes in these new documents. Except would need
>to be changed to have an ID reference attribute (although not of type
>IDREF) and we should state that this ID will be used to identify an
>element of type enc:EncryptedData with matching Id attribute in the
>node set being processed.
>
>2. Change to a model where we decrypt all non-excepted EncryptedData in
>the input node set; then serialize, wrap, insert and parse the entire
>node set in one go. In this case, Except URIs will work because the
>references will identify EncryptedData elements in the original document.
>However, multiple levels of encryption will not be decrypted and it
>should be noted that the output node set will be of a different document
>than the input node set.
>
>Merlin