- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Mon, 12 May 2014 08:36:58 -0400
- To: public-webid@w3.org
- Message-ID: <5370C06A.20901@openlinksw.com>
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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Monday, 12 May 2014 12:37:19 UTC