Category: oauth

Microformats and decentralized online currencies

Most people are probably aware of the announcement by Google (following Yahoo’s announcement) that they would be supporting microformats.

What is really interesting to me is what this means for online currencies.

If you look at an hReview, what it is fundamentally is a declaration of positive (or negative) experience measured as a number betwen 1.0 and 5.0 about an item, which someone publishes on the Web anywhere he/she wants. An aggregator like Google in turns aggregates it and computes an average of the rating. The reviewer does not need the authorization of the reviewed item to publish the review.

That name typically includes a link (URL), which can be viewed as one of the identifiers of the reviewed items on the Web. It might be their own homepage for a restaurant, or it might be a description of the item on a review Web site such as Yelp (here the Yelp URI of a thai restaurant where I live).

In the payment world, there is already a payment application that allows you to donate/pay money without the other person having registered, it’s Tipjoy. The way it works is that you donate to URLs on the Web. Just like an hReview, the recipient does not have to be registered with TipJoy for others to tip them. If and when they eventually register they can claim their money by inserting a tipjoy tag with their username in the HTML of their Web page. Twollars followed a similar process but with Twitter names instead of Web URLs, but Twitter names are also URLs…

So the general pattern of Twollars,  TipJoy and hReview is that you give or review a URL.

This could work for a really open monetary architecture:

  • People would write somewhere on the Web (typically a Web space they own) an hReview-like statement that they give a number of units of currency to someone else. For instance: <span class=”hPay”><span class=”give”>Given</span><span class=”amount”> <span class=”value”>20</span> <span class=”currency” title=”us.ca.sf.bh”>BH$</span> to <a class=”to fn url” href=”http://www.yelp.com/biz/blue-elephant-thai-san-francisco”>Blue Elephant restaurant</a></span class=”hPay”> (Note that they could write it manually, but most likely, they will use a form that will generate it for them).
  • An aggregator would find this statement, either by crawling the Web, or if they are blogged via a RSS ping. The aggregator will typically compute balances (positive and negative). In a mutual credit model, people’s balances would be allowed to be negative, but in a traditional government-issued currency, they would not, they’d have to borrow it at interest.
  • Receivers may claim some of the URLs through a similar process than the one used by TipJoy.
  • Users may publish back their balances via a widget on their Web site.

What’s great with this model is that anyone can start playing, even create their own currency, very easily.

More importantly, you can have several accounting services tracking hPay statements and computing balances. You don’t need an account at a bank, your Web site is your bank account. What the accounting service does is simply authenticating that you own the space where you published transactions, and keeping tabs.

There are several issues:

  • Currency creation: Where do we register new currencies so that accounting services can distinguish different currencies? The ISO 4217 code is too limited to support millions of currencies. We need something like I used above: “us.ca.sf.bh”, which would allow new currencies to be easily created out of existing ones simply through forking.
  • Currency rules: different currencies have different rules. Some will allow negative balances of any amount, some won’t allow anything below zero, some will allow some negative balances or positive balances with limits (ex. 5,000). These rules must be encoded in a formal language, published to accounting services and participants and associated with the name of the currency. Eric Harris-Braun and Arthur Brock have already explored this topic extensively.
  • Refusal: how does a recipient refuses a given currency amount? (another currency rule BTW) this assumes that the recipient can be notified that their URL was mentioned. This is essentially a linkback.
  • Security, in particular:
    • Authentication: how do we make sure that statements posted indeed come from the person owning the resource.
    • Authorization/Privacy: how to we ensure that not all transactions I make are public, but available only those I transact with and possibly as few as possible trusted reputable intermediaries. OAuth could be useful here if the resources can be easily segmented and tokens can be issued to groups at once.
    • Non-repudiation/Tracability: how do we prevent the effect of people deleting hPay statements.
    • etc.

Quite a lot to think about. Some of these items will be the topic of future posts.

Improving the home loan application process

I recently was very fortunate to purchase a house in San Francisco. As most home buyers, as part of the process, I had to get a loan approval  and to provide a lot of paper-based information. Unsurprisingly, I submitted this information in the form of electronically scanned print outs of various online Web services (thank Science I didn’t have to mail printed statements). This pile of information was then manually verified for accuracy and authenticity, and the relevant information was manually fed to a mortgage approval system.

