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

On 5/5/14 7:46 AM, Kingsley Idehen wrote:
> 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)

To verify my point, you can try our WebID verifier [1] using Safari 
and/or iOS. Note, I've tried yours which basically mandates G+ identity.

Initially, simply opt to "Cancel" when the TLS CCA UI is presented. 
Under normal circumstances, you will not be able to re-use this page 
without starting a new TLS session, which is achieved by quitting and 
restarting your browser. In the case of Safari, you simply wait a 
little, and repeat en route to a TLS CCA challenge.

Not being able to configure the timeout (on Mac OS X or iOS) is the only 
problem I have with the current implementation by Apple.


Links:

[1] http://id.myopenlink.net/ods/webid_demo.html -- my example which 
have varying behavior across browsers (e.g., Chrome on Mac OS X or 
Android will require a restart, but no so when using Safari on Mac OS X 
or iOS)

[2] https://mobilepki.org/webauth/ -- your example

-- 

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