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

Breno de Medeiros breno at google.com
Fri Apr 10 21:09:53 UTC 2009

Actually, the subversion client fits reasonably well in this paradigm:

1. The shell interface has a convenient mechanism to accept variable
input. So the choice of entering a password there.

2. The fact that the password does not get exchanged for another token
(single-user vs. pairing) is a consequence here of the fact that
subversion clients do not support OAuth; and the shell interface is a
reasonably convenient mechanism to enter long, strong secrets
(cut-and-paste from SVN server UI to shell client).

In general, the human-to-device channel cannot conveniently accept
large secrets (the svn client example is an exception in this setting)
and therefore you need a shorter, single-use secret to leverage a
pairing of stronger crypto token. The OAuth protocol effectively gives
you this pairing.

In general, the model of single-use code to be leveraged as a 'request
token secret' and the full OAuth exchange give in general a mechanism
that is both more usable (because requiring users to enter short
secrets) and  more secure (because it uses signatures for fetching
data instead of playing the same secret over what may be insecure

On Fri, Apr 10, 2009 at 1:55 PM, Deron Meranda <deron.meranda at gmail.com> wrote:
> 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


+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

More information about the general mailing list