[whatwg] Browser Signature Standards Proposal

[Anders Rundgren]

Hi Channy,
May I try to explain how I look on web-forms and digital signatures?

Most people indeed come up with schemes like the one you described
because it seems so obvious.

I work with a different concept which is not really form-oriented,
but rather view-oriented.  This is borrowed from what most e-commerce
sites use today.  First you create an order using arbitrary web
methods including <form>.  Then you typically input credit card
data etc.  Eventually you are faced with a consolidate/aggregated
purchase transaction request which typically is just an HTML page
with *static* information plus an "OK" button.  When you hit OK,
you do not send the HTML page, only an acknowledge of the request
you had on the screen.  Now, how does this map into digital signatures?
The basic difference with respect to the OK button is that the
returned result contains a signature over the view.  The actual
(internal) transaction data is typically not signed since it is
- already is known in advance by the server otherwise
  it wouldn't have been able to create a view to the user.
- may not have any visual representation at all.
What's more, the service also does its own calculation of message
digests of the transaction request view and is thus able to immediately
verify not only the signatures validity but that the user actually had
the proper content in his/her browser.  The signature is subsequently
stored close to the real transaction record for supporting unlikely
(but possible), future dispute resolutions.

There is an inherent problem with your suggested form:

<form name="sendmoney" action="/send.cgi" signed="signed">
<input type="text" name="dollars" value="3.00">
<input type="text" name="account" values="1234567890">
<input type="submt" value="Sending Money!"></form>

because in a real-world case it would probably read:

<form name="sendmoney" action="/send.cgi" signed="signed">
<input type="text" name="dollars">
<input type="text" name="account">
<input type="submt" value="Sending Money!"></form>

which means that you sign data that has not first passed a server's
validation.  Although XForms can do validation, I doubt XForms
are suitable for anything but simple applications. Server-based
validation can also cope with transactional issues that XF can't like
bookings.

Also I wonder what you meant should be sent to the server.
The signed attributes only?  I think this is a half-baked idea since the
rest of the document may contain important data that could affect the
user's decision to sign th data.   The "fine print" for example :-)
If you sign a house contract you don't sign the sales value but
a lot of text and conditions.  Digital signatures should IMHO
afhere to this notion.

In case there would be embedded objects like CSS or IMG in the
HTML page holding the <form> they should also in some way
be signed?  Now we have a brand new format: Signed HTML.
WASP does not need any specific signed HTML because its
method is a bit like S/MIME although in XML.

In addition to that there are some cryptographic stuff that needs
to be addressed which makes the rather innocent "signed" attribute
grow quite a bit.  If you look on the WASP CertificateFilter it is
a good example of how complex it can be to sign.

We also need an attachment feature.  It is a bit unclear how that
could be met with a <form> based approach unless all input is done
in a single form which would be very constraining.

To not be stuck with HTML but also allow MS office, PDF
Open Document we also need some other mechanism.

This is at least how WASP was conceived

In case you have an example of a Korean HTML signature, I
would be happy to get a copy.

Anders

----- Original Message ----- 
From: "Channy Yun" <channy at creation.net>
To: "Anders Rundgren" <anders.rundgren at telia.com>
Cc: <whatwg at lists.whatwg.org>
Sent: Tuesday, October 31, 2006 19:24
Subject: Re: [whatwg] Browser Signature Standards Proposal


Anders and all,

As I said in other thread, I think digital signature must be
standardized for secure and legal assurance of form data and I respect
your issuing and great jobs. But, we can simply think this issue in
range of this group. Most of forms directly go to web server via
urlencoded. If some indicators are given, browsers can execute signing
process.

For example,

<form name="sendmoney" action="/send.cgi" signed="signed">
<input type="text" name="dollars" value="3.00">
<input type="text" name="account" values="1234567890">
<input type="submt" value="Sending Money!">
</form>

When an user clicks submit button, the dialog box will be opened for
selecting the private certificates to be signed. Server can understand
form data and attached signatures signed by browser via SSL.

Or it can be applied each forms.

 <input type="text" name="dollars" value="3.00" signed="signed">

Anyway it is browser's the function of digital signature such as
sign.Text() function. This idea make possible to handle easily them
via form.

Channy


On 9/3/06, Anders Rundgren <anders.rundgren at telia.com> wrote:
> F.Y.I.
>
> I'm sorry about WASP, I was not aware of your activities when I created
> the Web Activated Signature Protocol.
>
> Background:
> http://middleware.internet2.edu/pki06/proceedings/rundgren-websigning.ppt
>
> Minimal technical description:
> http://webpki.org/WASP-tutorial.pdf
>
> The works:
> http://webpki.org/WASP-specifications-2006-08-26.zip
>
> There is [much] more if somebody is interested.
>
> Anders Rundgren
>
>
>
>