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

On 05/04/2014 05:13 AM, 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
>>> 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
>>
>> 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!

Hi everyone. Anders, I might be wrong, but I think the banking/e-gov use
case is quite different from the major WebID use case - WebID as a
single sign-on (SSO) solution.

I think the banks supply their own proprietary browser plugins because
the problem they are solving is safely using the certificate established
just for their use (one website), while WebID needs a widely available
client software with certificate selection UI which the users trust (so
it is not supplied by websites), because they need to be able to trust
it with their certificate which they use potentially on 100s of
websites. Also doing something like the banks do (one-website
certificates), would be impractical for WebID even if it was done by a
standardized browser plugin, as there would be new UI/communication
headache with binding the certificate generated for a particular
website, with the WebID profile hosting solution of choice.

Best regards,
JP

> 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
> 
> 
>>
>> timbl
>>
>>
>>
>>
>>
> 
>