W3C home > Mailing lists > Public > public-webid@w3.org > May 2014

Re: Question about "TLS CCA Session" versus "Web Session"

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Mon, 12 May 2014 08:36:58 -0400
Message-ID: <5370C06A.20901@openlinksw.com>
To: public-webid@w3.org
On 5/12/14 8:10 AM, Melvin Carvalho wrote:
>
>
>
> On 12 May 2014 13:50, Anders Rundgren <anders.rundgren.net@gmail.com 
> <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>     On 2014-05-12 13:33, Kingsley Idehen wrote:
>
>         On 5/12/14 6:00 AM, Anders Rundgren wrote:
>
>             On 2014-05-12 10:57, henry.story@bblfish.net
>             <mailto:henry.story@bblfish.net> wrote:
>
>
>                 On 12 May 2014, at 09:32, Anders Rundgren
>                 <anders.rundgren.net@gmail.com
>                 <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>                     On 2014-05-07 11:48, henry.story@bblfish.net
>                     <mailto:henry.story@bblfish.net> wrote:
>
>                         On 7 May 2014, at 08:42, Anders Rundgren
>                         <anders.rundgren.net@gmail.com
>                         <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>                             I don't claim knowing everything so please
>                             bear with me when I ask a simple question :-)
>
>                             Using JBoss and Tomcat (java-based)
>                             servers an HTTPS Client Certificate
>                             Authenticated
>                             session created from a browser *never
>                             terminates* regardless of session time-out
>                             settings
>                             because the TLS session has no link into
>                             the Java Servlet web session framework.
>
>                             Due to this neither manual logout or
>                             automatic logout work in such setups.
>
>                             Q1: how do other web-servers enforce
>                             logout from the server-side?
>                             Q2: if other web-servers actually can do
>                             this,  does this require TCP terminate?
>                             Q3: if other web-servers actually can do
>                             this,  logout works formost/all browsers
>                             without specific measures?
>
>                         As far as I can tell a server cannot force
>                         logout of the client, since the browsers tend
>                         to resend the same certificate
>                         to the server. You can only do this with
>                         Firefox which has a Javascript logout call
>                         currently. In my view login/logout
>                         has to be handled by the client in the chrome.
>
>
>                     This is a unique problem for HTTPS Client
>                     Certificate Authentication; no other authentication
>                     method needs modifications of the chrome in order
>                     to perform logout or requires the client
>                     to support session timeout policies.
>
>
>                 That is wrong as a little reflection should show:
>
>                 - Basic Authentication uses the Chrome
>
>
>             True.  However, basic auth is even less popular than HTTPS
>             Client Cert Auth.
>             Form-based login rules on the web.
>
>
>                 - All other current methods rely on cookie based
>                 authentication, and it is problematic to exactly the
>                 extent that
>                    there until recently it was difficult for a user to
>                 control his cookie based personas. This is exactly
>                 what Aza Raskin
>                    was trying to bring into the Chrome with his
>                 "Identity in the Browser" blog post
>                 http://www.azarask.in/blog/post/identity-in-the-browser-firefox/
>
>
>             Fine with me.  If the mechanism is universal it would be a
>             useful option.
>
>
>                     I can though imagine a chrome-based identity
>                     context but it should be optional and universal.
>                     It should probably also address logout to *all*
>                     enabled sites that you have encountered
>                     during your session on the web.
>
>
>                 yes, there are many such features that become possible
>                 once one starts thinking about tying
>                 identity to the Chrome, and putting the user fully in
>                 control of it. Google Chrome's Profiles
>                 are a good step in the direction, but they don't yet
>                 help show which certificates are used,
>
>
>             OK
>
>
>                 which  is important just because with WebID one could
>                 log into all sites with the same certificate.
>
>
>             In theory a singe certificate using WebID could log in to
>             all sites but due to differences in
>             policies etc. this won't happen.  I don't see that as a
>             problem if you have a working certificate
>             selection filter.
>
>
>             Question: where does this leave us?
>
>             Anders
>
>
>         Waiting for Chrome, Firefox, and Opera to catch up with IE
>         (Windows) and  Safari (on Mac OS X, iOS). Now if you want to
>         look at matters through "actual user" lenses, then the total
>         users of IE and Safari completely trump the users of Firefox
>         and Chrome, who for all intents are purposes fall into the
>         "programmer / developer" user profile.
>
>         To conclude, most end-users don't even have a problem. They
>         can work with <http://id.myopenlink.net/ods/webid_demo.html>
>         and switch certificates without restarting their browsers. As
>         for the issues with Certificate selection presentation, that's
>         less of a problem when the Certificate Generator UI aids the
>         user accordingly re., CN attribute values.
>
>         As is often the case, the programmer is making an incorrect
>         assumption about end-users based on the programmers own
>         preferred combination of host operating system, development
>         tools, and test applications (e.g.,, browser in this case).
>         Windows, Mac OS X, and iOS end-users don't have a problem
>         because they use the default browsers provided by the OS.
>
>         If I have <http://id.myopenlink.net/ods/webid_demo.html>
>         tweaked (which I will), such that it tests for
>         Firefox/Mozilla, even users of that particular browser will be
>         able to authenticate without restarting the browser -- since
>         the HTML page served up from the server will include the
>         necessary JS code achieving this goal.
>
>
>     This discusson doesn't go forward.
>
>     Google, Microsoft, PayPal and a lot of other big players recently
>     put their money on U2F which is completely new solution. There must be
>     reasons for not bulding on the already deployed platform, right?
>
>     Not until the WebID folks understand the motives behing the U2F we
>     can expect any progress in this space.
>
>
> WebID + U2F works too, there are many flavours.
>
> WebID + OpenID -- we have working demos of this
>
> WebID + Facebook Connect -- all facebook users have a WebID located at 
> graph.facebook.com <http://graph.facebook.com> which server RDF/turtle
>
> WebID + cookie
>
> WebID + username / password
>
> WebID + OAuth
>
> WebID + TLS
>
> etc. etc.
>
> Just pick your favourite solution and use that.  If there isnt a 
> bridge, build your own.  WebID + TLS is just for those that want to 
> manage their keys on the client via X.509, until Web Crypto API comes 
> out and offers more choice ...

+1

-- 

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





Received on Monday, 12 May 2014 12:37:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:55 UTC