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 <[email protected]> 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 <[email protected]> > Sent: Friday, April 10, 2009 2:52 PM > To: Deron Meranda <[email protected]> > Cc: OAuth <[email protected]>; OpenID List <[email protected]> > 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 <[email protected]> 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 <[email protected]> >> wrote: >>> On Fri, Apr 10, 2009 at 3:34 PM, Breno de Medeiros <[email protected]> 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 > [email protected] > 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) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
