The solution would be to use OAuth, but I don't see how you escape the browser requirement in the case of IRC because IRC itself is not all that secure.<div><br></div><div>Furthermore, you shouldn't really be sending OpenID credentials over an IRC channel... that seems akin to the password anti-pattern where someone could easily intercept the transmission of data between you and the OP.</div>
<div><br></div><div>You would need to manage authentication out of band some other way... </div><div><br></div><div>Consider the work on OAuth over XMPP:</div><div><br></div><div><a href="https://stpeter.im/index.php/2008/07/23/quick-oauth-notes/">https://stpeter.im/index.php/2008/07/23/quick-oauth-notes/</a></div>
<div><a href="http://xmpp.org/extensions/xep-0235.html">http://xmpp.org/extensions/xep-0235.html</a></div><div><br></div><div>Also, I proposed a PIN approach for low-value OpenID transaction where all you want to do is get identity:</div>
<div><br></div><div><a href="http://factoryjoe.com/blog/2008/10/30/lightweight-access-pins-a-modest-proposal-for-enabling-openid-in-desktop-and-mobile-apps/">http://factoryjoe.com/blog/2008/10/30/lightweight-access-pins-a-modest-proposal-for-enabling-openid-in-desktop-and-mobile-apps/</a></div>
<div><br></div><div>I can't say that my proposal is ideal either, but it would enable the kind of authentication that you've described without sacrificing your primary credentials.</div><div><br></div><div>I'm sympathetic to the idea of being able to just authenticate with a username/password and still get the benefits of OpenID, but that's just not realistic (AFAIC).</div>
<div><br></div><div>Chris<br><br><div class="gmail_quote">On Sat, May 16, 2009 at 10:23 AM, Yonas <span dir="ltr"><<a href="mailto:googelly.eyes@gmail.com">googelly.eyes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I had a long discussion with josephholsten on <a href="http://freenode.net/#openid" target="_blank">freenode.net/#openid</a> about how<br>
to enable OpenID for IRC.<br>
<br>
The requirements were that the user should not need to leave his IRC client<br>
to login, and not need to use his browser. The problem right now is that the<br>
OP presents the login page for a browser. Without resorting to parsing the<br>
form for login and password fields, we cannot login outside of a browser.<br>
<br>
Joseph's recommendation was to enable OAuth on the OP. The OP can advertise<br>
that it speaks OAuth, and the IRC client would login, and pass the OpenID<br>
results to the IRC server. The login flow would be:<br>
<br>
1. IRC Client: /openid register <a href="mailto:foobar@example.com">foobar@example.com</a> mypassword<br>
2. IRC Client sends message to IRC Server<br>
"I'd like to begin an openid login. The OP is <a href="http://example.com" target="_blank">example.com</a>"<br>
<br>
3. IRC server creates a OpenID Authentication Request for <a href="http://example.com" target="_blank">example.com</a><br>
4. IRC server sends request URL to IRC client<br>
5. IRC client confirms that <a href="http://example.com" target="_blank">example.com</a> speaks OAuth via WWW-Authenticate<br>
Response Header, scheme=OAuth (<a href="http://www.ietf.org/rfc/rfc2617.txt" target="_blank">http://www.ietf.org/rfc/rfc2617.txt</a>)<br>
6. IRC client authenticates via OAuth<br>
7. Example.com sends back OpenID success response<br>
8. IRC client sends OpenID success response to IRC Server<br>
"This is the response information"<br>
<br>
9. IRC server uses this information to confirm/verifies that the login was<br>
successful<br>
10. IRC server now recognizes the user as <a href="mailto:foobar@example.com">foobar@example.com</a><br>
--------------------<br>
<br>
The OpenID 2.0 spec says the OP --> end-user authentication method is out of<br>
scope, "The OP establishes whether the end user is authorized to perform<br>
OpenID Authentication and wishes to do so. The manner in which the end user<br>
authenticates to their OP and any policies surrounding such authentication<br>
is out of scope for this document. "<br>
<br>
Here's my opinion:<br>
<br>
1. OpenID login should not require a web browser.<br>
I feel very strongly about this, because we have a big effort for enabling<br>
a single set of credentials on the Internet, but no standard way to<br>
authenticate those credentials without a browser! For eg., if the auth<br>
method did not require a browser, I could easily OpenID enable my favourite<br>
FTP server. In fact, we could create a standard C/C++ library (or add to<br>
libopkele) that would easily OpenID enable anything.<br>
<br>
2. OpenID should incorporate 2-legged OAuth into the login method.<br>
I did a little reading about SAML, OTP, etc, but I think OAuth<br>
is....nice? :) 2-legged OAuth would be a very secure, portable, and<br>
standard way to authenticate your OpenID. Sounds sexy, eh?<br>
<br>
3. Using client certificates was brought up, but a password method must<br>
exist as well.<br>
<br>
Please let me know what you guys think. I'm really looking forward to seeing<br>
OpenID enabled in services outside of the browser.<br>
<br>
Cheers!<br>
Yonas<br>
<font color="#888888"><br>
--<br>
View this message in context: <a href="http://www.nabble.com/Enable-OpenID-for-IRC-tp23575937p23575937.html" target="_blank">http://www.nabble.com/Enable-OpenID-for-IRC-tp23575937p23575937.html</a><br>
Sent from the OpenID - General mailing list archive at Nabble.com.<br>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Chris Messina<br>Open Web Advocate<br><br><a href="http://factoryjoe.com">factoryjoe.com</a> // <a href="http://diso-project.org">diso-project.org</a> // <a href="http://openid.net">openid.net</a><br>
This email is: [ ] bloggable [X] ask first [ ] private<br>
</div>