[OpenID] Can we make a seamless OpenID mobile experience?

[Deron Meranda]

On Fri, Apr 10, 2009 at 3:34 PM, Breno de Medeiros <breno at google.com> wrote:
> The idea is to use a single-use code of some kind that works as a
> password substitute (since the user does not have a password at the
> site because he/she signs in using OpenID), followed by the
> installation of a longer-lived token on the device. Think about
> bluetooth pairing of devices as the basic paradigm.

This is not just a mobile or device issue.  I do something similar
now, for example, to support Subversion version control.  The client
is typically a Unix command line, and the communications is HTTPS +
DAV.  No browser there, and probably not even a GUI.

Basically, my RP (which hosts subversion among other things) issues a
single-purpose password for a user once they are authenticated via
OpenID.  Then, just for the subversion/DAV portion of the website's
URL space, I allow standard HTTP authentication.

Also for subversion, most clients will try to "remember" the password
once a DAV connection is configured for a local workspace.  So as not
to break that, the password (which my RP picks) should not readily
change.  This password is single-purpose, not single-use---which would
be prohibitively frustrating for the user in this case.

If your RP has it's own user ids; you can store your subversion
passwords easily enough.  If not, then you can use something like an
HMAC hash of the claimed_id, using a secret key, to generate the
passwords for each user.  You also probably want to use some sort of
hash on the claimed_id to generate the usernames (as would go in
change lists, etc.); since arbitrary URLs are not syntactically
suitable for subversion "users".

Since my RP generates these passwords rather than the user picking
them, they can be quite strong.  Also I don't have to worry about the
user forgetting them and getting locked out; since the user can just
login via OpenID and then view the password when needed.

For the end user, they will have to login via OpenID at least once, to
learn what their subversion username/password is.  Then they can use
subversion in the normal way, without OpenID.

You can do additional security checks if you want.  Such as only
allowing the subversion password to work if a (relatively recent)
OpenID session has been created from the same location.


Granted, this puts a lot more work on the RP and it's not seamless.
But it is doable, and doesn't generate a mass of rarely-used
complexity in the OpenID protocol itself, or a rewrite of lots of
applications that know how to do standard HTTP authentication.

-- 
Deron Meranda