- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Wed, 26 Sep 2012 14:09:03 +0200
- To: Ben Laurie <benl@google.com>
- Cc: Henry Story <henry.story@bblfish.net>, public-webid@w3.org, Andrei Sambra <andrei@fcns.eu>
- Message-ID: <CAKaEYhL+VmwDQYfXF7Eo91BD-42LrLQX=-xnu=q_hHTGbDn=8Q@mail.gmail.com>
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. Similarly the ubiquitous google +1 buttons have similar privacy issues. 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? > > >>> 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:09:33 UTC