<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<div class="moz-cite-prefix">On 9/5/19 5:03 AM, DD K wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAD3X5rZ9+hUBRN0Y7oAMj3qdYmLZbmdBhb1=sfy6oiYh7bdPWQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"> But the thing is still the error persists. And
I've debugged to see whats going on internally and I found that
at class net.shibboleth.utilities.java.support.xml.NameSupport
on the code snippet :
<div><br>
</div>
<div>The <i>namespaceURI</i> for <i>namespacePrefix</i> <b>ds</b>
is <b>null</b>. During debug I've manually set it to "<i><b><a
href="http://www.w3.org/2000/09/xmldsig#"
moz-do-not-send="true">http://www.w3.org/2000/09/xmldsig#</a></b></i>"
then there won't be any errors thrown and it runs fine. Any
idea whats happening?<br>
</div>
</div>
<br>
</blockquote>
<p>I'm not 100% sure, but I suspect it might be related to the round
tripping you're doing in your testing. Probably something related
to the DOM being re-used is causing a problem with all the complex
namespace handling we have to do. The 'ds' prefix for XML
Signature is a common one and ought to be in the
EncryptedAssertion in the correct place. We know it is in real
world use cases, this code has been in production use for over 12
years or so.<br>
</p>
<p>For this kind of artificial testing, I'd try my earlier
suggestion: After encryption, completely marshall and serialize
the EncryptedAssertion to something, like a temp File or byte[];
then parse the File/byte[]/etc and unmarshall to get a fresh new
EncryptedAssertion, and then decrypt that.<br>
</p>
</body>
</html>