Identity, Payments and Related Technologies

Open Web Payments !

2010-07-21T23:18:00.003-04:00

Today we presented our proposal for Open Web Payments and the corresponding Open Stack to implement it and support it in a much easier and extensible way. Obviously as you all know, there are a lot of Payments Providers - from credit card networks & NACHA to Online Wallet/Checkout providers, Social/Virtual/Game currency to frequent flyer/buyer points, mobile payments to offline payments. Unfortunately for a developer integrating with each one of those is a nightmare given the differences in data model, APIs and protocols. Our goals with Open Web Payments effort were to:

1. Provide Consistency APIs across platforms
2. Provide a Single model for authorization, payments and transactions
3. Support both real and virtual currencies
4. Provide a Single, extensible document model

Please review our presentation on slideshare below and please join the google group (http://groups.google.com/group/owp-api) to help in discussing and evolving this proposal as a formal spec, and if possible help in building a few sample reference implementations.

Open web payments

View more presentations from Praveen Alavilli.

Fueling the Wallet.Next

2010-03-11T13:46:00.001-05:00

Fueling the Wallet.Next

View more presentations from PayPalX Developer Network.

In Search of your Wallet ?

2010-03-05T01:19:00.001-05:00

In Search of Your Wallet ?

View more presentations from PayPalX Developer Network.

Online Payments for Developers - Part 2 - Clearing House Based Networks

2010-01-25T20:55:00.008-05:00

(this is a continuation of my previous post on Online Payments for Developers - Part 1)

Clearing House Based Network (a.k.a ACH)

A Clearing House simply is a central collection place where banks and other financial institutions exchange checks or drafts and settle accounts. In other words, it’s a common ground for all banks and financial institutions to transact with each other. ACH (Automated Clearing House) is an electronic network for the Clearing House, which was introduced in late 1960s as a result of the first “Paper-less Cache” initiative lead by several banks and Govt. The Federal Govt. wanted to reduce the cost involved in printing and mailing the Social Security, Tax returns, and Payroll checks, and the fraud in stolen checks from peoples mail boxes. The banks wanted to reduce the manual effort required in handling the checks submitted by the people. And last but not least, people wanted quicker access to the funds in their accounts, which otherwise takes a long time for the checks to be processed by the banks manually. Over time several other big corporations started using ACH for direct Payroll processing, and several insurance and utility companies started using ACH for direct debits for their service payments.

The ACH is usually called 4 Participants Model, as there are 4 participants in addition to the Clearing House itself.

The Originator – that initiates the payments transactions into the ACH (company that’s processing payroll funds, or the utility/insurance company collecting payments or more recently online and telemarketing companies to debit consumer accounts for purchase of goods and services).
ODFI (Originator Depositor Financial Institution) – a national/state charter bank, financial institution or a credit union or an insurance company that consolidates many transactions from many Originators and submits them to the Clearing House for processing. The ODFI makes sure the transactions are valid and confirm to the ACH standards.
RDFI (Received Depositor Financial Institution) – a national/start charter bank, a credit union or a loan and savings institution that participates in ACH. The RDFI holds the receivers deposit account and is responsible for accurately processing the transactions by debiting/credits the right accounts and for timely returning information to the ODFI for any transactions that cannot be processed.
The Receiver – that receives the transaction. The transaction can be a credit or a debit request, which means money, may be added or subtracted from the receivers account. The Receiver holds a depository bank account with the RDFI. The receivers can be consumers or businesses or some other form of a corporate entity.

Connecting the ODFIs and RDFIs is the Clearing House that processes all the transactions submitted by the ODFIs and delivers them to the RDFIs. As you can imagine the Clearing House processes gigantic volumes of transactions between the ODFIs and RDFIs. There are 2 Clearing Houses in US – the first one is a public Clearing House operated by Federal Reserve bank, where as the second one is a private Clearing House operated by a consortium of financial institutes and is called Electronic Payments Network.

Most financial institutions connect directly to the ACH with an exception of a few smaller institutes that connect indirectly to the ACH through another larger financial institution. Both Clearing Houses operate on the same set of rules defined by the National Automated Clearing House Association (NACHA). NACHA is a non-profit association of member banks, and participants that oversee the ACH network. There are obviously several other regulations that control how the ACH must operate, which you don’t really need to know or worry about unless you are building a system for a financial institution that wants to participate in ACH. J

Also as you can guess, most of the financial institutions act as both ODFIs and RDFIs (with varying volumes based on the businesses they cater to – for example a bank processing Payroll sends more transactions as an ODFI than a consumer bank providing checking/saving accounts to end consumers that handles more transactions as an RDFI), although for a given transaction they can only act as one or the other (all the transactions across different accounts with-in the same financial institution are handled by the financial institutions itself and not sent through the Clearing House).

I know you must be as confused as me when I first read about it J - it helps to understand how this 4 Participants Model work by looking at a sample use case scenario. Let’s walk through a scenario where an employee signs up for direct deposit of paycheck into his personal bank account.

As indicated in the diagram above, an ACH transaction starts when a receiver (employee in example) authorizes the originator to credit/debit money into their accounts (say Bank of America checking account) for any goods or services they have received, by providing his bank’s routing and account information to the Originator (the employer on our example) for direct deposit of paycheck into his account. Once or several times of a day (depending on the business – in case of payroll it would be biweekly or once a month), the Originator (Employer) sends all of it’s transactions (Paycheck information) in a file to it’s ODFI (say Wells Fargo Bank). Once the ODFI processes the files, it debits the money from the Originator’s account for the net value of all the transactions listed in the file.

Similar to the Originator, once a day the ODFI (Wells Fargo Bank in our example) consolidates all the files coming from all of it’s Originators into a single file (format defined by NACHA) and sends it to the Clearing House. The Clearing House processes the ODFI files, sorts the transactions by ABA-RTN numbers and calculates the net position for each financial institution including the transaction fee that the Clearing House charges the ODFI and RDFI for processing the transactions. The Clearing House groups the transactions based on the bank routing numbers, and then send the files to the corresponding RDFIs (in our example Bank of America will receive one).

It must be noted that even though these files contain millions of transactions, the net value for each RDFI might still be zero, or negative in some cases, since almost all the banks and financial institutions act as both ODFI and RDFI for it’s customers sending and receiving money on behalf of them.

Each day after it processes these files, the Clearing House also tells the ODFI and RDFI Financial Institutes whether they (in our example, Wells Fargo Bank and Bank of America) owes money to the Clearing House or the Clearing House owes the money to the financial institution. All the Settlements between the Financial Institutions are done using the accounts that each one of them holds with the Federal Reserve Bank (in case of public Clearing House) or the corresponding Bank of the Bankers (in case of a private Clearing House). Let’s say in our example, the Wells Fargo owes $3M to the Clearing House to provide Salaries to all the employees, out of which say $1M goes to the Bank Of America for all the employees that use accounts in Bank of America and the rest goes to other banks that the employees hold accounts at.

As indicated in the diagram above, the Originator pays the ODFI a negotiated transaction fee varying based on it’s transaction volumes, and it’s negotiating power and relationship with ODFI. There are additional fee for the files that are processed, transaction reports generated, and the process to bank account, etc. The ODFI and RDFI also pay a processing fee to the Clearing House. There are additional fees associated with services (fraud detection, etc.) provided by the Clearing House operator (NACHA). Similar to the ODFI, the RDFI charges it’s consumers a transaction fee based on the type of account (personal or business).

Alright that's it for the Clearing House Based Networks - next up is Card Based Networks, which I am sure is more interesting than the Clearing House Based Networks. :-)

Online Payments for Developers - Part 1

2010-01-20T02:21:00.017-05:00

I must admit, when I joined PayPal 2 months back (in Nov) as the Developer Evangelist for PayPal X, I was little excited and little scared. Well everyone can feel the excitement with new Job, new opportunities, new place, new colleagues, etc., but back of my mind there was always a little uncomfortable feeling about Payments and related things, mainly because it's not only a new technology area for me, but also I never knew how payments work behind the scene. Though I am big time online shopper (bought my car online 10 years back on carsdirect.com - still the biggest purchase I've made online) and a heavy credit/debit card user, to be honest I never really bothered about how they work.

