W3C home > Mailing lists > Public > public-webid@w3.org > September 2012

Re: WebID questions -- was: [dane] Call for Adoption: "Using Secure DNS to Associate Certificates with Domain Names For S/MIME"

From: Ben Laurie <benl@google.com>
Date: Wed, 26 Sep 2012 13:29:03 +0100
Message-ID: <CABrd9SS8w56oUsMeY0NwHQj9og+pv3h1xHqphKgPpaKdOYM9zw@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:40:59 UTC