- From: Henry Story <henry.story@bblfish.net>
- Date: Thu, 27 Sep 2012 12:22:24 +0200
- To: Ben Laurie <benl@google.com>
- Cc: public-webid@w3.org, Andrei Sambra <andrei@fcns.eu>
- Message-Id: <269C30A0-A60B-4ACB-BF88-8B8F403F7272@bblfish.net>
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. 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. > > > 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 10:23:02 UTC