Defining and relating reputation, whuffie, attention, social capital and privacy

Reputation

I define having reputation as having reputable third parties willing to confirm one’s claims as true.

These claims include:

  • personal information such as one’s date of birth or first name, 
  • transaction information such as timely re-payment of debt following a credit card purchase, 
  • opinions expressed that are shared by others such as a blog post or 
  • actions done or not that are approved by others
  • artifacts produced that are appreciated by others

Whuffie 

Verifying someone’s claims used to be expensive and limited to a few players, such as credit bureaus in partnership with credit card networks. The recent computerization of communications has reduced the authentication cost by increasing the amount of authenticatable information (in the form of published opinion/thought pieces) and the potential number of authenticating parties, leading to my understanding of the concept of whuffie. 

Linking with attention 

I say “potential” because 3rd parties will not authenticate content unless one has their attention in the first place. Attention is limited the nature of people’s cognitive capabilities and is ideally dependent on their goals, but also a function of one’s reputation, which leads us to…

Social capital 

The self-reinforcing aspect of reputation together with each person’s limited attention and exploding amount of authenticable information is what explains social capitalism: the authenticable information created by some is republished by others and through this process fully/partly appropriated because of their reputation. This is similar to Marx’ capital where part of the value-add of workers’ labour is appropriated by employers because of their ownership of the productive asset.

Examples include bloggers or journalists who are given exclusive information before it is published because of their established trademark. They don’t need anymore to find a good story, only to filter it out from what they receive.

Attention is the new capitalistic asset to own, maybe the new money considering that people’s attention is limited and that it is dispensable by those with social capital.

(Side note: assuming attention is driven by goals (see Flow), owning attention is done by getting others to align their goals on one’s goals).

Privacy 

What is interesting about reputation is that it does not necessarily require information to be published. It only requires someone reputable to confirm it as true. I don’t need to tell you that I’m over 21 years old, but just need to point you to someone reputable that can confirm my claim.

In other words, privacy may not be dead, but it has to be dead with one or a few highly reputable parties.

The relation to OpenId and OAuth

It derives from the above that an OpenId or OAuth provider’s relevancy is proportional to its reputation. Its value is proportional to its ability to actually verify the information it hosts.

Les banques devrait-elles devenir des fournisseurs d’OpenID?

This is a translation in French of an earlier post.

Il y a presque dix ans, au sommet du boom Internet, je me rappelle avoir avoir discuté avec un banquier qui me suggérait que dans le future, le rôle des banques ne se limiterait pas a garder l’argent de leur dépositaires, mais aussi à garder leur identité en ligne secrète. D’une certaine manière, cette prediction s’est concrétisée par le biais des programmes de protection contre le vol d’identité. Cela dit, si l’on définit l’identité comme la somme des informations personnelles qui distingue une personne d’une autre et qu’il est difficile voire impossible de se procurer, on voit bien qu’une grand partie de ces informations (et en particulier les secrets tels les mots de passe) sont disséminés dans un grand nombre de services en ligne (60 en moyenne, bientôt 200, d’après une étude du Yankee Group sur OpenID).

Comme chacun sait, OpenID constitue la solution non-propriétaire à ce problème, et pour les raisons présentées ci-après, il semblerait que les banques soient des candidats parfaits pour devenir fournisseurs d’OpenID:

  • “Qui peut le plus peut le moins”. Le niveau de sécurité imposées par les services en ligne aux mots de passe de leurs utilisateurs ainsi que l’intérêt des utilisateurs à avoir des mots de passe difficiles, varient d’un service en ligne à un autre, mais la banque en ligne est probablement un des services ou le niveau de sécurité des mots de passe est le plus élevé. La raison est simple: il s’agit du service où les utilisateurs ont le plus à perdre si leur mot de passe se retrouve dans de mauvaises mains. Ainsi, on peut difficilement imaginer un utilisateur s’authentifier auprès de son service de banque en ligne avec son le nom d’utilisateur et mot de passe de son compte Google, mais l’inverse est beaucoup plus plausible
  • Les banques ont plusieurs actifs existants relatifs à la sécurité:
    • Elles ont déjà en place une infrastructure technique assurant la sécurité de l’accès en ligne aux comptes bancaires,
    • Elles ont pour la plupart une image de marque forte en terms de sécurité, et
    • Elles ont déjà en place des programmes de protection contre le vol d’identité qui fourniraient un complément d’assurance à OpenID, et ferait de cette technologie une vraie solution/vrai produit
    • Les banques sont tenues légalement de connaître leurs clients, et ont pour cette raison probablement beaucoup plus d’information sur leurs clients (par example, documents officiels comme carte d’identité) que n’importe quel autre service en ligne (mais pour combien de temps encore?). Cela veut dire qu’elle possèdent le plus large éventail d’options d’authentification, leur permettant de supporter plusieurs niveaux d’authentification. Elles ne sont pas limitées au model d’OpenID classique de l’URL et du mot de passe: elles peuvent non seulement décider d’émettre des URLs OpenID qui soient distinctes du nom d’utilisateur, mais elles peuvent aussi et surtout utiliser une authentification multifacteurs, par exemple envoyer un numéro personnel secret par SMS à un téléphone mobile, ou demander à un utilisateur de cliquer sur un bouton pour être appelé par un centre d’appel, comme spécifié par les OpenID policy extensions.
  • Enfin, il existe de très bonnes raisons économiques. Un service OpenID offert par une banque consituerait:
    • Un service à très forte valeur perçue (mot de passe unique pour potentiellement tous les services en ligne utilisés par un utilisateur) que les banques pourraient faire payer
    • Une nouvelle façon de promouvoir leur image de marque: compte tenu du fonctionnement d’OpenID (redirection vers le fournisseur OpenID pour chaque authentification) les utilisateurs verraient le logo de la banque à chaque authentification.
    • Un formidable outil marketing: les banques auraient connaissance de quand quel utilisateur utilise quel service et pourraient présenter en fonction des offres et publicités liées ou non à leurs produits lors de chaque authentification,
    • Une très bonne manière de garder leurs client: le coût de changement de fournisseur OpenID s’ajoutant aux autres coûts de transfer de comptes bancaires à une autre banque.

