W3C home > Mailing lists > Public > public-webid@w3.org > May 2014

Re: UI for client cert selection (Was: Releasing RWW.IO)

From: <henry.story@bblfish.net>
Date: Mon, 5 May 2014 14:44:33 +0200
Cc: Anders Rundgren <anders.rundgren.net@gmail.com>, Andrei Sambra <andrei.sambra@gmail.com>, public-webid <public-webid@w3.org>, Read-Write-Web <public-rww@w3.org>
Message-Id: <94B4755C-FCDE-4062-9055-18CC2BFC3EBB@bblfish.net>
To: Tim Berners-Lee <timbl@w3.org>

On 3 May 2014, at 20:51, Tim Berners-Lee <timbl@w3.org> wrote:

> On 2014-05 -03, at 10:45, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
>> We can call it whatever we like, the user-experience offered by WebID as featured
>> on http://cimba.co web doesn't meet reasonable user expectations [..]
> So imagine the browser was going to be changed to make that better.
> People seem to widely agree that the client-side cert UI is bad on browsers.

It is worst on Mozilla on all platforms, and on most browsers on Linux that seem to use the same UI that
Firefox does. We have a page with a few screenshots that make this clear:

> Can we at least do a thought experiment to be in a world where it is fixed -- what would that look like?
> Maybe things like:-
> - Allowing the user to click a check box on "Always use this persona (client-side cert) with this web site (domain)"


> - Allowing a preferences access to manage the persona/website allocation matrix


> - Allow more screen space for selecting those certs


> - Allow a user to label, color, and suppress certs in the list


> - By default, not including expired certs in the list

yes, or move them to an expert view.

> - Tracking which persona is in use on this website (only when a user has more than one) in the URL bar

yes, this is very important. Last I saw Apple's Safari always keeps using the same certificate on a web
site once you have chose it, and there is no way to remove it. This should tie in to the feature described
below to logout of the browser.

Chrome's Profiles could do the job here, but I still believe that the URL bar is the right place for additional
information on which certificates are used for a particular web site. The information should be available somewhere
that is easy to recognise and use.

( There is an interesting question as to what needs to be done when a web page open links that cross domains )

> and so on.  Maybe is someone sketched the UI then a browser code could be persuaded to do it.
> It is necessary for existing client side cert sites anyway, and would maybe make the cimba.co experience 
> quite reasonable.

All of those are very good ideas on how to improve TLS certificate . As Melvin pointed out Aza Raskin 
who used to work at Mozilla came up with a very good UI experience sketch.


I would add the following features for WebID enabled certificates that I think would allow browser vendors
to do something really interesting in addition to what they have currently:


Allow a user to logout from a site through the chrome ( I think your points above 
cover that, under the heading of allowing a user to disascociate a user with a persona )
but it is worth adding this as a clear seperate requirement )

Firefox allows JS logout, but that is not satisfactory in my view. A pure chrome logout should (also) be mandated and easy to use.
( for privacy reasons this should be easy to get some political support on )

 Synchronisation of browser info with WebID Profile

This is to tie the WebID enabled certificate to the WebID profile so that:
  - The UI would show information in the certificate profile taken from the WebID profile
  - a one click link to the WebID profile page where the user could edit his profile
This would make it very easy for people to see the relation between their certificate and their profile.
If someone wants to change their profile logo, then the change would appear immediately in the browser
for example. Here I think I agree with Melvin and Nick Jennings.

A lot of collected wisdom is on the wiki https://www.w3.org/wiki/Foaf%2Bssl/Clients


> timbl

Social Web Architect
Received on Monday, 5 May 2014 12:45:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:55 UTC