Here is the information I had to provide:

    1. Hazard insurance policy
    2. Complete institutional statements covering most recent months + as applicable, reasonable explanation and documentation for any large deposits within the last 60 days
    3. Copy of the purchase signed agreement
    4. To verify salary: 1) paystubs for the last 30 days 2) last 2 years W2s
    5. Landlord reference verifying payment history for the past 12 months
    6. Verification of stocks/bons as stated in application
    7. Evidence of residency and employment status in the US
    8. Verified employment with employee through verbal conversation or electronic verification of employment
    9. Verification of applicant’s identity (identification certification document signed by authorized bank representative and faxed)

      I won’t talk about #9, which is simply ridiculous since I’ve applied for this loan at a bank I’ve been banking with since 1998 and who also handles my brokerage account. I don’t know how many times they have verified thoroughfully my identity. I won’t comment on #7, but needless to say that when I know very well that the INS has this information accessible in real-time. Regarding #3, it might already be possible to directly extract from a digitally signed pruchase agreement PDF form the relevant information. If not today, probably very soon.

      What’s really interesting is #1, #2, #4 and #6.

      #1 is information I received from my insurer, but I assume it is available from my insurance’s Web service in HTML/PDF format.

      #2 and #6 (and partially for #4 since I receive my paychecks by wire transfer to my checking account) is information that can be retrieved today directly from my bank or brokerage’s firm Web service.

      There are several building blocks needed to achieve this:

      • Information can be extracted from content. This assumes that the HTML content is either semantically tagged using a (yet to define) microformat, or available in alternative format, say some industry XML standard like ACORD XML for insurance or OFX for banking/brokerage information.
      • I can tell my bank to authorize the inquiring party that they can retrieve specific pieces of information. Also, I can specify to the inquiring party who they can inquire this information from. This is were an authentication delegation protocol like OAuth can be useful.

      #4 (Landlord reference verifying payment history for the past 12 months) is interesting. My current landlord and I banking at the SAME bank, I would have enjoyed the possibility of being able to tag some of my transactions with “rent” and share it with him so that he could validate them.

      Using ATM to send cash – no bank account or card required, only a cell phone.

      If you haven’t read this at bankwatch or banktech yet:

      Privier’s New ATM Service Requires No Card, Account

      The service is a cash-to-cash service targeted at the unbanked population. After registering a mobile phone online as well as other personal information, a user can go to an ATM, deposit cash, enter a mobile phone number, and receive in return a 10-digit withdrawal code that he can send to someone else.

      This is essentially an authorization delegation mechanism, and as such it reminds me of OAuth, which allows authorization delegation for APIs on the Web.

      The main issue here is adoption: the service is only valuable if the receiving party can go to an ATM that supports the technique, so my understanding is that this will have a real value when it is deployed by a large ATM network operator, or when it is supported accross networks via a common protocol.

      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.

      What the IT at Google Bank would look like

      As I was watching the Google I/O keynote presentation, I thought about how all the development tools provided by Google (Google Gears, GData, OpenSocial, etc.) could be put to work to create a Google-powered Bank, and what the IT architecture of this Google Bank would look like.

      Here is how I think it could look like:

      All user interaction devices, whether it is a teller workstation, mobile phone, ATM machine, kiosk would provide access to the bank via any of the standard Web browsers (Opera, IE, Firefox, Safari).

      If access to device-specific functionality is required, it would be done by Google Gears (say for instance, that I want to access the ATM’s cash dispensing functionality, or I want to access the mobile phone’s built-in GPS or accelerometer). Ideally, these devices would be running a single application that would adapt according to the services discovered on the device on on the service cloud. But realistically, they would be running variant of a single GWT Java code base that GWT would compile in JavaScript for browser-based deployment.

      Contacting customer support would be done via Google Talk click-to-call buttons. Interactive Voice Response systems would be powered by 1-800-GOOG-411 voice technology.

      All these user facing app would leverage a cloud of shared GData services based on Atom Publishing Protocol. These services would be used to retrieve and update any data and transaction: update accounts, customer profiles, schedule payments, withdraw money, consult account balances, etc.

      These services would be available to any developer who registered for an API key to create new 3rd party applications, with online documents, code examples, tutorials, videos, etc. There would be a related developer challenge that would award prizes ranging from $25K to $100K to motivate developers to create 3rd party applications. Google Bank would monitor usage and success via the API key, and acquire the apps that can contribute the most to their bottom line or user growth. OAuth would be used to allow 3rd party apps to accesss customer data without the user having to give away their Google login/password.

      OpenSocial would be leveraged by Google Bank to provide an easy framework for friends to share bills, family member to send money to one another via any device, and to loan money to friends/families or friends of friends. Google Bank would use this data to provide preferential loan rates or optimize transaction fees.

      Google Bank analytics would analyze my transaction patterns, build nice spending usage pie charts for me, and suggest relevant ways to save or make more money via competitive offers aggregated in Google Shopping. Bank marketing managers would use Google Bank analytics to analyze usage patterns, create marketing campaigns and target specific demographics and customer types in Google Adsense.

      And last but not least, users would be able to search all their personal data using a simple one input field user interface.

      Did I miss anything?

      Mint.com: a perfect banking use case for OAuth

      Mint.com provides a free service, which is able with your authorization, to connect to your bank(s), retrieve your bank account information and all your transactions and provide value-add services with the data. In particular, it allows you to see where you money is spent and give you hints at how you could save money. I personally think it is a superbly designed UI to the user data held at banks, which shows how much value there is to unlock, and also how much startups can be so much more efficient at delivering innovating services than banks themselves sometimes. Yodlee, a partner of Mint.com, was a dot com era example of this and Mint.com might be their Web 2.0 equivalent.

      One problem is: Mint.com requires you to provide your actual username and password to the online banking service provided by your bank, which you use not just to view transactions, but also to make payments, transfers, etc.This approach has several drawbacks. One is that the user can be legitimately concerned about what would happen if this information would get compromised. Right now, Mint.com reassures its customers by saying: “We don’t store your info, Yodlee does”.

      Another problem is that every time your online banking username or password changes, Mint.com stops working until you reconfigure it:

      Mint.com screenshot showing: wrong username/password

      Not very convenient. Add to this the fact that you can’t have any guarantee of what happens to your username/password when you want to terminate your relationship with Mint.com/Yodlee, and you may feel like you won’t use this application for now.

      An implementation of OAuth protocol between Yodlee/Mint.com, the user and the bank can solve these problems at once, and would certainly further drive user adoption.

      OAuth is self-described as a protocol for “secure API authentication”, but a better way to put it is that OAuth is a way for users to grant controlled access to their data hosted at online service A to another online service B. To use the car metaphor, if your data at online service A was a car, and online service B was the valet parking person, OAuth would be the way for the valet parking person to ask you for your car’s valet key, with which he can only drive a few miles and can’t open the trunk, and the way for you to give him the key. In security jargon, OAuth allows to delegate capabilities on your data to other applications, in the form of signed tokens, i.e. authorizations to do specific things with specific data that you sign with your identity. The beauty of it is: because these capabilities are signed by you, it can be presented by online service B to access your data at online service A without you having to provide your identity credentials (username/password typically) to online service B.

      Coming back to the Mint.com/Yodlee use case, here is how it would work:

      • The user would go to Mint.com to request access to his data at the bank.
      • Mint.com would request his bank a token for a specific capability, for instance, retrieving transaction data
      • Upon receiving this request token, Mint.com would redirect the user to the bank’s token authorization page.
      • The user then authorizes the token (If he is not already logged in, he would do that first)
      • Mint.com can then substitutes the request token with the access token, and access the user’s data as they requested and as the user authorized, until the token is invalidated or expires.

      Here are the benefits of OAuth for the user in this use case:

      • Mint.com/Yodlee never know the username/password used to log in at the bank.
      • When the user changes his username/password, Mint.com/Yodlee can still retrieves transaction data
      • When the user decides to terminate the relationship with Mint.com/Yodlee, he knows they don’t have is username/password and he knows that they can’t access his data anymore.
      • When you don’t want to use Mint.com/Yodlee anymore, you can simply invalidate

      The big question is: how much work would be involved at banks and Yodlee to support OAuth, and in particular, what would they have to change?