RE: ACTION-240 :TLS errors...

We should probably add something like that as an example since the
recommendation is open to interpretation (although some may prefer it
that way :).

The recommendation lists 5 requirements:

1. Allow technical user to access details of the error in a secondary
user interface (UI) but hide them in the primary UI.
2. Primary UI security context indictors should reflect the error
without displaying details.
3. Confine technical jargon to the secondary UI.
4. When user is asked to make a decision, explain the risks of each
option presented.
5. Do not refer the user to the destination URL or domain for
assistance.

Here's an imaginary example of how (IMO) a browser maker might
reasonable apply them to a self-signed server SSL cert:

 - On main window display "Security connection error".
 - Allow the page to load.
 - Adjust graphical SCIs (padlock, color bar, speedometer, etc.)
appropriately.
 - If user clicks on the main error message or SCI, pop a dialog box
with tabs for "Cause" and "Risk".
 - If user click the Risk tab, s/he sees an explanation of the risks of
browsing a site with self-signed SSL.
 - If user click the Cause tab, s/he sees technical details about the
server cert and what's suspicious about it.

Mike

-----Original Message-----
From: Thomas Roessler [mailto:tlr@w3.org] 
Sent: Friday, July 06, 2007 1:01 PM
To: McCormick, Mike
Cc: stephen.farrell@cs.tcd.ie; public-wsc-wg@w3.org
Subject: Re: ACTION-240 :TLS errors...

On 2007-07-05 22:37:04 -0500, michael.mccormick@wellsfargo.com wrote:

> I think what you're proposing sounds consistent with the 
> recommendations presented in 
> http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals/CertErr

I'm not sure I can tell from the material in the Wiki what kind of
behavior would be expected from a self-signed certificate.  Mind
elaborating?  Or is that to be covered elsewhere?

--
Thomas Roessler, W3C  <tlr@w3.org>

Received on Friday, 6 July 2007 22:53:43 UTC