Given my technical background in Online Identity, Authentication and Authorization areas, I was able to quickly come up to speed on the technology side, and with great help from my new colleagues and friends at PayPal, and a few resources online, I've learned a lot about what goes on behind the scenes on the Payment networks now. I know there are a few out there just like me, who is kind of curious to know how it works or want to build something that deals with online Payments but little apprehensive due to lack of understanding of various things that you would have to deal with. So I thought I would give some basic information, which might help you learn a little bit more and helps in building something that might change the way we pay. :-)

Well to begin with, as we all know, Payments in the modern days usually mean transfer of money (in whatever currency it is) from one party to other, made in exchange of goods, and services, or some times as gifts, donation and support. Payments started back in the old days with people exchanging goods and services that they could offer, for another (bartering) from their fellow citizens. But in the modern days, payments are commonly made using Money (currency/cash notes and coins), Credit/Debit Cards, various forms of Checks (Personal, Demand Drafts, Cashier’s, etc.), and Bank transfers from account to account. While the first one that involves money in physical form is called “Cash-based Payments”, all the others that do not involve money in physical form are called “Cashless Payments“.

Also just as there are different types of payments being in use today, there are quite a few different names used to indicate who the Senders and Receivers are for a given payment transaction based on their role and participation.

Cashless Payments are more appealing to everyone as they reduce the overheads of handling cash, cuts down on the risk of theft, the inconvenience of having to the find the right amount of change for a vending or car park machines, and more over, they make payments possible in the online electronic world where direct Cash-based Payments are just impossible.

There isn’t much to discuss on the technical side of Cash-based Payments, apart from the conversion rates across different currencies, several rules and regulations imposed by different countries and governments, several accounting systems that the financial organizations operate on and last but not least the actual printing of the currency J. On the other hand, Cashless Payments are technically more challenging given the various forms of online money transfers, and due to the fact that there is no physical money moved between different parties.

The Cashless payments are typically processed through commercial and Govt. controlled Payment Networks. There are several Payment Networks available to provide the cashless payments functionality in both physical and online worlds. Fortunately for developers, the Payment networks they use online hide most of these complexities. So that gives the developers the choice of choosing the form of payments that best fits their applications and use cases, and in some cases that provides them with the best transaction fee too. Almost every form of payment through a payment network involves either a per-transaction fee or a subscription fee or a combination of both.

Payment Networks

As mentioned earlier, the cashless payments consist of payments using Credit and Debit Cards, various forms of Checks (personal, cashier’s, demand drafts, etc.), and bank transfers between accounts. Out of the 3 types, though more recently they are processed through the same payment network as bank transfers (after they are scanned and processed by banks), the Checks based payments are generally not suited well for the online transactions. The rest of the two falls into 2 types of payment networks categories:

Clearing House Based Network
Card Based Network

Alright I think that's too much for a single post :-) - I will write more about these 2 Payment networks in the next couple of blog posts starting with Clearing House Based Networks.

Disclaimer: This information is in no way a complete/authoritative guide to payments and payment networks. This is just for giving a very quick and high level intro to how online payments work for people like me.

New Role @ PayPal X

2009-12-09T15:10:00.003-05:00

Well as most of you know - I have moved from the rainy Seattle back to the sunny (but chilly! since last one week) Bay Area, where I started my career as a software engineer 9 years back at Netscape/AOL. My short stay at Amazon.com in Seattle has been an interesting experience - learned a lot working on their platform and helped in building a new Authentication Portal for all Amazon.com, AWS, and it's subsidiaries. But as you can guess, that's what I've been doing since last 9 years. :-) It is still exciting to build Web Identity and Authentication Services/Applications, but after 9 years it's definitely not as exciting as it used to be before. Just about the time the new opportunity at PayPal came along to help in their recent efforts to open up their payments platform. What's more interesting than Online Payments for some one with Identity background ? Just kidding ... but just like Online Identity, a lot of things like authentication, authorization, data portability, contacts, activity, risk , fraud, etc..., apply for Online Payments too just at a different (higher) level. So I took the opportunity to join the PayPal Platform team as the Evangelist to help in making Online Payments more sexy. The new PayPal X Adaptive Payments Platform been opened up recently (early Nov at the PayPal Innovate Dev Conference) and the APIs are available for developers to make use of and build/convert/monetize their cool ideas around payments into reality.

I'm looking forward to learn more about the Payments world, help in improving the PayPal's Adaptive Payments platform/APIs and, above all, be the voice of external developers at PayPal. When you get a chance, check out https://www.x.com web site - it's our new developer portal with tons of information about PayPal's platform and APIs.

