- From: Ben Laurie <benl@google.com>
- Date: Wed, 26 Sep 2012 12:59:15 +0100
- To: Henry Story <henry.story@bblfish.net>
- Cc: public-webid@w3.org, Andrei Sambra <andrei@fcns.eu>
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! >>> 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 11:59:49 UTC