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

Peter Williams pwilliams at rapattoni.com
Fri Apr 10 23:37:42 UTC 2009

we surely we not are heading back to one time passwords, are we?

Otp is where websso started over decade ago, as the rsa/securid inter domain cookie! Plugin an nsapi in the otp verifing site, plug another nsapi/isapi/servlet on the other sites which had no agent to verify otps, create an artifact backchannel to create the target cookie subverting the sandbox, one gets saml, and then openid...

-----Original Message-----
From: Breno de Medeiros <breno at google.com>
Sent: Friday, April 10, 2009 2:52 PM
To: Deron Meranda <deron.meranda at gmail.com>
Cc: OAuth <oauth at googlegroups.com>; OpenID List <general at openid.net>
Subject: Re: [OpenID] Can we make a seamless OpenID mobile experience?

Reposting this to OAuth, since they did not like my previous attempts.

On Fri, Apr 10, 2009 at 2:09 PM, Breno de Medeiros <breno at google.com> wrote:
> 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
> connections).
> 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
> --
> --Breno
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)


+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
general mailing list
general at openid.net

More information about the general mailing list