At the Internet Identity Workshop 2009A

2009-05-18T01:29:00.003-04:00

wow it's been a long time since I've last blogged. Last couple of months have been quite busy with couple of projects on hand. I've almost lost track (other than checking from OpenID and OAuth mailing lists once in a while) of what's going on in the Identity world outside of Amazon. So looking forward to get upto speed on what's going on in the Identity world and also catching up with fellow technologists from other companies.

Concerned about phishing ?

2009-01-06T01:53:00.005-05:00

With all the swirls going on about phishing, Twitter APIs and OAuth - I just wanted to say - user education and awareness is the only way to solve phishing completely. No single technology can stop users from getting phished - unless the user knows what he/she is doing. Even websites using the out of band authentication and some OTP technologies are prone to phishing - an attacker can simply proxy the requests between the user and the real server. What technology can do is to make it easy for the users to learn how to protect themselves from getting phished.

OAuth just does the same - it introduces a consistent way to authorize clients to do something on behalf of a user, with the user's permission and not ask for their login credentials. Yes one might argue that malicious clients can spoof as the provider and phish for user's credentuals, but given that most of the providers allow SSO and session persistence, a user would still get alarmed if he is asked to provide his login credentials again.

Cardspace/Infocard selector provides a better security model against phishing by providing a way to completely eliminate the need for passwords. But if the Identity Providers (STS) still require Username/Password claims even with their managed cards, their users are still prone to phishing attacks.

I would recommend everyone to read the User Interface guidelines written by the Web Security Context working group in W3C.

2009 The Year Of ....

2008-12-31T01:07:00.003-05:00

well everyone is predicting what's gonna happen in 2009 so thought why not me too :-)

Nope, I am not going to predict what technology is going to be widely adopted over another, which company will succeed in their online identity and data portability strategies, etc.... to be frankly I don't care. :-)

2008 has been a good year for Identity (Management and Access Control) and I think it will continue into 2009 with more emphasis on the following things:

User Experience and Value to End Users - I am one of those who say "my mom knows what email is but doesn't know what SMTP/IMAP are" and I want to see the same in online Identity world. Also I am strong believer that SSO alone doesn't carry many benefits to the end users unless there is some data associated with user's Identity that can be shared across different sites/services. IMO - these two together will play a major role in bringing several Identity related technologies into the mainstream.
Interoperability - not just between services/providers but also between various protocols and technologies in the Open (Web) Stack so they can be all stitched together seamlessly and effortlessly to bring better UX and value to end users.

Anyway eager to see what 2009 has for us and looking forward to work on even more interesting things.... and also very eagerly looking forward to hear my daughter (15m old) talking.

Happy and a Prosperous New Year Everyone !

Open User-Centric Connect ?

2008-12-05T12:20:00.004-05:00

Just wondering if anyone started working on building an Open Source Connect-like application using the Open Stack (OpenId, OAuth, PoCo, OpenSocial, etc.) that provides users "control" on what Service Provider they want it to use. Or is Google Friend Connect going to become an Open Source project ?

Basically IMO - it should be a collection of client side Javascipt, HTML/CSS and server side php/java/.. code, which can be deployed by any Web Site. It should let users configure where they want their activities should be posted to, where to bring their contacts/friends from, etc..

Ofcourse all this should be done only using a combination of open standards like OpenID, OAuth, PoCo, OpenSocial, etc..

Thoughts ?

Static OpenID Associations !

2008-11-12T02:16:00.003-05:00

One of the things that I have been thinking about recently is about what changes we would need in OpenID to make it easy to build something that provides seamless user experience like FBConnect (just user authentication not sharing user data like friends list, feeds, etc.).

Of course, with the existing OpenID 2.0 spec, it's quite easy to do it (using a combination of checkid_immediate and checkid_setup calls) but the RPs still need to do some heavy lifting in terms of setting up their servers, databases and database replication, etc.. to run on a farm of servers for scalability and performance. (for example storing and sharing discovery, associations and nonce verification information on multiple servers across different data centers and not to mention issues around enabling outgoing http connections to fetch discovery and associations info)

We could argue that the RPs can just use the check_authentication call to OP to verify the assertion but this adds up unnecessary additional latency in the overall authentication process.

And when it comes to enabling SSO with in trusted circles using OpenID, the dynamic discovery and association steps seems unnecessary. Usually trusted circles are limited in size and are used to sharing keys and secrets (meta-data) in some other offline provisioing process anyway.

So with those in mind I wonder if it makes sense to propose an extension to OpenID that would allow OPs and RPs in a trusted circle to establish static associations such that the RPs can just host a simple php/servlet/perl/.net/etc.. handler that validates the assertion returned by the OP using the stored association information locally.

It goes something like this

Allows an RP to preregister with an OP to get it’s own association data.
RP provides it’s preferred association type (HMAC-SHA1/256), and realm
OP SHOULD do the necessary checks based on their business relationship to make sure the realm provided matches the RP , which is out of scope of this extension
OP generates and provides assoc_handle, mac_key and expires_in
RP uses the assoc_handle in the checkid_immediate and checked_setup requests.
OP MUST always make sure the return_to url matches the realm exchanged during the offline provisioning process – not the realm passed in as a request parameter.
OP MUST sign all the positive assertions with the mac_key corresponding to the assoc_handle passed in by the RP.
If a given assoc_handle is expired, OP MUST fail the request (both immediate and non-immediate) with an openid.mode value as “expired_association” along with the expired association handle value as invalidate_handle parameter.
RP MUST verify the assertion signature locally (must not send check_authentication request to OP)
RP MUST make sure the timestamp passed in the response_nonce is within an allowed time period (say 5 mins)
1. If the RP can do regular nonce checking (to make sure it’s only used once) then it SHOULD do so instead of just checking for the allowed time period as this exposes the replay attacks for a small window of time.
2. Alternatively RP MAY sync it's clock based on OP
RP extracts the user’s identity provided by the OP as per the OpenID specification.

To implement this all an RP would need are

