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

http://www.smh.com.au/it-pro/business-it/australian-online-security-startup-wins-singapore-backing-20140505-zr4ow.html

On 5 May 2014, at 6:33 pm, Jiří Procházka <ojirio@gmail.com> wrote:

> 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