Bill,
Yes, that is a possible approach. However, the problem is more that the rest of my application works in JDOM, so it will be modifying other parts of that XML document and then writing it back to a file eventually. So I can write it back to a file, however, I'm worried that it's making enough changes then that it will invalidate the signature.
In my brief
testing so far, I can read in a document, parse it with JDOM, and output it, with no formatting, and read it back into a DOM object and successfully validate it. However, it's interesting that if I apply the pretty printing formatter to that JDOM output, it caused invalidation of the signature later. This confused me because I am using the XML-C14 canonicalization method to create and validate the signature. I'm under the impression that this standard creates logically equivalent docs. If all the pretty print formatter does is indent the text nicely, why is it affecting the signature? Shouldn't the canonicalization take care of this?
Perhaps my only course of action will be to keep the static, signed portion of my XML in it's own file and the dynamic portion elsewhere. However, this seems to partially defeat the whole purpose of the W3C standard.
My larger concern here is that if I can't even work between XML libraries in
Java and get this to work, what's happening to others who are working with web services across languages and libraries?
Thanks for the help,
Tony