- From: Mo McRoberts <Mo.McRoberts@bbc.co.uk>
- Date: Fri, 21 Nov 2014 09:49:21 +0000
- To: Henry Story <henry.story@bblfish.net>
- CC: "public-webid@w3.org" <public-webid@w3.org>
On 2014-Nov-20, at 18:38, henry.story@bblfish.net wrote: >> Mo, could you drill down into the pain points, in order of what you see as the biggest, e.g. auth UI, keys across devices, lost keys, particular browsers, etc. > > +1 that would be very helpful. > It looks like a big issue you have is due to Certificate Authorities. But once WebID removes that, what problems remain? CAs are a very small part of the puzzle, to be honest. The complication they meaningfully add is a one-time affair, and it’s easily managed. The main issues, in no particular order, are:— - Key/cert management functions in browsers are hard for people to find, and very inconsistent between browsers and operating systems Firefox insisting on using its own cert store really doesn’t help matters, especially given that its buried several layers of options deep. Smartphones and tablets are a whole other layer of fun, although there are tools to help. - Cert selection dialogs behave differently between browsers e.g., Safari always lists *all* certs for which you have a private key (including the auto-generated certs for iCloud), whereas Chrome will pay attention to the CCA acceptable CA list, for example. - Stickiness is inconsistent e.g., Safari will re-prompt for cert selection every couple of pages when you’re browsing a secured site, unless you set an identity preference (which is poorly-documented, and can only be done through a separate utility). - Where cert selection is sticky, there’s no user feedback If you use a browser which does remember your cert selection, there’s then nothing to indicate that you’ve actually logged in using CCA, and what cert you’re using, unless the site happens to provide it (which is ‘sometimes’, depending upon whether the site was explicitly designed to work with CCA or pluggable auth or not). - No logging out Solve the lack of browser chrome to tell me that I’m logged in, and you’ve got an easy place to let me log out, of course. This is a bigger deal for WebID than it is for our managed world, but it does bite us from time to time. - No feedback on expiry This one’s a huge deal. For reference, our certs for staff expire after 12 months, and those for third parties after 3 months (and that’s not going to change, as it’s a failsafe against the various situations where revocation might fail to occur). There’s no browser or OS-level indication that a certificate is due to expire soon, or has expired. When you do have an issuer, reminder e-mails have limited effect. When the certs have expired, browser-level responses are typically very opaque: either the cert just disappears from the selection list, or TLS negotiation fails with a meaningless (to the user) error. - Multiple devices Transferring certs between devices is a huge pain, in part because the management UIs are buried deeply. To make matters worse, key material gets copied around, increasing the risk surface. I would much prefer (and this is applicable to WebID — and I’ve talked about it in the past) a scheme where an end-user’s cert is an *issuer* to time-limited, but easily-renewable, subsidiary client certs for each browser/device they use. However, this won’t be possible without fixing the issues with basic certificate user experience, so I don’t have much hope in that changing any time soon. M. > > >> >> Any thoughts on how we could make it better? >> >> >> M. >> >> > On 2014-Nov-19, at 13:16, Kingsley Idehen <kidehen@openlinksw.com> wrote: >> > >> > On 11/18/14 9:42 PM, Sandro Hawke wrote: >> >> On 11/12/2014 01:01 AM, Anders Rundgren wrote: >> >>> On 2014-11-12 05:36, Sandro Hawke wrote: >> >>>> On 11/10/2014 06:39 AM, Melvin Carvalho wrote: >> >>>>> Just wanted to highlight this interesting work from sandro >> >>>> >> >>>> Thanks. I should say the design came out of discussions with Andrei Sambra, >> >>> > trying to avoid the problems with poor browser support of client certificates. >> >>> >> >>> Sandro, that's a very interesting statement since the W3C is just about to launch >> >>> a continuation of WebCrypto which indeed may be focused on certificates and browsers! >> >>> >> >> >> >> I'm just speaking for myself as a user and software developer; I'm not involved in that W3C work. My feeling is the UX is terrible. My understanding is the only people who ever use it are people without a choice, like enterprise employees and university students. What fraction of consumer websites use client certs for user authentication? I've never seen one. I think that's because the UX is so bad. >> >> >> >> -- Sandro >> > >> > Sandro, >> > >> > If users are clueless about what they are doing, no amount of UX + UI will solve that. This issue isn't just about browser implementations, its about the combined effects of understanding (on the parts of users and app developers), UX, and UI. >> > >> > Focusing on the "UI/UX is bad" narrative will not fix anything. Which is akin to the "RDF tools are bad" narrative. >> > >> > Why don't we try a little harder in regards to exploiting the pinhole that TLS CCA offers? We've done that, and had success [1]. >> > >> > Users don't have a major problem with TLS CCA once they understand what's happening. Like many things (in my experience) its developers that are once again jumping to their own conclusions on behalf of end-users. >> > >> > >> > [1] http://youid.openlinksw.com -- Certificate Generator that produces Certs that make TLS CCA interactions easier to understand (New HTML version will soon be released) . >> > >> > -- >> > Regards, >> > >> > Kingsley Idehen >> > Founder & CEO >> > OpenLink Software >> > Company Web: http://www.openlinksw.com >> > Personal Weblog 1: http://kidehen.blogspot.com >> > Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen >> > Twitter Profile: https://twitter.com/kidehen >> > Google+ Profile: https://plus.google.com/+KingsleyIdehen/about >> > LinkedIn Profile: http://www.linkedin.com/in/kidehen >> > Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this >> > >> > >> >> >> -- >> Mo McRoberts - Chief Technical Architect - Archives & Digital Public Space, >> Zone 2.12, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA. >> >> Inside the BBC? My movements this week: http://neva.li/where-is-mo > > Social Web Architect > http://bblfish.net/ > -- Mo McRoberts - Chief Technical Architect - Archives & Digital Public Space, Zone 2.12, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA. Inside the BBC? My movements this week: http://neva.li/where-is-mo
Received on Friday, 21 November 2014 09:50:32 UTC