I just came agross to your interessting blog about mobile OpenId. I am new to the OpenID topic but have some experience in mobile.

In my opinion the success of mobile openID will depend mainly on usability.

You have at least to
1. type in your OpenID each time you access a website
2. type in the SMS (basically very secure but probably not suitable for mass market.
Too many clicks and to much to type on the small displays was (among the slow speed) one of the causes of the the flop of WAP Services at the beginning of this century.
The number of inputs and clicks should be reduced.

Here my idea:
1. could be solved by “proactive HTTP header-based Discovery”:
You pass the openid.server along with in every HTTP request (it is not your personal ID so you don’t care…).
Then the Relying Party can redirect you automatically to the OP server (so step 1 is automatic).
Your mobile browser would need to allow setting the name of your open id server in the HTTP Headers (e.g. x-openid.server: http://www.myopenid.com/server).
(Btw. Firefox already allows setting HTTP headers… so it would make surfing on your PC also more confortable
Alternatively you could configure the mobile browser to use some HTTP Forward Proxy which would insert the HTTP header on your behalf.

2. Once you are redirected to the OP, this can use permanent cookies to “identify” you and present you directly the password field.

Of course this may require an extension of the Open ID standard protocol because any RP willing to provide access to mobile would have to read the HTTP header from the request, but if there is enough interesst around…
There is already a HTML-Based Discovery, so why not an HTTP Header based Discovery?

What do you think?

Adrian

I like the fact we can rely on the phone number as such a unique and personal token. My thinking even goes so far that there could be be a DNS-like system one day for associating mobile phone numbers with an OpenID record — I could use it as an alias to my OpenID Url, on a phone or anywhere. (My DNS record could be updated/overwritten by my OpenID provider whenever I successfully claim ownership of the number)

But back to mobile login flows: from the user’s point of view, I would strongly favor a solution that doesn’t require a break in medium, i.e. that doesn’t switch from the mobile browser to my SMS inbox and back. Copy/Paste is a poorly supported paradigm on phones and if you ever tried to remember a phone number while switching between two mobile screens, you know how cognitively unpleasant it can be. Even if it’s just a short code, it doesn’t feel right to rely on the user (and their short-term memory) to do the transfer. What am I missing that makes mobile OpenID so different from web-based authentication? If we come to agree that your OpenID should be responsible for verifying and keeping your phone number on record (I certainly think this makes good sense), then the flow could stay entirely web-based or not? Certainly, OpenID providers would need to support mobile login UIs (and possibly mobile numeric PIN-based password) for an optimal experience but that could be a matter of time given the increasing adoption of mobile web services.

Thanks for leading the way on this much-needed discussion, Chris.

Instead of sending the user’s cell phone number to the RP, it may be better for the OP to provide an OAuth protected messaging API to allow the RP to send SMS (or email) to the user without having to know the user’s email address or phone number. Users who do not want to receive any more messages from the RP can just revoke the OAuth token.

Additionally, the OP can manage the user’s SMS preferences, for instance, users can set limits for the number of SMSes that can be sent to their phone per month in order to avoid getting overcharged by their wireless carrier. Users could also configure their OP to not send SMSes while the user is likely to be asleep.