<br><br><div class="gmail_quote">On Sun, May 16, 2010 at 11:40 AM, David Recordon <span dir="ltr"><<a href="mailto:recordond@gmail.com">recordond@gmail.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 Sun, May 16, 2010 at 2:45 AM, Santosh Rajan <span dir="ltr"><<a href="mailto:santrajan@gmail.com" target="_blank">santrajan@gmail.com</a>></span> wrote:<br></div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
David,<div><br></div><div>Couple of questions I have.</div><div><br></div><div>1) If "OpeniD Connect" is about OAuth 2.0 why use the name OpenID at all? What has OpenID got to do with OAuth 2.0? Why not call it "OAuth Connect"?</div>
</blockquote><div><br></div></div><div>To me, OpenID is about identity and OAuth is about authorization. </div></div></blockquote><div><br></div><div>If that's really true, then why bother fixing OpenID 2.0? OpenID 2.0 does a fine job separating identity from auth(mumble)ation. But that is exactly one of its problems: it delivers an identity assertion to an RP, and doesn't worry about anything else. The OpenID assertion cannot be used to _authenticate_ HTTP requests from the browser to the RP's server - it has a nonce in it that will prevent it from being used (unlike cookies) more than once. So the RP has to run its own cookie/HTTP session handling code, which is a pain in the neck. </div>
<div><br></div><div>To me, one of the insights in this whole OpenID-on-top-of-OAuth debate has been that browser-to-server auth is no different than server-to-server auth. We call the former "authentication" and the latter "delegated authorization". But it's all the same - a request comes in (in the former case - a request from a browser, and in the latter - a backchannel request from some server) and a server needs to decide whether data can be returned, and what data.</div>
<div><br></div><div>OpenID Connect should make it easy for the recipient of such a request to decide whether it's legitimate, what privileges the requester has, etc. And the mechanism in both cases (browser-to-server and server-to-server) should be the same. I shouldn't have to run my own cookie-handling/HTTP-session mechanism just because the requests I'm processing come from browsers, not from other servers. So providing just "identity" is a goal that falls short of what we need to accomplish. </div>
<div><br></div><div>Your own proposal, by the way, goes beyond the distinction of identity/auth(mumble)ation: You say that the openid response can be used as a cookie to _authenticate_ browser requests to the RP. You can't do that with an OpenID 2.0 assertion, but you _can_ do it with this. I think that's awesome, but it shows that you, too, want a protocol that goes beyond identity. </div>
<div><br></div><div>Instead of worrying about identity, what we should worry about (and what your proposal almost accomplishes) is an auth mechanism that works both for browser-to-server _and_ server-to-server (and device-to-server, and flash-app-to-server, etc.) calls. (Identity is something secondary that falls out of the process once the request is authenticated.) I say "almost" because your proposal has two different token formats: There is the OAuth access token that is used to authenticate server-to-server calls, and then there is the "OpenID Connect token" (which consists of a bunch of different response parameters all lumped together as a cookie) that is used to authenticate browser-to-server calls. I think we can make this even easier, more consistent (and, btw, more secure - I believe you're missing a couple of necessary parameters in the signature).</div>
<div><br></div><div>Can't wait to talk about this at IIW.</div><div><br></div><div>Dirk.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div>When we built OpenID we had Yadis for discovery which we built on top of, but didn't have another technology for authorization. This meant that we created our own mechanism around how the redirects happen, parameters are encoded, and the signatures generated and verified.</div>
<div><br></div><div>Today we can replace all of that with OAuth 2.0. So OAuth builds on top of HTTP, SSL, HMAC, etc which we can directly take advantage of.</div><div class="im"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>2) I thought OpenID was about "Federated Identity". On the other hand OAuth 2.0 is about "Delegated Identity". Are you dumping the idea of "Federated Identity" once and for all for OpenID?</div>
</blockquote><div><br></div></div><div>OpenID Connect is still about decentralized identity. "Federated Identity" means one (or a small number) of providers within a previously agreed upon circle of trust. One of the key things this proposal adds to OAuth 2.0 is the ability to have a client the server has never heard of before make an OpenID request. See <a href="http://openidconnect.com/#associations" target="_blank">http://openidconnect.com/#associations</a>.</div>
<div class="im">
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>3) My apologies for asking such blunt questions. I will appreciate your answers for this. And if you have a good answer I will be your no 1 supporter.</div></blockquote><div><br></div></div><div>No problem, as I said this is really meant to help get the conversation going again!</div>
<div><br></div><font color="#888888"><div>--David</div></font><div class="im"><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Thank you so much,</div>
<div>
Santosh</div><div><br><div class="gmail_quote"><div><div></div><div>On Sun, May 16, 2010 at 5:27 AM, David Recordon <span dir="ltr"><<a href="mailto:recordond@gmail.com" target="_blank">recordond@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div>
The past few months I've had a bunch of one on one conversations with a lot of different people – including many of folks on this list – about ways to build a future version of OpenID on top of OAuth 2.0. Back in March when I wrote a draft of OAuth 2.0 I mentioned it as one of my future goals as well (<a href="http://daveman692.livejournal.com/349384.html" target="_blank">http://daveman692.livejournal.com/349384.html</a>).<div>
<br></div><div>Basically moving us to where there's a true technology stack of TCP/IP -> HTTP -> SSL -> OAuth 2.0 -> OpenID -> (all sorts of awesome APIs). Not just modernizing the technology, but also focusing on solving a few of the key "product" issues we hear time and time again.<div>
<br></div><div>I took the past few days to write down a lot of these ideas and glue them together. Talked with Chris Messina who thought it was an interesting idea and decided to dub it "OpenID Connect" (see <a href="http://factoryjoe.com/blog/2010/01/04/openid-connect/" target="_blank">http://factoryjoe.com/blog/2010/01/04/openid-connect/</a>). And thanks to Eran Hammer-Lahav and Joseph Smarr for some help writing bits of it!</div>
<div><br></div><div>So, a modest proposal that I hope gets the conversation going again. <a href="http://openidconnect.com/" target="_blank">http://openidconnect.com/</a></div><div><div><br></div><font color="#888888"><div>
--David</div></font></div></div>
<br></div></div><div>_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
<br></div></blockquote></div><br><br clear="all"><br>-- <br><a href="http://hi.im/santosh" target="_blank">http://hi.im/santosh</a><br><br><br>
</div>
</blockquote></div></div><br>
<br>_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
<br></blockquote></div><br>