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

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