Re: Prefix rewriting considerations

> This depends on the scenario. If the XML Signature is intended to be
> placed and verified on a single document, there is no need to rewrite
> the prefixes at all, agreed. However, if you want to "recycle" a
> signature, e.g. use the same signed fragments of an XML document 
> in new documents (e.g. data variables in SOAP messages of Web Service
> compositions), you might run into problems with the prefixes 
> chosen on signature application.

Exclusive c14n already handles this use case. Where it has problems is
with QNames in content, because those have to be handled "inclusively"
to get around the problems with how it's defined. That creates its own
problems by reintroducing the leakage issue, so my suggested fix is to
enable the signer to identify those QNames (where possible) and eliminate
a lot of errors that way.

> The complete "visibly utilized" stuff (that actually made EXCC14N rather 
> complex) can be omitted, since you don't need the namespace declarations
> anymore.

It doesn't seem terribly complex to me, but I think the main reason for that
approach was limiting size, and the changes required to a document to put
it into canonical form. Whether that's "legitimate" or not is worth discussing.

> well, the tradeoff here is either dealing with some attributes or
> dealing with lots of namespace mappings in XML subtrees. I think it
> largely depends on the scenario, but I have to admit you're right:
> PFC14N is not suitable to support all use cases.

I guess maybe the question is whether it fits into one of the proposals
for prefix rewriting, or is maybe a third option (suitably modified to handle attributes
and QName content).

But since I'm still generally skeptical of rewriting and don't think it's strictly needed,
I probably wouldn't be driving that conversation.

-- Scott