- From: Timothy Holborn <timothy.holborn@gmail.com>
- Date: Mon, 12 May 2014 23:41:52 +1000
- To: Anders Rundgren <anders.rundgren.net@gmail.com>
- Cc: Melvin Carvalho <melvincarvalho@gmail.com>, Kingsley Idehen <kidehen@openlinksw.com>, public-webid <public-webid@w3.org>
Is authentication / (web scale) platform security actually carried out at the cpe (customers premises equipment ) level, or in a data-centre somewhere in the majority of occasions, for users, who we hope to provide cloud storage, capable of rww, and perhaps alternatives to social network silos, etc.?? Has anyone done calcs on how these systems may provide (without advertising or data mining subsidies) the lowest cost of ownership to users? In countries or places where users have infrequent access to advanced computer terminals (as may be required to update, modify settings, or carry out more advanced tasks than say, is possible on their phones) how are these services made accessible? Facebook, google, almost all other web2 social network silos (web mail systems, etc.) generally provide systems that are freely provided, with no monthly bills or expectations. Can forget about an account an log into it years later (do long as you remember the access details... "Have you got the keys"). Whereas, even in the USA - when the gfc hit, I hear streets of houses were for sale. Data, one might consider, to be more valuable than a house. At least the resume, and supporting documentation one might suppose... Perhaps in future the digital contract for the car, or the vehicle repair logs filed digitally... If the "banks" fall over, (did that happen in Greece?) how can citizens still ensure accessibility? Do they have to pay more? Challenges in real terms IMHO. Anders, see my $0.02 below... :) > On 12 May 2014, at 10:24 pm, Anders Rundgren <anders.rundgren.net@gmail.com> wrote: > > Melvin, > > Of course you can use whatever "auth" method you feel suitable but that won't lead > to interoperability and then the market might as well continue using centralized > IdP schemes like Google. > Google does auth which then enables users to use services similar to rww, however using google drive, plus, and other google (centric) services. Much of what google does provides a good example along the lines of what rdf / semantic web (graphs rather than relational db's) groups seek to create. However, it's a proprietary method. Can't load up my own google drive on my own shared hosting / VPS services (yet, perhaps). Other examples of google investments include schema.org and freebase.com (I think that's the tld). Google does good, but it should be one alternative in a field of market based solutions (inc. Some solutions that are free software / open-source) > That U2F is a suitable replacement for the (pretty much failed) WebID-TLS scheme > is something I wouldn't bet on. The philosophy between U2F and WebID are quite > different. > WebID as is (so confusingly) stated is simply a turtle (serialised rdf) uri / http document. (I think most often by Kingsley - who doesn't say it in a confusing way, nor does the spec / Henry's work. It's just seemingly two concepts), that provide secure web-scale preferences. WebID auth (currently preferences as specifically x509v3 with subject alternative name inclusion of a FOAF document) is a different thing. (Hammer away if I got it wrong...) I imagine, the WebID standards concept could be adapted to alternative auth. Methods. I also imagine the question that should be posed, is what would any alternative auth. Method, need to do to become WebID compatible. Perhaps the WebID element could be pushed to the web? (IE: the rww server?) I'm really not sure what is possible, and what is not possible. If a user has a static IPv6 address, can that be linked to a WebID? What if they've got a subnet? Perhaps it could be issued with the lease, entered into DNS. But then, the visitor issue also applies. Unless it's the webserver (ie: an rww compliant server) that's got the addressing done. Perhaps it's as simple as a DNS entry, with DNS-sec. I'm not sure how many w3 groups are focused on the identity issue; but it's both a big one, and one that many internet users are seeking solutions for, via open standards (no golden handcuffs). Timh. > Anders > >> On 2014-05-12 14:10, 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/ <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 <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 <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 ... >> >> >> Anders >> >> >> >> -- >> >> Regards, >> >> Kingsley Idehen >> Founder & CEO >> OpenLink Software >> Company Web:http://www.openlinksw.com >> Personal Weblog:http://www.openlinksw.__com/blog/~kidehen <http://www.openlinksw.com/blog/~kidehen> >> Twitter Profile:https://twitter.com/__kidehen <https://twitter.com/kidehen> >> Google+ Profile:https://plus.google.__com/+KingsleyIdehen/about <https://plus.google.com/+KingsleyIdehen/about> >> LinkedIn Profile:http://www.linkedin.__com/in/kidehen <http://www.linkedin.com/in/kidehen> > >
Received on Monday, 12 May 2014 13:42:24 UTC