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 12:09:00 +0100
Message-ID: <CABrd9SR6_MUTzxc6CkVfbYTedm9xC-fVBDe-OqTt7JMXW6GdjQ@mail.gmail.com>
To: Henry Story <henry.story@bblfish.net>
Cc: public-webid@w3.org, Andrei Sambra <andrei@fcns.eu>
On 27 September 2012 11:22, Henry Story <henry.story@bblfish.net> wrote:
>
> On 27 Sep 2012, at 12:13, Ben Laurie <benl@google.com> wrote:
>
>
>
> 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.
>
>
> fine. There are other technologies to address those issues. Username
> password is one of them.
>
>
>>
>>
>> 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.
>
>
> yes, the ball is in your court in part as representative of Google.

Not really.

> Pressure
> them to improve the UI, and we will have all have a better privacy
> experience. We here can help build a vocal group of people to help your
> managers understand the importance of users being aware of the identity they
> present to a web site.

Chrome tends not to be impressed by vocal minorities - what is needed
is users asking for the feature.

>
>
>>
>>
>> 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
>> <aza.jpg>
>>
>>
>>
>>
>>
>> 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/
>>
>
>
> Social Web Architect
> http://bblfish.net/
>
Received on Thursday, 27 September 2012 11:09:37 UTC

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