On 2010-06-05, at 10:46 AM, Luke Shepard wrote: > Thanks for the replies Dick. > > On Jun 5, 2010, at 7:35 AM, Dick Hardt wrote: > >> OAuth standardizes an existing design pattern that had numerous proprietary >> implementations. Of course it will get "adopted" -- the design pattern is >> already implemented. People implement OAuth because they want to get access >> to APIs at a resource. Sure, some of those APIs provide identity data, but >> it is NOT a distributed identity system. > > Agreed. Of course it will get adopted, and it does not by itself provide a > distributed identity system. > >> It is NOT a distributed identity system. If you can make discovery work for >> OAuth, then you can make it work for OpenID. OAuth implementations today do >> NOT have discovery. > > Agreed. OAuth does not say anything about discovery. That's why it would need > to be added in a separate spec.
The discovery part was the tough part in OpenID. It is where the security and usability issues are. We learned many lessons and there has been reasonable consensus around a number of directions we needed to take OpenID -- it just never got going. I unfortunately was prohibited from working on it for quite a period of time. :( > >> OAuth 2.0 does NOT solve the problems that OpenID was trying to solve. > > OAuth does not solve ALL of the problems of OpenID, but it does solve SOME. > From the OpenID website, "OpenID allows you to use an existing account to > sign in to multiple websites, without needing to create new passwords." > That's the same goal that's accomplished by the myriad proprietary providers > out there today, and if many independent companies are choosing OAuth to > solve that problem, then it makes sense to build on top of what's working. Of > course OAuth does not address the decentralized nature of OpenID by itself, > but it could easily be adapted with a separate spec to accommodate them. > > Look, I'm not saying I have all the answers, but it's okay, because at this > point we aren't voting on a spec. The proposal is just to form a working > group, for crying out loud - an email list where we can discuss using OAuth > to advance OpenID, share implementations. > > You said that you think that even considering using OAuth "contravenes the > OIDF Foundation's stated mission." One of the stated missions of the OpenID > Foundation is to "supporting expanded adoption of OpenID". If OAuth is going > to become a widely adopted internet technology, then it seems plausible that > building on top of OAuth could dramatically increase OpenID adoption. Maybe. I would be interested to hear what OAuth has that OpenID does not have. OAuth was standardizing an existing problem, so easy to adopt. I am not clear why building on top of OAuth is better. I have a number of technical concerns about OAuth's trust model. Happy to have those conversation in a WG or on the specs list. Would like a clear charter for the WG so that we all know what is in scope and what is out of scope. > Putting up roadblocks this early in the process prevents innovation when it > needs to happen most. I am supportive of people trying different techniques out. The Connect Charter is vague and broad. As a member of the specs council, I asked David to clarify a number of aspects of the proposal the day he posted it. I got some response yesterday. So far it seems that David does not feel it important to respond to my technical questions. He did not bother to solicit any feedback from me on the Connect proposal -- he sprung it upon the community with some backing after some back room conversations -- hijacking the work that had started around OpenID v.Next. -- Dick
_______________________________________________ board mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-board
