Hello, I think I made the change so I will try to defend it, first of all the use of KeyInfo out of a Signature it is not a use case I was looking to. So perhaps we break it as we don't look at it. And sadly the old api is full of internal objects that can be use external. And I see KeyInfo like that. So in order to fix, can you write a test case that fails and submit a bug, I will update the code in SVN head. Thanks, Raul
On Fri, Oct 3, 2008 at 4:31 PM, Werner Dittmann <[EMAIL PROTECTED] > wrote: > Scott Cantor schrieb: > >> >> Well, the bug is holistic. What I mean, and this is what I meant in my >> original comment, is that the bug is a consequence of the inconsistent XML >> handling across the range of libraries. It could be viewed as a bug in >> lots >> of places. >> >> In this specific case, I think it's probably easy to argue that the xmlsec >> library has no reason not to declare that namespace, I suppose, but >> ultimately >> what xmlsec needs to do is define the contract...what is it prepared to >> promise about the DOM it gives you? >> >> > Well looking at the documentation of the KeyInfo class it says that it will > look for "ds:KeyInfo" when constructed from an element. This is missing > when > "creating from scratch" but one can assume the KeyInfo is somewhat > symmetric > in its usage, thus also takes care of the ds: and namespace handling. IMHO, > if an element creation class has do deal with specific and well defined > namespaces > that it should be the task of this class to take care of this. KeyInfo > class > creates an element with a namespace prefix, thus it should also add the > necessary > namespace attribute to it. > > In WSS4J we do it similarly: we return a full Doc tree where elements have > their associated namespaces attributes thus the application does not need > to > know about the specific/efined namespaces. > > At least it seems that this modification in xmlsec-1.4.2 has some impacts > on other > applications as well because this modification broke an "assumed" contract. > > Regards, > Werner > > > You have to work from that contract, or (as in the case of OpenSAML) build >> your own XML processing model that takes the responsibility on. >> >> But it's also too easy to say "the caller has to fix up namespaces", >> because >> unfortunately those namespaces are intrinsic to the signature process. You >> can't just add them later and expect it to work. >> >> -- Scott >> >> >> >> >
