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

Peter Williams pwilliams at rapattoni.com
Sat Apr 11 00:32:04 UTC 2009

-----Original Message-----
From: Luke Shepard <lshepard at facebook.com>

One way could be an extension that allows an OAuth consumer to ping the provider directly with a username and password, and get a token directly. Yes, this has issues with trust and security. But my point is that these apps are being built already, and wouldn't it be cool if they were built using open standards?yes it would be cool.


Do we realy need -another- open standard, tho?

Being only semi-competent, it took me about 8 hours the other night to get the idp-side token server from ping identity for my first time to receive from my client app  a username+password (according to open standard token format), translate it into a signed saml assertion after passing auth against ldap (both open standards), attach it to the soap header (which took 7.29 hrs) and retrieve it from the app context at the service to have the validating sts (another ping server supporting rp affiliations) confirm the tokens origin, trust it for the interace being bound, and release the username (and roles etc) to the access manager guarding the service business  logic. Had nothing whatsoever todo with browsers...or http (particularly).

By the time peter can personally actually make something work, stuff is ready for mass market...

Tis true - that its also often the point at which someone comes along riding the same wave and makes a simpler variant, that does 80percent of the same with half the overhead.

----- Original Message -----
From: general-bounces at openid.net <general-bounces at openid.net>
To: Peter Williams <pwilliams at rapattoni.com>
Cc: OAuth <oauth at googlegroups.com>; OpenID List <general at openid.net>
Sent: Fri Apr 10 16:49:52 2009
Subject: Re: [OpenID] Can we make a seamless OpenID mobile experience?

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


+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