Please see my responses inline below.
Best regards,
Manoj K. Srivastava
Infomosaic Corporation
Voice: (408) 988-4337
Fax: (408) 516-9427
White
Papers Case Studies and Articles
Confidentiality Notice: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and/or privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, Please
contact the sender by reply e-mail and destroy all copies of the original
message.
From: Anders Rundgren
[mailto:anders.rundgren@telia.com]
Sent: Friday, August 26, 2005 2:05
PM
To: Multiple recipients of list
Subject: Re: "Dry" and
"Wet" signatures - A definition
Hi Manoj,
I'm not completely sure how this works or if we really are
talking about different things. Some questions:
- Is this all (presentation, fill-in, final version,
signing) happening locally?
[Manoj K Srivastava] It is web application so every thing is
generated on the server (remotely) and presented to the user in a web browser
(locally). Signing takes place using either SecureXML Java Applet or SecureXML
ActiveX on the browser side, signature validation and creation of the final
viewable signed document takes place on the server side. Both cases where the
signature is kept separate from the signed data and where they are kept in the
same (XML) document are in use at different customer applications.
- The signature information place for an HTML form,
where is that?
[Manoj K Srivastava] Depends on the form design. It is
simply a visual for the user to know where the signer information will appear
in the final signed document. The HTML/PDF source contains tags which are used
by the server side posting signing process to insert the signer information at
the right place before presenting the signed document for viewing.
To me, it appears that you have defined a specific
signed document format. There is absolutely nothing wrong with that, but
it is also a major reason why complexity can be limited.
[Manoj K Srivastava] On the contrary I am talking about a
generic scheme of things where the original document, which could be Word, PDF,
HTML or any other format, contains known place holders for signature
information visual presentation, which are used during post dry signing processing
for inserting the signer information such that it appears to resemble a signed paper.
In this scheme of things the signing itself can follow a known standard such as
the W3C XML Signature Standard. It is only the part of the application which needs
to present the signed document for human viewing needs to do extra processing
where it must understand the format of the document signed, look for the tag
indicating the placeholder for the visual signature information and insert them
as obtained from the signer’s certificate. The same can be done with
additional transaction data not captured in the web form. In other words, we
are breaking the problem into two pieces: 1. Signing and Signature Verification
2. Presentment of the signed document.
The Dry schemes I currently work with are probably pretty
different to InfoMosaic as they actually separate documents,
signatures, and the optional associated transaction data. Such schemes do
not work in an e-mail work-flow but in a web-based work-flow.
[Manoj K Srivastava] I am talking about web workflow.
regards
Anders
----- Original Message -----
From: Manoj K.
Srivastava
Sent: Thursday, August
25, 2005 19:29
Subject: RE:
"Dry" and "Wet" signatures - A definition
Dear Anders,
Thanks for defining Wet/Dry Web
signatures.
Some of our customers have implemented web
signing using our product in a way which can be called Dry-Wet Signature.
In this case, the user is presented with
an HTML or PDF form, which they fill out and submit. They are then shown the
final version of the form (similar to the “Dry” Signature) and
asked to sign it. The form shown to the user has empty signature fields at this
point. After they have signed the form, the user and others can view the signed
form with signature information filled in the right place. The signed form
shown to the user is dynamically generated using the previously signed form
data and the signature information. So from the end user perspective it is a
“Wet” signature while the signature capture process itself is
“Dry” in nature.
The “Dry-Wet” Web signing
allows for greater flexibility, allows for a standard signature creation aiding
workflow integration and reduces the overall complexity.
Best regards,
Manoj K. Srivastava
Infomosaic Corporation
Voice: (408) 988-4337
Fax: (408) 516-9427
White
Papers Case Studies and Articles
Confidentiality Notice: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and/or privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, Please
contact the sender by reply e-mail and destroy all copies of the original
message.
From: Anders Rundgren
[mailto:anders.rundgren@telia.com]
Sent: Thursday, August 25, 2005
9:46 AM
To: Multiple recipients of list
Subject: "Dry" and
"Wet" signatures - A definition
Dear list,
In a previous posting where I referred to some discussions
concerning a possible Web Sign standards effort within OASIS, "Dry"
and "Wet" signatures were mentioned. Several off-list messages
indicate that these terms need a proper explanation.
This comes to no big surprise as these terms have actually been coined by
myself in the absence of an established terminology in this actually rather
virgin field.
"Wet"
web-signatures
An editable document, be it an MS Word document or an
HTML form with edit fields, radio buttons etc. is filled-in and signed by the
user and then sent to the service provider.
"Dry"
web-signatures
The user is (after an arbitrary interactive process with a
service provider), presented, a static (read-only) document and is
requested to sign it in order to indicate "acceptance". Since
the document actually comes from the service provider, the result sent to the
service provider is typically only a detached signature of the shown document.
Further comments
These schemes represent two different schools, one which
tries to mimic the existing paper form world, while the other scheme is more
aligned with how the web is currently used.
Implications
Superficially these schemes may appear similar, but that is
indeed not the case; there is probably a 10-to-1 difference in complexity
unless you restrict "Wet" signatures to only support a single
document format. The reason for this increase in complexity is that each
document format has its own native signature format (or has no defined
signature format at all), as well as its own input data validation
scheme. Using "Dry" detached signatures, you can achieve the
same thing as S/MIME does, namely document format independence with respect
to the signature process (except for some trivial canonicalizations).
Possible input data validation is assumed to have been carried out in earlier
phases of a web session, using standard web methodology. There are
numerous other implications as well concerning the use of "Wet" and
"Dry" signatures, but these are far outside the range of an e-mail
posting.
Anders Rundgren
Working for a major