On 28.03.2010 06:19, Nelson B Bolyard wrote:
The sequence of events in the dialog is likely, IMO, to give the users the
impression that client authentication is a user-initiated act, rather than
a server initiated act. It seems to say to the user, "if you want to
authenticate to this server with your cert, you select your cert and click
here".
yes: ... you click here (the icon), you select your cert, then the
browser or the user will reload ...
I gather that the intent is that the browser will (re)initiate an
https request to the server(s) in response to that click.
yes, after the user selects a different authentication (use a cert, use
a different cert, don't use a cert) in the dialog.
But there is no
assurance that the server will request client auth when the subsequent
requests are sent.
I think this is likely to lead to a lot of inquiries/complaints from users,
asking "why can't I authenticate to this site whenever I want to?".
Thanks for making us aware of this scenario (server requests auth on
first connect, but doesn't on subsequent connects).
I think we can address your scenario with the following application
behaviour:
If we're connecting to a site and the site requests client auth, we will
look up our stored configuration. If we can't find any stored
configuration for the site, then, do the same as we do today, and show a
prompt (the same prompt as used for the configuration, which is similar
to today's client auth prompt).
It will be a one-time automatic prompt (for this site).
The action chosen by the user (use or cert or do not use a cert)
can be remembered as the future default (for this site).
In the future, if the user connects to the site, we don't need to bother
the user with a prompt. We'll either use a cert or not use a cert, and
indicate it showing the respective icon (allowing the user to click and
change her mind).
Would this work?
In addition, a site that requests a client cert only once, and on
failure will never ask again, probably isn't very smart.
I'd expect any reasonable site must deal with the possibility that a
user doesn't send a cert on first attempt. A site must make it possible
to retry in some way.
If the user notes the request to authentication, then configures to use
a cert, then uses the site's mechanisms to retry, I think we have
achieved our goal.
Does this make sense?
Also, what are those icons supposed to represent?
The first icon is supposed to show a closed barrier, like the ones used
at streets on border crossings, or at railway crossings. It means site
requested a cert, but we're not sending a cert to the site.
The second icon is supposed to show an open barrier combined with a
passport. It means a site requested a cert, and we're sending a cert.
It looks to me like a
book and a light beam, where the book eventually interrupts the light beam,
much as objects on a conveyor belt at a supermarket checkout break the
light beam which stops the belt. Perhaps that's not what it's showing me,
but if it is, that doesn't suggest to me anything having to do with
authentication. But this is a minor point. I'm sure that suitable icons
can be found.
I'm not a graphics artist. I don't propose to use these icons as is. But
people asked for a mockup, and here you are. :-)
Kai
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
