On Sun, May 16, 2010 at 11:40 AM, David Recordon <[email protected]>wrote:
> On Sun, May 16, 2010 at 2:45 AM, Santosh Rajan <[email protected]>wrote: > >> David, >> >> Couple of questions I have. >> >> 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"? >> > > To me, OpenID is about identity and OAuth is about authorization. > 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. 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. 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. 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. 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). Can't wait to talk about this at IIW. Dirk. > 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. > > 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. > > > >> 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? >> > > 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 http://openidconnect.com/#associations. > > > >> >> 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. >> > > No problem, as I said this is really meant to help get the conversation > going again! > > --David > > > Thank you so much, >> Santosh >> >> On Sun, May 16, 2010 at 5:27 AM, David Recordon <[email protected]>wrote: >> >>> 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 (http://daveman692.livejournal.com/349384.html). >>> >>> 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. >>> >>> 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 >>> http://factoryjoe.com/blog/2010/01/04/openid-connect/). And thanks to >>> Eran Hammer-Lahav and Joseph Smarr for some help writing bits of it! >>> >>> So, a modest proposal that I hope gets the conversation going again. >>> http://openidconnect.com/ >>> >>> --David >>> >>> _______________________________________________ >>> specs mailing list >>> [email protected] >>> http://lists.openid.net/mailman/listinfo/openid-specs >>> >>> >> >> >> -- >> http://hi.im/santosh >> >> >> > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
