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

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

From: Timothy Holborn <timothy.holborn@gmail.com>
Date: Mon, 12 May 2014 18:40:07 +1000
Message-Id: <94E15C62-74B8-434F-88D9-60BF88826D61@gmail.com>
Cc: "henry.story@bblfish.net" <henry.story@bblfish.net>, "public-webid@w3.org" <public-webid@w3.org>
To: Anders Rundgren <anders.rundgren.net@gmail.com>

Sent from my iPad

> On 12 May 2014, at 5:32 pm, 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.
> 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.


Not if it's used to ID IoT rather than foaf...  

Still helps to define a specific IoT device, connected to specific authorised foafs...

Type 1 auth - user profile set for IoT x509 cert

Type 2 - user profile new to IoT x509 cert

Diff. On rww.io (etc);  secondary tls inc. Foaf between cloud storage & app?  Not sure.  Theory is foaf lives on cloud account, not browser auth. To cloud rww storage...  

> 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/
Received on Monday, 12 May 2014 08:40:39 UTC

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