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

Fri Apr 10 23:49:52 UTC 2009

No, this is not OTP. OTP requires you to enter a new code every time.
OAuth enables long-lasting or ever-lasting secure associations
(launched from a one-time-user, setup-time-entered-only secret). This
is not old OTP raising its head, it is very similar to current
industry-standard ways to associate devices (again, analogy with
bluetooth pairing).

On Fri, Apr 10, 2009 at 4:37 PM, Peter Williams <pwilliams at rapattoni.com> wrote:
> 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)
>>
>
>
>
> --
> --Breno
>
> +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
> http://openid.net/mailman/listinfo/general
>

-- 
--Breno

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