Should banks bank on OpenID?

Almost a decade ago, at the height of the Internet boom, I remember talking to a banker telling me that in the future, banks would not just keep your money safe, but also your identity. To some extent, this has materialized with identity protection programs offering insurance against the risk of identity theft. That said, if you view the identity as the collection of hard- or impossible-to-obtain information about a person that uniquely distinguishes her from others, you would certainly admit that a big part of this information (in particular secrets such as passwords) are spread around in a variety of online services (60 on average, growing to 200 according to a Yankee report on OpenID).

OpenID, as everyone knows, is the open solution to this problem, and banks seem to be excellent potential OpenID providers for the following reasons:

  • “He who can do more can do less”. Password strength requirements and password strength user incentives are not equal among online services, but online banking is probably one of the services where password strength is highest, simply because this is where for most people the loss would be the highest if their password was to fall in the wrong hands. So, users won’t use an easy-to-remember Gmail username/password or blog commenting account to login at their bank, even if the bank trusts Google’s security, but they would probably not mind the reverse.
  • Existing security-related assets:
    • Banks already have the security infrastructure in place to secure financial accounts,
    • Most banks are already trusted brands in terms of security, and
    • Banks already have identity theft protection program in place that would complement OpenID, which is just a technology
    • Banks are required by anti-money laundering laws to know their customer, and have probably more identity-related information about their customers (ex. government-issued documents) than any other online service. This means they have the widest range of authentication options, allowing them to support multiple levels of authentications. They are not constrained to a public URL/private password model: they can not only decide to issue a OpenID URL that is distinct from the existing username, but also use multi-factor authentication for instance by sending a PIN by SMS to a phone or requesting the user to click and get a call from a call center agent, as requested by OpenID policy extensions.
  • Last but not least, compelling business reasons. A highly secure OpenID would be:
    • A value-add service that the bank could charge a premium fee for
    • A great way for banks to promote their brands (you’d see their logo everytime you authenticate), get to know their customers’ online usage patterns (which service you are using and when) and present new offers/ads (banking-related or not),
    • A great way to retain customers.

twauth: mobile authentication with OpenID and Twitter

I stumbled upon Ian McKellar‘s twauth prototype: a Twitter and OpenID based mobile authentication solution.

The idea behind twauth is to address the usability issues of current mobile OpenID-based authentication workflows.

The particular issue that Ian’s twauth addresses it the effort place on the user to enter alphanumeric passwords.

Twauth addresses this issue by replacing the alphanumeric password entry by a digits-only 5-digit one-time code sent to the mobile phone via Twitter/SMS, that the user then enters on the openid authentication page.

Here are some screenshots of the complete workflow:

1. Entering the twauth mobile OpenID URL at the mobile ma.gnolia.com (m.gnolia.com) http://twauth.ianloic.com/twitteruserid:

Ma.gnolia.com mobile login page

2. Instructing the OpenID server to send a direct (private) Twitter message with a 5-digit code (ignore the garbage):

Direct message selection

3. The mobile phone that is linked to the Twitter account linked with the twauth OpenID URL is sent a message with a 5-digit code (18010 – screenshot not available)

4. User enters the one-time 5-digit code:

Entering the one-time 5-digit code

5. You are authentic!

You are authentic

Hosting your very own OpenID with phpMyID

Why hosting your own OpenID? for me, it’s a way to stay committed to a fully decentralized Web.

phpMyID is very simple standalone, single user, OpenID Identity Provider developed by CJ Niemira. It does not require access to a database as everything is stored in the .php file.

It is absolutely perfect for a personal Web site.

Installation only took me about 30 minutes by following the very detailed installation instructions. My OpenID is http://lebleu.org/openid (I am going to move it to https as soon as Laughin Squid enables SSL on my site).

I already tried my new very own OpenID with SourceForget.net and OpenIdDirectory.com (to add a vote for phpMyID) and it works great. SourceForge.net just recently (May 5) added support for OpenID. If you already have an account with SF, you will bind your OpenID to your existing account by logging in with your OpenID and then logging in again with your existing account name/password. I found that logging with OpenID on SF takes a bit more time than with username/password, but I guess this will improve over time, and it is a minor pain compared to the convenience of having a single registration and sign-on facility that I control 100%.