a few config file entries to provide association handle and mac_key to the application code
a simple OpenID handler (php/perl/servlet/etc..) that uses the association information from config file to generate OpenID Server redirect url to request authentication (which can be cached as the assoc_handle doesn't change) and to verify the response from the OP (validate signature, nonce, etc..)

Now compare this with what it takes to become an RP with current OpenID2.0 spec.

Of course I know this is defeating the original purpose and intent of OpenID to provide authentication framework for the internet, but given that several people that have done various user experience analysis and finding that OpenID is more useful and meaningful to users when the RPs provide OP specific login buttons anyway (Login with Yahoo, Login with Google, etc..), would supporting something like this be way off the original intent ? Since this will be an optional extension, people who want to support any OpenID out there can still do it, while others who only care about SSO with a few trusted OPs (that they have business relationship with) do not need to reinvent the wheel.

Also another thing to keep in mind is for other apis/protocols (like OAuth) the RPs would need to share consumer information (keys and secrets) anyway.

Thoughts ?

Account Recovery for terminated OpenIDs

2008-11-11T16:45:00.004-05:00

Wells one question that always comes up when talking about becoming an RP is - what do we do when the OP that our users chose to use, shuts down it's OpenID support ? The answer has always been - well collect your own credentials (which in most cases is a password, because no one wants to collect lots of PII info for online account recovery) so you can let the users recover their lost accounts if necessary in the future. Then the next question comes - well then why do I need to support OpenID and more over it's not solving the original goal of reducing the number of passwords the users have to remember.

Can all OPs provide 99.9% uptime SLA ? Or should every user on the internet have his/her own domain that delegates to a trusted OP and can be changed by the user if necessary ?

Any other thoughts ?

all set for Internet Identity Workshop

2008-11-11T01:40:00.004-05:00

Just arrived in bayarea to attend the IIW from tomorrow. Missed all the fun today but the next two days is when things start getting more serious. Looking forward to participate in various discussions, learn and hear about things related to Identity and Authentication from others and of course meet some good old friends and great technologists from other companies.

I am in particular interested about things happening in the OpenID UX improvements side and also to talk about UX improvements in OAuth for mobile/client apps. It's been a long time (June 26th) since we started talking about OAuth spec updates covering very important usecases at the OAuth Summit - so time now to find out where things are with those too.

With the recent job change and the big relocation from East coast to west, I feel like I have been disconnected with the Identity community. Hopefully this IIW would get me back up to speed.

FB Connect really raising the bar for OpenID ?

2008-10-23T00:50:00.005-04:00

I was reading John McCrea's guest post on techcrunch titled "Facebook Connect and OpenID Relationship status: it's complicated!" and that started me thinking is it really raising the bar for OpenID ? I don't think so. It's raising the bar for OpenID "Providers" to provide better user experience "not" for OpenID itself at the expense of being an example for "just do it your way and don't worry about open standards". Isn't it ? May be I am thinking it so because I missed their presentation at the OpenID UX Summit last monday.

Seriously, FB Connect provides 2 things at it's core -

an identity exchange (or so the called SSO) protocol for sign in, and
a web api to retrieve some information from your profile, friends and post to your activity stream

Then it provides an easy to use web toolkit/library/Javascript built on top of their platform to make the integration easy (totally hiding the complexity in implementing #1 & #2 above). This is not new - several have done it before. But they weren't probably as successful as FB connect is (or will be) because they don't have the same kind of crowd (user base) and utility as Facebook Connect to the end users !?!

Here is an example from the previous company I worked for: Adding AIM buddylist to your webpage (click on see the buddylist widget in action button). Yeah it uses iframe to load the sign in form (which FBConnect used to do when it launched in the beginning) but you get my point.

When we did something very similar (but only for displaying authentication status dynamically) back in my previous job, which we called "Auth touch point Hat" that anyone (internal/external partners) could use to automatically detect and display user's authentication status with as simple as inserting a line of javascript code, it was well taken initially by everyone. (I believe it's still in use on some sites like journals.aol.com and myaccount.aol.com but not so sure ...) But as the sites grew in terms of page views then came along the high performance requirements. They started to hating it because when the browser loads their page, it has to make a connection to the login server (on SSL) to download the JS, which is cacheable but it makes a SSL request back to the host every time the page loads to detect authentication status and also loads couple of static images/css files from CDN (yet another server the browser needs to make connections with). All these add extra weight on the page. If there are enough number of users on the page using it then may be it's a good trade off but otherwise, you are slowing down the rest of the users who don't really care about it. In such cases, it's much more easy to make the Sign In link/button static and deal with the rest only when a user completes the Sign In part and comes back with an Authentication token/assertion. I am sure several other providers might have gone through similar experiences.

Now looking at the # of html elements theinsider.com is loading for FB Connect, I really wonder how long before these guys would start saying it's slowing down my site (even the static content coming from their cdn has "no-cache" headers !?) and go back to static links and do things only when it's really required.

But anyway going back to my original point, it's really an eye opener for all Identity Providers. Unless the SignIn is contextual, has value and easy to understand, end users don't get it. Just merely telling them that you can type your OpenID url doesn't bring in good experience. OpenID has to get away from being a "product" to an "open protocol for WebSSO". One can add all other flavours on top of it (as extensions, OAuth, etc.. as per their needs) to make it really useful to the users. It's really not worth reinventing the whole wheel again and again. Personally I have done it thrice already in my previous jobs - well I did it because there was no one single standard that's been adopted by everyone, easy to implement and use at that time. Not sure why FB Connect couldn't use OpenID protocol as the underlying SSO protocol and OAuth as the authorization protocol and build the rest of the things (exact same UI and UX) on top of them !

Open Services to Open Application Platforms!

2008-10-17T01:48:00.003-04:00

Imagine you are an emerging artist with lots of ideas to create beautiful paintings. Now if I give you 2 options:

I will give you all the material (paint, canvas, brushes, etc..) and you go create whatever paintings that you want to create and display/market/promote them where ever you want
You create a painting in your own workshop using your own materials (I might give you a few tools to help you make the painting even more beautiful - nice frame to put it in, etc..) and bring it to me - I will put in my gallery where thousands/millions/billions of art loving people come to see/buy paintings everyday

Which one would you like the most ? Obviously #2 isn't it ? Materials are something that you can afford on your own (you don't have to be a popular artist to buy this stuff) but getting your art displayed in a popular gallery .. not so easy for many !

That's what exactly is the reason behind why so many providers getting on to the Open Application Platform business. The recent Yahoo Application Platform (YAP) is one such strategy in my opinion. Yeah I can use their Address Book, Mail APIs, Messenger APIs, etc.. to build cool and interesting applications, but how can I get real users find it and use it ? With YAP what ever I build instantly becomes available to millions of users. Obviously this is no different than the platforms that are already available out there (MySpace, Facebook, Bebo, etc..) - but the interesting thing to watch is how end users are going to use it - I don't think Yahoo has any social apps (flickr is one but I don't think there are similar kinds of social circles as you find on others) that are as popular as other social networking sites. As we all know recently with the new UI redesign, at least the Facebook guys kind of deprioritized the importance of Applications on Facebook for several reasons (UI, UX, privacy, etc..). Now we have to see how much control YAP would give the developers control on the UI, position and user data access.

Anyway, I wonder if this is the end of the Open Services era and the start of a new "Applications on the cloud" era. We have already seen the success of iPhone Apps, Google documents are becoming part of day to day work for many instead of MS Office, and many more SaaS based consumer applications.

What's up with FB and SSL ?

2008-10-08T13:13:00.005-04:00

These are the kind of things that make SSL warnings in a browser useless for end users - because they would accept it anyway - deliberately or not !!

Privacy concern with GMail in Firefox 3 ?

2008-10-01T10:28:00.004-04:00

Don't know if any one else have noticed, but when you are reading mails on GMail.com, it changes the html 'TITLE' of the page as the mail subject along with your email address. Something like "Gmail - - ". Since FF3 now displays (I don't remember seeing this problem with FF2) the page title also along with the urls matching in the Location bar, when you start typing "gmail.com", some of your personal data/information could get exposed (look at the screenshot below), unless you make sure you clear all the browsing history in the browser after you are done. Obviously this probably isn't a big concern when you are not sharing your computer with others.

I have checked Yahoo!, Hotmail & AOL webmail applications and they don't do the same - the title of the page doesn't change to the mail subject & email address. So no privacy issues there.

Also IE doesn't seem to display the page titles in location bar although I didn't check in the new IE8 beta.

What it takes to build a Web Authentication Service ?

2008-09-27T16:02:00.003-04:00

I wanted to write about things that a Web Authentication/SSO Service would need to have for a long time but never got a chance to do so. During the last one week I started writing this down whenever I got a chance during my big move to Seattle.

The main reason behind this post is to point out the common features that most of the "Web" Authentication, SSO & Identity Providers would need to provide to support Consumer apps and Services (both internal and external Consumers) :

a way to detect if a user is already Signed-In or not
a way to Authentication users with support for 2nd factor and strong authentication methods where ever applicable
a protocol to exchange user Identity and profile information
a way to request a security token to bootstrap authentication process to invoke services on behalf of the users
a way to validate/verify the security tokens
a way to request user's permission to do something on behalf of the user using the security token
a way to provision required configuration and crypto keys (manual or automatic)
a way to discover various end points (service end points, authentication server end points, etc.)

And of course for the users

a way for user to register account
a way for user to update account information
a way for user to reset authentication credentials (password, security question, etc...)
a way for user to manage permissions/sessions/etc...
a way for user to manage account relationships, Parental Control information and federations

Obviously to provide all the above functionality, it would need

A Token management system to generate secure (encrypted or signed) tokens
A Service management system to provision and manager Consumers and Services utilizing Authentication Services
An Account management system for users to register and manage account information
A Session management system for keeping track of user's activity and authentication status
A Permission management system for keeping track of user's authorization decisions
A front end Web-Application to serve customizable Login UI
A front end Web-Application to handle different protocols,
A Access Control/Authorization System
A Database to store account and credential information
A Discovery system to manage and provide both user and service discovery data
strong security filters to prevent XSS/SQL & Script injection attacks, and
last but not least an Encryption Key management system

All these could exist as different components in a single System or as different services (most commonly) that are used together or a combination of both to build the complete Authentication Service. Oh and don't forget the other basic operational things like logging, metrics, monitoring, rate limiting, etc.. - without those it would be a nightmare for the Operations teams to run and manage the Authentication Systems.

There are several Open Standard Protocols that provide most of the functionalities listed above, so pick and choose the ones that makes the most sense for your needs.

UPDATE: I missed a few mainly the obvious Database to store both account information & authentication/challenge credentials, a discovery service and some kind of "role" management system to access control users to various resources/functionality. Account relationships and Parental Controls kind of fall in the same category.

Social Engineering Attack

2008-09-17T22:14:00.010-04:00

Here is a good example of Social Engineering Attacks:

http://ap.google.com/article/ALeqM5iem-vu_mlRjRYfqkscEkw2ciRm7wD938OLM81

"It wasn't immediately clear how hackers broke into Palin's Yahoo! account, but it would have been possible to trick the service into revealing her password knowing personal details about Palin that include her birthdate and ZIP code. A hacker also might have sent a forged e-mail to her account tricking her into revealing her own password."

A quick look at all the Online Password Reset flows at all major providers, all you need to know is the answer to the Security Question. Some doesn't even verify any more additional data - not that they are hard to guess but at least it adds little more complexity for hackers to try all possible combinations.

A3 >>>> A6

2008-09-17T22:14:00.007-04:00

Two more days left for me at AOL. Since last 2 weeks I have been quite busy doing lots of knowledge transfer and various project transition meetings. It's just amazing to recap the number of things I have worked on, dealt with and learned, and the number of great people I worked with in the last 8 years. I still remember the day one at Netscape (MView) back in 2000 going through the new employee orientation. For the first few months I spent lot of time in learning more about Authentication, SSO, how Passport works, how MagicCarpet works, etc.. - I should say those were the real foundations for me right after coming out of school. Learned a lot from the original authentication gurus at AOL (Chris Toomey and Mike Schilli). I still can't believe how several features that we designed and implemented in the earlier versions of MagicCarpet still being used in several places (both internally and externally). From MagicCarpet to Screen Name Service to OpenAuth- it's been a great ride for me at AOL. I just hope to continue the same in my next job at Amazon - yup a big move from East Coast back to the West. Wish me luck !

SSL != Rocket Science

2008-09-15T12:50:00.004-04:00

Not sure why but since last week I got an impression that most of the developers think SSL as rocket science. :-(

Truth is it's not that complex - there are tons of resources online that describe how SSL works in simple terms. In most cases you just need to read the protocol, and don't worry about the internal details because all those are taken care of applications, packages, libraries, etc.. that have been out there for a really really long time.

Here are some that explain the SSL protocol in simple terms ( I will add more as I find them):

As an application developer dealing with SSL, all you have to worry about is how to manage the SSL certificates (client side or server side), how to manage your CA Certs files so you can verify the certificates presented by the servers, and how to check if a certificate has expired or revoked.

Of course as with any other security software, always make sure you subscribe for the updates to the software you are using for bug fixes and patches that could make your application vulnerable to security attacks.

FBConnect - still insecure ?!?

2008-09-14T16:44:00.009-04:00

Today I realized it's been over 2 weeks since I last wrote on the FBConnect stuff and thought of checking it out again to see if there have been any changes done to improve the security and any other things after their recent Facebook Developer Garage event (called Connect Edition).

Surprisingly the only change they have done is to change the login form into a popup instead of an IFRAME embedded in the site. Here is the screenshot of how it looks now:

But still no SSL ! I wonder why ? Even the form POST is on non-SSL - means your login credentials are in clear and you are vulnerable to MITM attacks (eavesdropping).

AOL.com now with Yahoo Mail and GMail Preview !

2008-09-12T18:09:00.004-04:00

I was pleasantly surprised to see the Yahoo Mail and GMail preview widgets on AOL.com today. I didn't had a chance to talk with the AOL.com developers yet but looks like for Yahoo Mail they are using BBAuth and their Mail APIs but for GMail it's same old story - see "The password anti-pattern" :-(

Hope the GMail team will launch OAuth enabled APIs soon.

Chrome's stats for the nerds !

2008-09-11T14:38:00.002-04:00

First thing I tried after I installed the Chrome last week was the about:config url to see various internal configs and was surprised to see that it's not supported.

But then I found several very useful other pages that are supported by Chrome:

about:memory (you can go to this by clicking on the stats for the nerds link in the Chrome's Task Manager - Shift + Esc)
about:cache
about:dns
about:histrograms
about:internets
about:network
about:plugins
about:stats
about:version

Wonderful!

OAuth for Javascript (AJAX) clients

2008-09-10T11:24:00.000-04:00

Tony reminded me about something on twitter today that I wanted to write about since long time after a discussion on OAuth-Extensions mailing list about how to use OAuth from Javascript based "in-browser" Consumers using various AJAX technologies/methods that are already available.

Before I jump into how this will work - here are some building blocks that you would need:

At the minimum you would need:

OAuth Core 1.0 (this is obvious :-) )
OAuth Custom Response Data Format Extension
OAuth Problem Reporting Extension
OAuth Extension to support unregistered consumers

The following are more for advanced users as they require strong security/access controls:

Cross Domain XMLHTTPRequest using an IFRAME Proxy
The new XMLHttpRequest Level 2 (and related Access Control for Cross-site Requests) and Cross-document Messaging

Alright so the main problem with the OAuth Core 1.0 spec that makes it hard to use from a Javascript Consumer is that all the response error codes are returned as HTTP Status Codes and the response data is in a simple form-encoded format (parameters separated with '=' and '&' signs) .

Almost all methods except for the XMLHttpRequest for doing AJAX calls in a browser neither provide access to the raw HTTP headears nor the HTTP response status code. So it is pretty much not possible to handle OAuth requests and responses unless the Consumer is hosted on the same domain as the Service Provider so it can use XMLHttpRequest or if the Service Provider provides an IFRAME Proxy that the Consumers can use to make XMLHttpRequest (see Cross Domain XMLHTTPRequest using an IFRAME Proxy).

The problem with the response data is that it just doesn't work for jsonp calls, which is the most common way to do cross domain requests using javascript (when XMLHttpRequest cannot be used).

So to solve this problem, couple of extensions were proposed. The first important one is "Custom Response Data Format" Extension, that allows a Service Provider to advertise what other data formats are supported in it's Discovery (XRDS) document and the Consumer can pick the data format that best suites it's need. The default data formats defined in the extension are the most commonly used ones like xml, json, yaml, and amf0/3. Service Providers can define their own data formats too and document them in their own API documentation along with the format identifier and the corresponding processing rules/logic. With this extension, the Service Providers can support the response data in a format that can be easily read and processed by the Javascript Consumers. The most commonly used data format for Javascript clients is "json". The Javascript Consumers can also pass "xoauth_json_callback" to get the response as a jsonp call back.

The second important extension is the "Problem Reporting Extension", which lets the Service Providers to provide more information about the "problem" (error really) with the OAuth request that was sent by the Consumer. We have added some changes to this extension for the Consumer to specify if it wants the status code (which usually represents the error code in case of a failure) returned back in the response body. This would let the Javascript Consumers to be able to read the error code even when using jsonp method and take on the appropriate action.

One last thing to consider for Javascript Consumers is the security of the consumer secret that needs to go along with the consumer key so all the OAuth requests can be signed. Since the code of the Javascript Consumer is visible to everyone, it's not obviously advisable to include the consumer secret also in the same code. So the better way is to use an empty string as the consumer secret and rely on other things that all browsers provide - like HTTP Referer header to enforce the same origin (site) policy and/or HTTP Cookies to enforce same application/browser instance policy. One could argue that both HTTP Referer and Cookies are spoofable and replayable, it's almost impossible to do it in a user's browser with out getting some malware installed on it. But we all know when a malware is installed on a machine, all bets are off at that point.

OAuth Extension to support unregistered consumers defines a way to allow Consumers to use the OAuth end points provided by the Service Providers with no prior provisioing of consumer key/secret. This is mainly useful when you want to allow anonymous consumer access to your APIs with a certain level of security.

With the support for the new XMLHttpRequest Level 2 (and related Access Control for Cross-site Requests) and Cross-document Messaging, Service Providers can allow XMLHttpRequest access to the Javascript Consumers on other domains but as I said above, it requires a very careful configuration of the access control policy files to make sure access is only allowed for the resources that can be shared across domains. Another problem with this is the support for these new versions in the browsers - almost all the newer versions of the browsers support this but as we all know it would take a while before majority of the users upgrade to the newer versions.

The problem with the Cross Domain XMLHTTPRequest using an IFRAME Proxy is that it uses yet another way to transfer data from one domain to another using URL Fragments. It requires bunch of requests and responses back and forth between the iframes to transfer all the data (including HTTP headers and body) and might even cause problems with both Consumer & Service Provider performance.

Hope this is useful. Let me know if I am missing anything and if there any any improvements that can be done. I will see if I can try to build some prototypes when I get some free time.

Simplified Laws of Identity

2008-09-10T09:44:00.002-04:00

Just noticed that Kim Cameron the Chief Architect of Identity at Micosoft posted a simplified version of his Laws Of Identity

"People using computers should be in control of giving out information about themselves, just as they are in the physical world.

The minimum information needed for the purpose at hand should be released, and only to those who need it. Details should be retained no longer than necesary.

It should NOT be possible to automatically link up everything we do in all aspects of how we use the Internet. A single identifier that stitches everything up would have many unintended consequences.

We need choice in terms of who provides our identity information in different contexts.

The system must be built so we can understand how it works, make rational decisions and protect ourselves.

Devices through which we employ identity should offer people the same kinds of identity controls - just as car makers offer similar controls so we can all drive safely."

I particularly like the last point "just as car makers offer similar controls so we can all drive safely" - that's so true. Unless "User-Experience" is thought out from day 1 in all aspects of Identity Management (protocols/identifiers/credentials/information control/permissions/etc..) it will be hard to bring it into the mainstream - most users just don't get it !

Identity Evolution - a personal story !

2008-09-08T10:58:00.003-04:00

This weekend my daughter has turned "1" - we had a great birthday party for her and we were glad she enjoyed it too by clapping to people singing Happy Birthday song for her and cut the cake with her birthday hat and more than that we were very happy that she overcome the fear of strangers and enjoyed the company of all our friends & family.

After the party, on Sunday I started thinking about how in the last 12 months, her Identity evolved not just in the inner circle but also outer trust circle too. By inner circle I mean inside our family and by outer circle I meant friends, neighbors, etc...

I still remember the day a year back when we gave her an "ID" as "Ruchi" on which she didn't even had any say - whether she likes being called Ruchi or not. She was called "Baby Alavilli" for a few hours before which the hospital official came by and asked us if we have decided on any name to finish the required paper work - birth certificate, hospital records, passport app, etc.. Even though we (my wife and I) agreed on the name already - we still had some what strange feeling - mainly after reading a book titled "The Namesake" by Jhumpa Lahiri. Great book btw - if you like non-fiction.

Anyway, so thought about other things we did in the last year ever since was born that kind of helped in establishing her identity all around -

the online ids on google and flickr so she can have her own email address reserved for her and an online photo album that we can share her pictures with friends and family
our family blog where my wife writes about what's going on here with Ruchi so all our family members in US and back home in India can feel more connected to her.
the daily trips to the totlot in our community where she made friends with a lot of other kids
taking her to Ashburn library every saturday for the baby lap-sit and play time
taking her to Cascades library twice a week for the baby garten class
and of course last but not least trying to interact with her using her name at all other times at home.

I think the next task for me is to make sure she gets introduced to the good side of WWW as she starts growing up (along with a computer for sure) - so comes the parental controls, content filtering, etc.... including blocking access to her stuff online from random people (and machines).

Well it's just amazing to see how everything in real life correlate to the digital world. I am very eagerly looking forward to see how she grows up on the digital world in the coming years and (re)establishes her Identity by herself.

Carpet Bombing

2008-09-04T17:20:00.002-04:00

no - I am not talking about the Carpet Bombing related to wars and destruction. This post is about a recent popular topic of interest for many security geeks and probably for Google Chrome browser users - Carpet Bombing flaw in WebKit that effected both earlier versions of Safari (3.1) and Chrome browsers.

Several asked me what is this flaw and why is it called so - so thought I will write up a quick post with some details....

Like the attacking strategy in wars, the Carpet Bombing flaw in browsers is related to a security hole that allows hackers to host malicious code on a web site, which when visited by the users causes the browser to download several files (not just one or two - literally many many many files) on to the user's desktop. Means malicious files could be downloaded and run on the user's machines causing further havoc all without the user's permission. Well it doesn't mean that if the user is asked for the permission, he/she would deny it - given that most people don't even read what's in a window/dialog and just click on "ok" button, but still it's a big problem.

Here is a screenshot of such attack (source Nitesh Dhanjani blog)

Google Mule !

2008-09-04T10:06:00.002-04:00

If you haven't read Aviv Raff's blog it's worth reading - here it is.

"Google Mule

In real life, when you take two species, a horse and a donkey, and mix them up you get a mule. In the browsers world, when you take a horse (Firefox/IE) and a donkey (Safari) and mix them up, you get – Google Chrome."

Access control for cross-site requests!

2008-09-03T15:22:00.002-04:00

http://www.w3.org/TR/access-control/
good or bad ? any thoughts ?

Yeah it's well thought out and a nice way to enforce access controls on the web - but seems like it's making it too complicated (header, policy-path, cache control, etc...) , which would probably make everyone allow access for all "*" in the future - same as what happened to Flash crossdomain.xml in most cases.

Hopefully some one in the ASF will write a simple module for Apache/Tomcat that makes everyone's life easy.

Surprising Google Chrome's EULA !

2008-09-03T14:34:00.004-04:00

well I must say I didn't even bothered to read it when I downloaded and installed it on my other "windows" machine - but some one pointed this out to me today:

http://gizmodo.com/5044871/google-chrome-eula-claims-ownership-of-everything-you-create-on-chrome-from-blog-posts-to-emails

So be careful in what you do using Chrome !

[UPDATE - 9/4] Looks like Google is going to change the EULA - more here.

Open Identity Token and Personal Discovery Service

2008-09-03T10:56:00.002-04:00

This is a follow up to George's post on Open Identity Token to solve use cases like the one described here.

Some thoughts on this use case and Open Identity Tokens in general (in random order)

"Bob’s discovery service" might not know Alice with the same Id (OpenID) - Bob might have only entered Alice's alternate email address that doesn't even resolve to the same OpenID that Alive used currently to sign in to HikingTrails.com
HikingTrails.com might need to go back to Alice's OpenID provider for each (notification) service that it wants to invoke on behalf of the user. Bob might use notification service A, David might use notification service B, and so on... - where A, B, etc.. totally different services.
If the Identity/OpenID Provider provides a Open Token verification API, then it would have no way to make sure the token is being used at the same place for which it is granted. This goes back to the same problem that was solved by doing a RP Discovery in OpenID2.0.
This requires a real discovery service (process) instead of a simple XRDS (static) file hosted some where - since the services defined in the XRDS will be anyway protected, there shouldn't be any harm in saying "my notification service is here and oh btw, it's only open to a restricted list of people so you might not be able to send notification to me".
Open Identity Token seems less trust worthy - of course the same problem that people attribute to OpenID but at least in OpenID case, it is not directly meant for a specific service invocation - it's merely for knowing who the user is and the RP/SP can do more things before it allows the user to do certain things.
Can we do this with a simple extensions to OAuth ? Something like this...
- Consumer gets it's Access Token from IDP(usual OAuth dance) for Alice
- Consumer asks IDP for another Access Token to access another 3rd party service B on behalf of Alice (using 'scope' param) to contact Bob
- IDP checks if Alice has previously given authorization for Consumer to talk with her friend's notification services on her behalf. If not IDP would return 401 unauthorized error instructing the Consumer to send the user back to authorization url (See Scalable OAuth extension).
- IDP generates new access token/secret pair (or updates it's local session ) with new authorization information.
- Consumer makes a OAuth protected resource call (signed) using the new Access Token/secret, and passes Alice & Bob's IDs
- 3rd Party service makes a discovery call on Alice's ID and find the IDP's OAuth end points in it's XRDS file
- 3rd Party service makes a OAuth protected request validation request to the IDP by passing in all the request params it received from Consumer and also adds a special HTTP header with the SIGNATURE_BASE_STRING as it calculates from the incoming request from the Consumer.
- IDP validates the request and returns success or failure
- 3rd Party service let's the Consumer request through to send notification request
- Something like this can be build on top of the ScalableOAuth extension that we are already working on to support session extension and multiple authorization use cases and of course this also assumes the user's ID is discoverable.
- Not sure if I am thinking through all cases but that sounds better than the Open Identity Token model - I hope !
In general in the current social networking era where things (notification) are more publish/subscribe model, not sure how important it is to solve this use case. Most of the user's anyway still use their email addresses not a notification service.
A more practical and useful use case to solve might be for a need to have a personalizable discovery services where the user's can login, select the services they want to use for different things (flickr for photo interest friends, facebook for college friends, myspace for music buddies, LinkedIn for professional contacts, Yahoo for family contacts, etc..) - based on which any Consumer can send the request to the corresponding network based on user's choice. As a user I can say I want to share this with my professional network - so go do what ever it takes to post this into my professional network feed. The Consumer does a discovery on my ID to find out where my Personal discovery service is or the ID discovery itself could cover personal discovery services listed too.

more later ....

Google Chrome - now available for download and developer site

2008-09-02T15:15:00.002-04:00

Try it out - http://www.google.com/chrome - only for winxp/vista though :-(

It didn't give me option to import my stuff (bookmarks, saved passwords, etc.) from Firefox though I am happy with that given that I don't want it to mess up with my Firefox yet. It imported stuff from IE seamlessly. Web pages are definitely loading faster than IE8 (yes I have a beta version) and Firefox (with tons of plugins).

On the cookies side, it's definitely on par with Firefox cookie implementation - so all good unlike the confusing cookie handling in multiple IE processes.

Btw - more info here on the Chromium developer site.

Now back to trying out more Chromium features ......

Facebook Connect

2008-09-02T11:55:00.002-04:00

Several people pinged me about the weird tweet I posted on last friday about Facebook Connect. So let me explain....

Facebook Connect is a new feature provided by the Facebook guys as part of their Facebook Platform to allow their users to expand their online social activity to outside the Facebook website. It is a very interesting, useful and a core functionality that helps everyone to build the Open Social Web for the users.

OF course you would ask so what's the problem - well the first problem is it's YET ANOTHER PROTOCOL - though you can't really say it's a protocol since it's built on top of their existing Facebook platform but it's still does things in it's own proprietary way. No matter how many tool kits and SDKs you provide it's still proprietary and not community driven.

Now the problem that I was referring to in my tweet was about they not using SSL, which is a commonly used "de facto" standard used to transfer sensitive user information (like login credentials) securely on the wire. So this weekend I played more with it and even installed their sample app on my personal site. I could neither find any configuration option where I can say I want to use SSL for the FBConnect iframe nor could I just use 'https' url while loading their javascript (which inserts the iframe). I guess I have to keep looking and may be play with their api directory instead of using their sample code - but I must say using a non-secure example to demo their new functionality is definitely not encouraging. :-/

Google Chrome - Yet another browser or not ?

2008-09-02T10:47:00.000-04:00

Google announced yesterday it's new and a fresh take on browser - on a quick read through their blog post, it definitely sounds very nice as with any other Google's announcements related to Open Source and community driven technologies.

Their comic book approach to introduce the new technologies and the reasons behind their design and implementation was really good. After going through it - it sounded to me like most of it's features and design was derived from people's good and bad experiences with other browsers like FireFox, Safari, Opera and IE. The multi-process vs the threads is probably one of the basic differences between Firefox/Netscape/Mozilla and IE. But yes I agree taking that to the tabs itself is a totally new approach. But I hope it doesn't cause more confusion to the users (at least the tech savvy ones) with the way it's going to handle session cookies.

In Firefox, session cookies are never a problem because they are all stored in the same memory space - regardless of how many tabs/windows you run, they all use the same cookie jar. But in IE it's totally different. Based on how you launch new IE windows, your cookie jar will contain same or totally different cookies with in the same session - they might share or not depending on whether they are launched as new tabs or a new window using Ctrl+N (child process) or a window using IE icon/menu item in the start menu/desktop. This is always confusing to the developers when their applications write both persistent and session cookies, which end up causing different behaviours based on the way users open the IE browser. I am hoping Google Chrome doesn't have the same problem or at least some nice ways for the developers to deal with it.

On the security side I must say I am not too excited - most of the things like blacklisting, sand boxing, and private browsing are already available in other browsers so one would ask what's more it's doing than those ?

Anyway, I am waiting for them to release it to the public so I can try it out myself.

I CAN HAS 'MY OWN' BLOG !

2008-09-02T10:34:00.000-04:00

yey ! I finally decided to start my own blog. After blogging on AOL Developer Network for over an year and on my personal family blog - I guess it's time to have my own so I can exercise my right to Freedom of Speech and/or Expression. (where ever applicable) :-)

I will start writing about existing and new things in the world of Online Identity, Authentication and SSO, and any other interesting technologies that I come across in my day to day life.

Wish me luck!