But even if everyone agreed to offer such APIs, you’re left with a UI problem: all of these UIs currently ask users for “username/password” or “email/password” since today most sites have their own login database. I think we need some creative solutions for how/when to ask for “OpenID/PIN” and what form that takes. There’s also the issue of how/when users know to get a PIN, and do they remember it, and how temporary/hackable/etc it is.

But this problem is not going away, and it’s going to prevent many large services from becoming RPs if we don’t solve it, so let’s keep this going, and let’s have a session on this at IIW.

Thanks, js

an interesting idea that still has one serious problem; it assumes the mobile (or desktop) login isn’t the first usage.

SMS pincode latency is (imo) less of a problem than bouncing users in and out of browsers.

I think if Oauth is going to work, it has to stop assuming there’s a browser in the loop. That or accept it’s not a general purpose model.

@George: I do think that we need to be able to address the limitations of multiple devices, some of which won’t or can’t be upgraded and will continue to rely on a username and some shared secret (aka password or PIN) to handle authentication. The point of the PIN is to address those situations — so that you can still use your favorite identifier without using your main account password.

A premise here of the PIN model is that certain “low risk” actions could be performed with the PIN — but other actions — resetting your password, deleting your account, publishing content (maybe) would not be allowed. This would be determined on a service by service basis (probably by the service provider itself or in collaboration with the user — “allow these actions to be performed with only PIN authentication”).

@Stephen: it’s not just user confusion. It’s that you need to address the situation where you have an identifier (an OpenID) but no password to access your account. A PIN approach would be similar to what 37 Signals uses in Basecamp feeds, etc.

In the use case above, a hacker could attempt to guess the lightweight PIN. In this case, there is no out-of-band notification to the user. So there is less likely hood that the user would know they are being hacked. I suppose that could be mitigated with SP notification via email, SP rate-limiting and allowing only one attempt per un-authorized request token.

For devices like phones with only a numeric keypad, and set-top-box units like TiVo, I’d still prefer a mechanism that used my laptop to set it up. I realize there are a lot of people where the only connected device they have is a cell-phone so this approach doesn’t work for everyone.

Maybe we need a couple of “best practices” for this kind of UX and then allow the apps to determine which one is best for their environment.

The dependency on a browser is still there, of course. I’m not sure how much traction this approach would get in practice.

The reason for the PIN is that the latency of SMS can really kill a sign on experience… not to mention that not everyone can provide SMS-based messages.

As for sending a token via email, in the case of Gmail/webmail, if you don’t have tabs, you’re still exiting your flow, in which case you might as well do full on OAuth.

One other aspect of the PIN idea is that you could set up, say, more than one PIN… each with different types of pre-set permissions… like “read private data”, “delete one item”, “send me email”, etc… If you keep your PINs simple, this could work, though it is a bit of a lead-user/uber-geek idea.

If we do not want to make some users pay for the SMS, we can use email (most devices provide access to your email) or even an automated phone call to ask for user confirmation.

We talked about this at the last IIW as a possible extension to OAuth but we never wrote anything down.