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

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

From: Nick Jennings <nick@silverbucket.net>
Date: Mon, 5 May 2014 13:42:14 +0200
Message-ID: <CAJL4Wtb7PVnyAo-nEXTHoLnvtXG_HoVg2EoWGJW3Mp4QsA2RYw@mail.gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Cc: Tim Berners-Lee <timbl@w3.org>, Anders Rundgren <anders.rundgren.net@gmail.com>, Andrei Sambra <andrei.sambra@gmail.com>, public-webid <public-webid@w3.org>, "public-rww@w3.org" <public-rww@w3.org>
... and some form of syncing as Sandeep has pointed out. Though I wouldn't
put that as a base requirement.

On Mon, May 5, 2014 at 1:37 PM, Nick Jennings <nick@silverbucket.net> wrote:

> On Sun, May 4, 2014 at 11:59 AM, Melvin Carvalho <melvincarvalho@gmail.com
> > wrote:
>> On 3 May 2014 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
>>> 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
>>> - Tracking which persona is in use on this website (only when a user has
>>> more than one) in the URL bar
>> When geolocation was added to the browser, it was possible for browser to
>> request your location.
>> Perhaps requesting your identity can work the same way.
>> - Allow Once
>> - Allow always for this site
>> - Dont allow
>> I suspect most people will start with a single identity, and if it
>> catches on might stabilize around 2-3, just like email address usage.
>> For those users you could have a selection process that lets you select a
>> name/avatar card like picture that you'd like to present to that site.
>> Mozilla actually coded this up and were going to take it forward as
>> "Identity in the browser" some years ago.
>> http://www.azarask.in/blog/post/identity-in-the-browser-firefox/
>> Unfortunately this solution never made it out of mozilla labs.  Instead,
>> they went with verified email (Persona), which did not gain the adoption
>> that Mozilla was aiming at.
>  I agree, I think the concept of user sessions within the browser has
> started to catch on more since Google Chrome implemented this (a nice
> little avatar and all your session information is compartmentalized into
> that profile). It seems natural to extend this with WebID certs. I think
> one of the major drawbacks with the existing client-side cert system is the
> idea that you have a bunch to choose from, they are not human-readable
> friendly, and there is no visual feedback *in the browser*  to what
> actually happens after you select a cert. This makes the whole thing
> extremely obtuse and an all around bad user experience.
>  So, as Melvin describes, an avatar/name to go along with your browser
> session, one cert per-persona (If you want multiple ones, you make multiple
> users for that browser), and a visual indication of whether you are logged
> in or not *in the browser chrome* not necessarily on the website. This
> compartmentalizes things in a much more elegant way and makes it easier of
> the user to understand what's going on, their current state, regardless of
> a websites UI (or lack thereof).
> I really like the idea of WebID but currently find it too frustrating to
> use - which is doubly frustrating because it seems like a couple of really
> simple fixes could make it infinitely better.
> -NIck
Received on Monday, 5 May 2014 11:43:14 UTC

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