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: Thu, 27 Sep 2012 11:13:37 +0100
Message-ID: <CABrd9SRjPuQrOn8O4pqZ7P9rK+tS2s0sRRrCQG5981-0jww5xw@mail.gmail.com>
To: Henry Story <henry.story@bblfish.net>
Cc: public-webid@w3.org, Andrei Sambra <andrei@fcns.eu>
On 27 September 2012 10:59, Henry Story <henry.story@bblfish.net> wrote:

>
> On 27 Sep 2012, at 11:45, Ben Laurie <benl@google.com> wrote:
>
> On 27 September 2012 10:02, Henry Story <henry.story@bblfish.net> wrote:
>
>
> On 27 Sep 2012, at 10:38, Ben Laurie <benl@google.com> wrote:
>
> On 27 September 2012 09:31, Henry Story <henry.story@bblfish.net> wrote:
>
>
> On 27 Sep 2012, at 09:57, Ben Laurie <benl@google.com> wrote:
>
> On 26 September 2012 13:50, Henry Story <henry.story@bblfish.net> wrote:
>
> On 26 Sep 2012, at 13:59, Ben Laurie <benl@google.com> wrote:
>
> 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.
>
>
> Microsoft's info cards was a centralised solution I believe. Here we are
> using only open web standards: HTTP, TLS, RDF, Linked Data. Which allows
> everybody - individuals as well as large institutions to participate. We
> are not excluding anyone here.
>
>
> No, infocards were decentralised.
>
>
> And they permitted a distributed web of trust? I really doubt they had the
> tools to work with that, in part because it requires open standards such as
> those behind LinkedData (HTTP+RDF) for it to make sense.
>
> But that's really not the point -
> the point was that they involved similar choices amongst a large
> number of possibilities, and it turned out to be hard to use.
>
>
> it cannot have been a similar choice among these number of possibilities.
> They did not have LinkedData ( that meme only really appeared in 2006 or
> so, and has been growing slowly and steadily since then . see for example
> Tim's 2009 Ted Talk
> http://www.ted.com/talks/tim_berners_lee_on_the_next_web.html )
>
> Think about this: if you are from Google - a company whose life is based
> on the Web, was built on the web, and whose core algorithm is based on the
> linking of pages - but who still is largely new to LinkedData, you can
> imagine that Microsoft, a much older company with a lot more legacy, is
> going to be much slower in embracing such a change ( though huge leaps have
> been known to happen ) Also remember they were taking in by the SOAP bubble.
>
> OpenID has a similar problem (its what they call the Nascar problem).
>
>
> We can get rid of the Nascar problem easily. I think someone may already
> have implemented an initial example of that using WebID... You just write a
> server that does the following when someone clicks the 1 and only login
> link on the page.
>
> The server requests the client certificate  ( asynchronously is best as in
> here  https://github.com/bblfish/Play20 )
>
> IF the user selects a certificate and returns it
>
>
> This is the point at which the Nascar problem occurs: selecting the
> certificate.
>
>
> ( Background of NASCAR problem for those new to this
> http://factoryjoe.com/blog/2009/04/06/does-openid-need-to-be-hard/ )
>
> No, that is not the problem. Most people nowadays have 2 or 3 payment
> cards, which they can choose from when going into a shop to pay for
> something. Choosing one among a handful personas is easy when logging in
> somewhere. And most users would not have more than a handful of
> certificates to select from when going to a web site.
>
>
> You can't have it both ways: if privacy is protected by using multiple
> certificates, you cannot also restrict people to using 2 or 3.
>
>
> Having multiple identities is one aspect of protecting privacy: it allows
> you to choose which persona you use on which web site - if you want to log
> in that is: anonymity could be considered the null certificate.
>

There are shades of anonymity - I might still want to log in yet be
anonymous (i.e. not linkable to my other logins). The null certificate
would not achieve that.


>
> There is no need to restrict people to using 2 or 3. There is I believe a
> limit on how many identities people wish to have.
>

The W3C does not seem to agree -
http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html claims
that some people do not want to be correlated across sites.


> The rest is up to browser vendors to improve the User Experience.
>

You can punt on the problem if you want, but it doesn't stop it from being
a problem.


>
> What protects privacy is your
> 1. your browser asking you who you want to be identified when going to a
> site
> 2. your browser showing you who you are logged in - as the attached
> prototype by Aza Raskin shows
>
>
>
>
>
> The problem is that these selection boxes are predetermined in advance by
> the web site you go to, are confusingly presented differently on each web
> site, and don't in fact give you the freedom of running your own identity
> server. Who would put the University of Oxford identity server up there as
> an option if such existed?
>
> But I could get a University of Oxford certificate and wherever I go to on
> the web if the server asks me for a certificate, I would be given the
> option of using one of the certificates I actually have - not those most
> people usually do have.
>
> The NASCAR problem is one of in your face choice for options you don't
> want, without giving you the options you actually do have.
>
>   The server on receiving the certificate. Either
>     a. the certificate is CA signed and trusted. Follow usual procedure.
>        (though if there is a WebID, you can get extra information that
> would
>          otherwise be difficult to put in a cert)
>     b. the certificate does not have a CA known to the server and no WebID
>        use the public key as a temporary identifier, but suggest linking
> that public key to a number of other
>        identification schemes - you're in NASCAR land - but also suggest
> to the user to get a WebID
>     c. the certificate does not have a CA known to the server and a WebID
>       do WebID identification.
> Else
>      do the usual Nascar stuff
>
> In a, b above you have a WebID so you can replace the Nascar box by a
> linking verification process, and you can reduce the immediately visible
> options by using the information from the WebID profile using the
> foaf:holdsAccount relations found in the foaf file: e.g.: no need to
> suggest Facebook login - as a first option - if the user does not in his
> profile declare having an account there.
>
> The above is a back of the envelope sketch of how to do things. Of course
> with a team of good designers you'd develop that carefully and do usability
> tests.
>
>
>      Henry
>
>
> Social Web Architect
> http://bblfish.net/
>
>


aza.jpg
(image/jpg attachment: aza.jpg)

Received on Thursday, 27 September 2012 10:14:06 UTC

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