I've encountered a strange problem in the process of decrypting a message which had been signed using xml:dsig before being encrypted with xml-security.
The elements wrapping both the signed message and the encrypted message were defined in the same namespace, and given the same prefix: "sp" in this case. For example, the signed payload was wrapped in an element like <sp:SignedPayload xmlns:sp="urn:xml-gov-au:nehta:types:SecuredPayload:1.0"> When encrypted, the encrypted payload was wrapped in an element like <sp:EncryptedPayload xmlns:sp="urn:xml-gov-au:nehta:types:SecuredPayload:1.0"> When I tested the sign-encrypt/decrypt-verify cycle within a Java-only environment, featuring a glassfish V2UR2 server, the process worked. That is, I could sign then encrypt a payload, place that in a web services message (with its own levels of signing and encryption), send that to a glassfish server, where the payload was stored, then retrieve the payload in another WS message. However, when I sent the original message to a WCF server, and it was retrieved using WCF and .NET, the decryption failed. Rather, the decryption was successful, but resulted in an XML fragment with an unbound "sp:" prefix. Sure enough, the xmlns:sp declaration was missing. To isolate this, I changed the SignedPayload namespace and prefix. <sip:SignedPayload xmlns:sip="urn:xml-gov-au:nehta:types:SignedPayload:1.0"> This then gave the same failure on a Java environment. I tested it without the web services stage by a simple direct sign-encrypt/decrypt-verify cycle, and the decrypt threw an exception complaining about the unbound prefix "sip:". I suspect that in the first instance, the profix was being resolved by climbing the tree enclosing the decrypted looking for an xmlns:sp, and finding it on the element enclosing the encrypted payload. Has this behaviour been seen before? -- View this message in context: http://www.nabble.com/Unbound-prefix-after-decryption-tp19626544p19626544.html Sent from the Apache XML - Security - Dev mailing list archive at Nabble.com.
