OAuth/OpenID for online transactions?
I’ve been reading this incredibly interesting interview with an adware author, and here’s this line that I just think is so great:
If you think about it, when I use a credit card, the security model is the same as that of handing you my wallet and saying, “Take out whatever money you think you want, and then give it back.”
Bingo. How about another model, where a credit card number functions more like an OpenID, and maybe OAuth (don’t know which would be better here), and you’re sent to your bank’s site via the credit card vendor’s redirector (preferably in a way where, like OpenID, you’re supposed to type in the bank’s site in your address bar so that you don’t get phished). Then, you are told when you log in that such and such a vendor is wanting to debit your card for this amount (once/on a recurring basis), and you approve that and are sent back to the site, kinda like with Google Checkout.
Maybe the next step isn’t OID/OA, but banks running their own PayPal like services (which will not happen for quite some time, if ever, don’t delude yourselves), and also hell freezing over.
Chris Messina had this to say,
January 14, 2009 @ 4:17 pm
I think this is essential for OpenID — and something that I’ve taken for granted as the next step for OpenID and OAuth.
If you can imagine that instead of an identity wall to access a service, you have a “pay-wall” instead – and you advertise your payment broker on your OpenID (using what’s called “Discovery”), you could facilitate OpenID as a mechanism for autofilling your payment source — then you authenticate (or do an OAuth-like dance) — and authorize access to disperse a certain amount of funds…
This is also why I call your collection of “stuff” online “data capital”. You access your private Flickr photos to same way you access your money in the bank. And the more you have of it, usually the better.