ACTION-237: questions to address with Signature 2.0 proposal

Here's a list of a few questions to (hopefully) stimulate the
decision-making process:

- Do the advantages of the proposed redesign outweigh the cost of creating a
significantly different 2.0 specification?

I think the answer to this is yes, because it addresses two issues that I
have major difficulty with today: implementations in more languages, and
improving the ability to understand what's been signed. Streaming is also
addressed.

However, there would seem to be a trade-off against existing implementations
to be weighed.

- Are there use cases precluded by this suggested redesign, and are those
use cases important?

I'm not best positioned to figure out what's missing at this point, but I
think as proposed it's suggesting that the Transforms option would be
limited. But since one of those Transforms is still XSLT, I'm not clear on
whether anything is actually being limited here in practice.

- Is the need for Transforms limited to XSLT and Decryption?

If so, is keeping even those justified? Can't XSLT be made a workflow issue
by signing both a source document and the transform to apply?

- Is the extension model sufficient? Necessary?

It appears that the extension model in this proposal would depend more on
source-level reuse and would require much more careful code design than with
the pluggability/pipeline model of the current spec. This suggests to me
that extensions would be even less likely than currently, but in my
experience the likelihood now is extremely low anyway because of concerns
over interoperability.

-- Scott

Received on Sunday, 22 March 2009 20:12:48 UTC