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
>>
>>
>>
>>
>

Reply via email to