W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2016

Re: Alternative proposal for the form signing using client-certificate

From: Mitar <mmitar@gmail.com>
Date: Thu, 10 Mar 2016 01:05:38 -0800
Message-ID: <CAKLmikOXahHYvn+H-OvR9sZ4FBrPO-3CmCytDtsWbyjP1NLTyw@mail.gmail.com>
To: Crispin Cowan <crispin@microsoft.com>
Cc: "timeless@gmail.com" <timeless@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>

On Tue, Mar 8, 2016 at 2:38 PM, Crispin Cowan <crispin@microsoft.com> wrote:
> Users do NOT understand certs. Do not ask them questions about certs[*]. Ask them in-context questions about nouns and verbs that they are familiar with, e.g. "Do you authorize paying $Foo to <Bar> for product <Baz>?"

In fact it can be even simpler. Browser would just ask:

"Do you want to sign a form and submit it?"

And this would happen when user click "submit" on a form with
signature field. It is pretty clear to the user what is happening, no?

It is pretty close to the "do you want to resubmit the form" on page
reload you can get from the browser.

Then there can be a way for power users to check details, but there is
really no need. Because URL is included, signature cannot really be

> [*] It is fine to provide a UX intended for experts to inspect and manipulate certs to their heart's content. But that does not address secure end-user consent scenarios.

The point is that my proposal has so low misuse threat that consent
can really be as simple as possible. In fact, we could just even sign
always, even without a prompt. Why not? Just sign it. Users do not
care. They are already used to order things by submitting a form. The
only difference here is that you have a proof that they did so by
having a 3rd party verifiable statement.


Received on Thursday, 10 March 2016 09:06:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:55 UTC