What the IT at Google Bank would look like
May 30th, 2008
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?
twauth: mobile authentication with OpenID and Twitter
May 13th, 2008
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:
2. Instructing the OpenID server to send a direct (private) Twitter message with a 5-digit code (ignore the garbage):
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:
5. You are authentic!




