<div class="gmail_quote">On Mon, Jun 1, 2009 at 11:03 PM, Ben Laurie <span dir="ltr"><<a href="mailto:benl@google.com">benl@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Jun 1, 2009 at 10:22 PM, Chris Messina <<a href="mailto:chris.messina@gmail.com">chris.messina@gmail.com</a>> wrote:<br><br>
> And, FWIW, Google Code and Basecamp both provide a decent solution for<br>
> dealing with OpenID users in cases with browser-less situations like the<br>
> command-line... by providing a revokable/resettable secret that can be used<br>
> in combination with one's OpenID to perform CLI authentication w/o creating<br>
> a new username.<br>
<br>
</div>I don't think Google Code does ... but clearly it could, using the<br>
mechanism it currently uses for generating passwords. That is, as you<br>
say, a resettable random string, which could be used as an unguessable<br>
user ID instead of as a password. Alternatively, if we used email<br>
addresses as IDs, their email address could be their user id and<br>
OpenID used to generate the password, much as Google Code does today.<br>
Just saying.</blockquote><div><br></div><div>I should have been more clear.</div><div><br></div><div>Google Code DOES NOT yet support OpenID, but it does provide a "GoogleCode.com password" that is used as an alternative to your Google password in order to interact with its system:</div>
<div><br></div><div><a href="http://www.flickr.com/photos/factoryjoe/3588867545/">http://www.flickr.com/photos/factoryjoe/3588867545/</a></div><div><br></div><div>Basecamp, meanwhile, provides the user with a separate username and password for accessing a project's RSS feed, meaning that these credentials can be reset if they are compromised, or better, in the case of shared workspaces, invalidated if someone leaves a project:</div>
<div><br></div><div><a href="http://www.flickr.com/photos/factoryjoe/2723687290/">http://www.flickr.com/photos/factoryjoe/2723687290/</a> </div><div><br></div><div>From a UI perspective at least, these two approaches solve the "well what do I do for OpenID users when they need a password?" question. It also means that these UIs code be used to generate OAuth tokens where the consumer key is the user's OpenID (or some normalized version of it) and the secret is some randomly generated string.</div>
<div><br></div><div>Chris</div></div><br>-- <br>Chris Messina<br>Open Web Advocate<br><br>Website: <a href="http://factoryjoe.com">http://factoryjoe.com</a><br>Blog: <a href="http://factoryjoe.com/blog">http://factoryjoe.com/blog</a><br>
Twitter: <a href="http://twitter.com/chrismessina">http://twitter.com/chrismessina</a><br><br>Diso Project: <a href="http://diso-project.org">http://diso-project.org</a><br>OpenID Foundation: <a href="http://openid.net">http://openid.net</a><br>
<br>This email is: [ ] bloggable [X] ask first [ ] private<br>