Reposting this to OAuth, since they did not like my previous attempts. On Fri, Apr 10, 2009 at 2:09 PM, Breno de Medeiros <br...@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.mera...@gmail.com> > wrote: >> On Fri, Apr 10, 2009 at 3:34 PM, Breno de Medeiros <br...@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) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
