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

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

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Mon, 12 May 2014 12:00:56 +0200
Message-ID: <53709BD8.9090900@gmail.com>
To: "henry.story@bblfish.net" <henry.story@bblfish.net>
CC: "public-webid@w3.org" <public-webid@w3.org>
On 2014-05-12 10:57, henry.story@bblfish.net wrote:
>
> On 12 May 2014, at 09:32, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
>
>> On 2014-05-07 11:48, henry.story@bblfish.net wrote:
>>> On 7 May 2014, at 08:42, Anders Rundgren <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

>
> Henry
>
>
>>
>> Anders
>>
>>>
>>> This has been identitified as a key improvement browser manufacturers need to make for privacy reasons.
>>>
>>> Henry
>>>
>>>
>>>> Anders
>>>>
>>> Social Web Architect
>>> http://bblfish.net/
>
> Social Web Architect
> http://bblfish.net/
>
Received on Monday, 12 May 2014 10:01:28 UTC

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