Maybe I'm confused, but as far as I can make out, PenOP's collection
of "90 handwriting metrics" is being used as a poor man's version of a
"certificate" or (more accurately?) as a "salt" value, and one which
some claim is not well chosen.
In any event, the actual signing is still done using hashing and
encrypting: without the crypto in step 3, the PenOP scheme couldn't
produce a useful signature -- even for the stated target market of
low-value, high-volume transactions. The key for doing step 3 still
has to come from someplace, though, and the crypto algorithm is itself
unspecified.
Framed this way, I don't understand how PenOP's scheme doesn't fit, so
I don't understand what the issue is. As Phill points out, we will
want to permit arbitrary signing schemes and PenOP's scheme is
basically just one more member of the herd at this level.
For the sake of ensuring interoperability, we need to specify a (set
of) "MUST" algorithms for signing, none of which should be proprietary.
Hence, while we may try to allow something like PenOP's proprietary
"signing" operation, we obviously can't make it an explicit part of a
Signed XML spec. As Phill also points out, though, there are other
proprietary biometric "signing" schemes lurking out there, so PenOP's
is undoubtedly only the first one we've seen. So, I think we will
have to somehow accommodate these and other schemes.
I think this means we'd need to have a pointer in the signature block
to what one needs (when it's something other than the default) in
order to validate the signature. This pointer could be a URI, an
OID or ... Other than saying that the pointer refers to some external
resource and that it should be unique, I don't think we'd need to
define any of the semantics involved because these will invariably be
application-specific.
On the other hand, it might be useful to include a syntax (preferably
by reference) for one or two common reference types, plus a "quoted
blob" to allow for new or proprietary references. One obvious problem
I see with a "quoted blob" is that some application developers would
undoubtedly yield to the temptation to use this to embed executable
content in signature blocks.
--Bede