RE: Clarification on 4.3.3.1 -- elided URI attributes

Donald,

> As a WG member, I oppose this change. If you are being grossly
> application dependent, you can always just have one Reference where
> the application magicly knows how to construct a composite TLV encoded
> octet string or the like with all the data you want to sign.  Or just
> forget about using the XMLDSIG standard at all.
> 
> I would assume the way some XMLDSIG libraries would work is that you
> give them the Signature element and they use a call back to get the
> data based on the URI. Under such an arrangement, there is no problem
> with application dependent URIs like "x:1", "x:2", etc. And the
> application could know what to do for a special callback indicating no
> URI. But how could it work for multiple call backs for no URI? After
> all, the XMLDSIG library isn't constrained to do these Reference call
> backs in any particular order. With multiple null URIs there would be
> no way to know which Reference a call back was for.

I cannot see your point. It is no technical problem to design the call-
back in a way to deal with the situation drafted by you. For instance
the library could provide the position of the particular <Reference>
within the sequence of <Reference>s, or instead of providing a null
URI, the library could provide a proprietary URI indicating the posi-
tion within the sequence of <Reference>s, such as "myProt:pos1".

On the other side, I see no reason to allow an empty URI in a 
<Reference> at all, since you can solve all those scenarios with
proprietary URIs.

But that are all minor issues. The most important point I think is
that the specification reaches Recommendation status asap. If changing
anything here leads to further delays, I am strongly opposed to such
changes.

/Gregor

Received on Friday, 12 October 2001 19:02:32 UTC