- From: Ben Laurie <benl@google.com>
- Date: Wed, 26 Sep 2012 13:29:03 +0100
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: Henry Story <henry.story@bblfish.net>, public-webid@w3.org, Andrei Sambra <andrei@fcns.eu>
On 26 September 2012 13:09, Melvin Carvalho <melvincarvalho@gmail.com> wrote: > > > On 26 September 2012 13:59, Ben Laurie <benl@google.com> wrote: >> >> On 26 September 2012 12:10, Henry Story <henry.story@bblfish.net> wrote: >> > Answer to the questions and summary at the end. >> > >> > On 26 Sep 2012, at 12:14, Ben Laurie <benl@google.com> wrote: >> > >> >> On 26 September 2012 10:56, Henry Story <henry.story@bblfish.net> >> >> wrote: >> >>> >> >>> On 26 Sep 2012, at 11:15, Ben Laurie <benl@google.com> wrote: >> >>> >> >>>> On 26 September 2012 09:54, Henry Story <henry.story@bblfish.net> >> >>>> wrote: >> >>>>> >> >>>>> On 26 Sep 2012, at 10:42, Ben Laurie <benl@google.com> wrote: >> >>>>>> >> >>>>>> Once more, I remain unenlightened about the answers to my >> >>>>>> fundamental questions. >> >>>>> >> >>>>> Can we perhaps start back at your fundamental question again? We got >> >>>>> sidetracked here a bit because of my-profile.eu >> >>>>> no working well for you. >> >>>>> >> >>>>> The last thing I remember you stating is that authenticating with >> >>>>> one ID across multiple sites is in your view a horrendous thing. Is that the >> >>>>> fundamental problem? >> >>>> >> >>>> One of them. And not just my view - the view of many. Here's a >> >>>> presentation from a colleague that illustrates our thinking on the >> >>>> use >> >>>> of client certs for authn: >> >>>> http://tools.ietf.org/agenda/81/slides/tls-1.pdf. >> > >> > Ok so this paper is about "Origin-Bound" Certificates. The problem is >> > that they are trying to use certificates the way one uses cookies. A >> > hidden mechanism for a server to identify you securely from on session to >> > the next. And this is not what we are interested in here, since we are >> > interested in cross site identity ( selectable by the user in a way which he >> > is at all time in control of) >> > >> >>>> >> >>>> In case its not obvious, the problem is that its a massive privacy >> >>>> invasion. >> >>> >> >>> Well as I pointed out, it is not a problem if the user controls and is >> >>> aware of the identity he is revealing on each site. This is a simple User >> >>> Interface issue which Aza Raskin showed in 2009 how to solve >> >>> >> >>> >> >>> https://blogs.oracle.com/bblfish/entry/identity_in_the_browser_firefox >> >> >> >> Manually choosing one of hundreds of certs sure sounds like a problem >> >> to me! >> > >> > You would never have more than a handful to choose from, and your >> > certificates could >> > default to being the last one you used for a site. >> > >> > The reason you are thinking you need 100s of certificates is probably >> > because you think >> > you need a certificate per site. This misunderstanding is deeply >> > ingrained it seems. >> >> It is not a misunderstanding, it is a requirement! You think I'm OK >> with all sites being able to link me up: I'm not! > > > Ben, doesnt google do this already. I see "SIgn in with Google" button > across the web. I presume that will share an identity across different > domains, much like OpenID or Facebook Connect. It isn't _like_ OpenID, it _is_ OpenID. And yes, Google does do it already. I'm not a fan, and it seems neither is most of the world, which is kinda my point. > Similarly the ubiquitous google +1 buttons have similar privacy issues. Many things have privacy issues, but google +1 buttons are not for login. > Is one of the issues, as mentioned in the IETF document that the UI pops up > BEFORE you have had a chance to view content? Not sure what you mean here. Certainly sites like to have some control over the user experience, and this is another issue with client certs - you select them before the page loads. Is that what you meant? >> >>> and which for which there is a bug open in pretty much every browser, >> >>> e.g.: Chrome >> >>> >> >>> http://code.google.com/p/chromium/issues/detail?id=29784 >> >>> >> >>> So does the above paper take into account that the user could be aware >> >>> of the identity >> >>> he is using, and control it? >> >> >> >> The above paper uses a certificate per site. Identity is controlled in >> >> Chrome by using the "Users" feature. >> > >> > Ah yes, you have origin bound certificates. That has a use, but not one >> > if you wish >> > to link information up between web sites. >> >> Well, now we get to the core: you want to allow linking. Fine, in its >> place. But this is not a good property for a general-purpose login >> system. >> >> So, if you want me to replace login with WebID, then you need to have >> a good story around _not_ linking, also. >> >> >>> Btw. if you consult the spec you'll see that all a user needs to >> >>> publish to the world >> >>> is his public key >> >>> >> >>> >> >>> http://www.w3.org/2005/Incubator/webid/spec/#publishing-the-webid-profile-document >> >> >> >> Publishing all your public keys would defeat the purpose of per-site >> >> certificates - unless you publish each on a different page. >> > >> > We here in the WebID group are not speaking about per-site certificates. >> > Our core model is one where one certificate can be used on many sites. Per >> > site certificates give you not much more than a cookie. That is an >> > orthoganal issue. >> > >> >> >> >>> All the rest can be access controlled. >> >>> >> >>>> >> >>>> Next: >> >>>> >> >>>> 1. Usability in the browser is only part of the problem. But >> >>>> nevertheless it remains a problem. >> >>> >> >>> A problem that browser manufacturers can fix, pretty easily, and which >> >>> is even going to be a legal requirement for them to do, as was >> >>> explained >> >>> at the IETF summit in Paris earlier this year. >> >> >> >> Oh really? Got a link? >> > >> > This was organised by the IETF SAAG ( Security Area Advisory Group ) >> > http://www.ietf.org/mail-archive/web/saag/current/msg03614.html >> > >> > But you should not be surprised. Think of it: the Europeans take privacy >> > seriously. >> > Browsers can make people aware of the privacy on each site. The law >> > requires that >> > if possible things be done. It is possible. QED: do it. >> >> I am a European, and I do take privacy seriously. Perhaps you'd like >> to explain why privacy should not apply to WebID? >> >> BTW, this law is in effect now and it does not require anything of >> browsers. >> >> >>>> 2. If am all signed up to WebID and I get a new device, how do I get >> >>>> it signed up? I know your stock response is "you just go through the >> >>>> flow again" - once for every site I'm registered with - using what to >> >>>> identify myself? Bear in mind that there has to be a per-site >> >>>> certificate. >> >>> >> >>> Ah! Here we get at the crux of the misunderstanding!!! >> >>> >> >>> There does not have to be a per site certificate when WebID is used. >> >>> This is what Linked Data permits us to avoid. This is why WebID is so >> >>> useful. It is why X509 failed as client certificates. Indeed if all you can >> >>> use a client certificate for is your own web site then it has very little >> >>> use - you might as well use a cookie, or a password. But if you can then >> >>> connect to other sites, and login in one click, then things are different - >> >>> completely different. >> >> >> >> If your answer is that WebID relies on me giving up on not being >> >> linkable across all sites, then we may as well stop talking now - >> >> WebID is useless. >> > >> > It does not rely on you giving up not being linkable across all sites. >> > It allows you to link when you want to. (see the browser issues above) >> > There is a world of difference between those positions. >> > >> >> But even for a single certificate you have not answered the question. >> > >> > see answer 5 below for the detailed answer. >> > >> >> >> >>>> 3. Related: if I lose all my devices, how do I recover? >> >>> >> >>> If you still have your server you go there and remove all public keys. >> >>> If you are using a service provider at a university you go and see him and >> >>> tell him to remove all your keys. If you are at Google, then you get hold of >> >>> the hotline? How do you do it now? >> >> >> >> What? Users have to have servers? This is clearly a non-starter. >> > >> > No they don't have to have servers, and I never said so. >> > >> > Notice the "if" in "If you still have your server" ? >> > And the "If" in "If you are using a service provider" ? >> > And the "If" in "if you are at Google" ? >> > >> > Unless you think that those all are the same - ie you work at Google - >> > then you will see that this is a choice left up to the end user. Does it >> > bother you that I could have my own server? >> >> If your solution requires Google to run a call centre, then Google >> will not use it. >> >> >> Now, you login using your password, just as you have always done. This >> >> is one reason passwords won't go away easily - they're only tied to >> >> me, not my devices. >> > >> > We never said that you need to get rid of passwords. It is just that >> > with that certificate you no longer need to login with a password to any >> > other site. And probably won't need to login with a password to your own >> > site other than in a case of disaster. >> >> So the usability problem here is that a password I do not use >> regularly is a password I cannot remember. >> >> > There is also the possibility of having one time passwords, which I >> > think Google is working on too. And standards like OATH >> > >> > http://www.crypto-stick.com/2012/OATH-One-Time-Passwords-Allow-Login-to-Gmail-Dropbox-AWS >> >> I believe we actually use OATH. One time passwords are already rolled out, >> btw. >> >> >>>> 4. How do I revoke access when my laptop is stolen? >> >>> >> >>> You go to the server and remove the public key from your profile. >> >> >> >> How do I log in to the server? >> > >> > You use a one time password generated perhaps with >> > >> > http://www.crypto-stick.com/2012/OATH-One-Time-Passwords-Allow-Login-to-Gmail-Dropbox-AWS >> > or a very long password you use very rarely. >> >> See above. >> >> >>> Or you ask your admin to do that. Or if you have your own server at >> >>> home, can't remember anything, then you unplug it. >> >>> >> >>>> >> >>>> 5. How do I migrate my existing username/password accounts to WebID? >> >>> >> >>> There is a technical answer and UI answer for that. >> >>> >> >>> Let me start with the user's point of view. Here is how that would >> >>> look if we were to >> >>> imagine a user (me) using Google+. >> >>> >> >>> One day I go to google plus on my desktop browser and Google Plus >> >>> entices me to >> >>> "Use WebID and login securely across the web" >> >>> I click on that banner, and pronto, a certificate is created and >> >>> transferred to >> >>> my browser. (ok perhaps you add an intermediate page with helpful >> >>> explanations >> >>> and cool demos) >> >>> >> >>> Next I am walking down the street with my Android. Google+ is clever >> >>> enough to notice that my android does not have a certificate - it does a TLS >> >>> request for a client certificate, but receives none - and so asks me >> >>> "Hi Henry, get a WebID certificate for your phone too" >> >>> I click the banner and oops I have a certificate in Android. >> >> >> >> Up to here this mostly makes sense, but... >> >> >> >>> >> >>> Once I have a certificate for a device, I can log into any web site >> >>> that supports WebID in one click. I can also determine for any site how much >> >>> information I wish to give that site about me - using access control on >> >>> information at my profile. Someting we need to work on still. >> >> >> >> Once more, this is an unacceptable privacy problem. >> > >> > Because you keep thinking that the user does not have a choice in >> > controlling his identity on the sites he visits. And that is because you are >> > not a User Interface Expert. But User Interface experts have looked at this >> > and made it easy to use and control. See >> > >> > http://www.azarask.in/blog/post/identity-in-the-browser-firefox/ >> > >> > and the pictures in big >> > >> > http://www.flickr.com/photos/azaraskin/4128966575/sizes/l/ >> >> Well, we're back to "how does this work when I have hundreds of >> certificates?" >> >> > >> > >> >> >> >>> So the Technical answer, is that Google+ adds to each profile a >> >>> representation that can be read as explained in the spec >> >>> http://webid.info/spec/ . It is quite easy to retrofit a normal web >> >>> site with this info. >> > >> > >> > To sum up your problem (in my view) is that you think authenticating >> > with one linkable id across sites is a privacy problem. You believe that >> > because you don't allow the possibility of a User Interface that makes it >> > easy for people to be in control of the identity they user per web site. The >> > User Interface elements for that have been proposed and would be easy to >> > implement. >> >> The easy interface works well only if you are happy with a small >> number of identities - i.e. linkability across almost everything. >> Also, note that this kind of thing was tried with Microsoft's >> InfoCards and also with OpenID. It didn't go so well. >> >> > >> > So I agree with you: if one were not in control of one's identity as one >> > switches between web sites, then one would have a privacy problem. But I >> > believe one can be in control of one's identity as one switches between web >> > sites ( see Aza Raskin's work ). >> > >> > Given that the question is what would the benefit be of this linked >> > authentication? My short answer is that it allows people to work across >> > organisations in a distributed way, which would be a major benefit to >> > society. For more you can see my talks on http://bblfish.net/ . >> > >> > >> > Henry >> > >> > >> > >> >>> >> >>> Henry >> >>> >> >>> Social Web Architect >> >>> http://bblfish.net/ >> >>> >> > >> > Social Web Architect >> > http://bblfish.net/ >> > >> >
Received on Wednesday, 26 September 2012 12:29:38 UTC