Re: Aligning WebID with U2F. Was: UI for client cert selection

On 5/5/14 2:05 AM, Anders Rundgren wrote:
> On 2014-05-04 23:36, Kingsley Idehen wrote:
>> >On 5/3/14 11:13 PM, Anders Rundgren wrote:
>>> >>On 2014-05-03 20:51, Tim Berners-Lee 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
>>>>>>> >>>> >>onhttp://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
>>>>> >>> >
>>>>> >>> >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.
>>> >>Hi Tim,
>>> >>
>>> >>The hurdles aren't limited to the UI.  The following bug-report for Android
>>> >>http://code.google.com/p/android/issues/detail?id=38393
>>> >>shows that the server-initiated filtering feature that WebID-TLS presumes is set to "WorkingAsIntended" although it is not even implemented.
>>> >>
>>> >>In the several EU states X.509 client authentication is used quite extensively for on-line banking and e-government services.
>>> >>These systems typically rely on proprietary browser plugins rather than using HTTPS Client Cert Auth.
>>> >>Since plugins are to be "outlawed" by the browser vendors, they are now forced rewriting their systems to invoke local (native) applications to handle the certificate authentication.
>>> >>I.e. they are effectively*giving up on the web*  for the authentication part!
>>> >>
>>> >>Due to this and a bunch of other issues related to HTTPS Client Cert Auth, I believe that we need a somewhat bigger "patch" to actually get anywhere.
>>> >>
>>> >>FWIW, I hereby submit a concept and sample implementation which I believe could be a suitable replacement both for the TLS-solution in WebID-TLS as well as for the proprietary systems used in the EU:
>>> >>http://webpki.org/papers/PKI/webauth.pdf
>>> >>
>>> >>I encourage other developers in this space to do the same.
>>> >>The W3C may then run a "beauty contest" and select a concept for standardization:-)
>>> >>
>>> >>Cheers
>>> >>AndersR
>>> >>
>>> >>
>> >Anders,
>> >
>> >Have you looked at how Safari works? The fact that it now uses a timeout to end TLS sessions, that are lingering or deemed "potentially inactive" ? Have you looked at this UX experience on iOS?
>> >
>> >Just asking as I've looked an the Android and your sketch, but don't sense evaluation of iOS.
>> >
>> >Apple is pretty good at UX. Sometimes they do enough just to be better than the competition, so I do tend to look at them first in regards to UX matters, ditto as the place to trigger changes that ultimately percolate to competitors etc..
>> >
> Kingsley,
> I have not looked into Apple's dealing with TLS sessions or the certificate selection UI, because I don't have to.
>
> The logic behind this somewhat quirky position is that I in similarity to Google, Microsoft, Paypal, ARM, RSA, and most of the EU banks have*rejected*  the idea of using HTTPS Client Certificate Authentication as the foundation for strong consumer authentication.  The motives probably vary, but I think my write-up contains the primary considerations.

I looked up your write up prior to replying. Here are your fundamental 
issues:


. TLS lacks a logout mechanism -- not so on iOS or when using Safari 
(which uses a timeout)

. Currently there is no support for TLS session management in for 
example Java Servlets -- "Java" (to me) is irrelevant

. A bunch of rather tricky and browser-specific workarounds for coping 
with the mentioned issues makes HTTPS CCA integration in web 
applications complex and error-prone -- I find that vague and subjective 
in regards to the problem at hand

. Confusing behavior if the user wants to select another certificate. It 
usually requires you to shutdown the browser due to TLS session 
"stickiness" -- totally speculative in that you assume users cannot (in 
the right context) discern distinct certificates, that's akin to 
claiming that users can't distinguish one identity card from another in 
the real-world (I think you know how to distinguish your Passport from 
your Driver's License, when either is the required Identity Card)

. Limited and non-standardized certificate filtering capabilities leave 
consumers with difficult selection choices -- again, utterly subjective 
and not a strong basis for repudiating what exists

. Essentially zero interest in the TLS community in usability issues -- 
like all communities, state-of-mind is fluid, and eternally driven by 
incentives (e.g., uptake by users driven by a problem e.g., the need for 
verifiable identity that's open and decentralized) .


This problem, like many others, requires a combination of loosely 
coupled open standards and some user education. The "silver bullet" 
approach is flawed and will never work. Users need to understand what 
they are doing. "Granny Software" is obsolete.

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: 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