issue: including namsepaces for QName values in c14n output

[Peter Dapkus <pdapkus@bea.com>]

I reviewed draft 14 where issue 95 was addressed and couldn't find any
text introduced to address the issue of namespaces that are non-visibly
used (ie namespaces used in QName values).   The spec should at  least
state the requirement to add non-visibly used namespaces.   Preferrably,
it would provide some detail about how to identify namespaces that are
non-visibly used.   

I think there are a couple of questions to be answered in this regard:

First, does this introduce an additional step to signature validation,
where we validate that all non-visibly used namespaces were correctly
included?  seems like it should.

Second,  how (if at all) can we identify non-visibly used namespaces
without awareness for the messageschema and any extending schemas? 

Requiring awarness of message schema is a bad thing -- it tightens the
coupling between web service implementations for the sender and receiver
by requiring both to be in sync on the message schema and on any
extensions to that schema.   This would be the only place that awareness
of the message schema has so far been required for WS Security
processing.

If we don't require awareness of the message schema, then it seems like
we ought to be very explicit about the algorithm by which we identify
non-visibly used namespaces -- to be sure that we can always get
agreement between the sender and the receiver about which namespaces
should have been included (assuming we also validate the non-visibly
used namespaces).

If we *do* require awareness, then we should probably warn the reader
against extending signed elements even when their schemas allow unless
they're relatively certain that the receiver is aware of the extensions
too.

Finally, I am assuming that we include these namespaces via the
InclusiveNamespaces child of Transform, defined in the Exclusive c14n
spec, correct?

It might also be nice to update the example to demonstrate the inclusion
of the namespaces in the signature.

On today's call, I think I mispoke -- I believe Merlin had agreed on a
previous call to submit text because he had a clear idea for how this
all should be done.  Still up for it, Merlin?


cheers,

-Pete

-- 
Peter Dapkus <pdapkus@bea.com>