Santosh, Now is not the time and OpenID alone is insufficient.
Getting identity fully integrated with the browser will be watershed event. If we get it wrong, we just slow things further. We want it to happen when we have enough experience and can cover most of the use cases. Since most people only have one browser, it needs to work at all RP websites and handle all common use cases. It needs a universal, consistent user experience to login/connection using userid/password, OpenID v2, OpenID V.Next, IMI, SAML and handle client certs. IMO it needs to support zero knowledge proofs for privacy reasons. It also needs to automate some registration flows, and project social sub-graphs. Users don't care about protocols like OpenID or any of this tech. They want a common, consistent UX that makes sense. Work is going on in of these areas going on at Mozilla, OIDF, ICF, Kantara, W3C, IETF, ISOC, etc. and at Google, Microsoft, Facebook, and at startups., so we are learning. But the mere fact that OpenID (and other protocols) are forking (V.Next, Connect, etc.) proves my point. We haven't learned enough. David and the gang didn't write up OpenID Connect just for fun. Things fork in response to requirements unmet. Our "one protocol (and associated UX) ring to rule them all" approach has failed. Pushing OpenID support into the browser now will continue this failed strategy. --Paul On May 20, 2010, at 9:22 AM, Santosh Rajan wrote: > I would like to see OpenID V.Next include native browser support for OpenID > in V.Next. This has a key advantage that it will vastly improve the security > and privacy implications for OpenID. > > OpenID so far has only considered two parties involved in the dance. The OP > and RP. If we can farm out some parts of the dance to the browser vendors we > can bring the assertion mechanism much closer to the user (currently residing > with the OP). > > I will explain this with a simple flow here. > > 1) In V.Next we allow the RP's to farm out discovery and (Re) direction to > the OP by the browser. Here is one example we can do it. The RP can indicate > to the browser that it will accept native browser support by providing a link > element. > <link rel="openid.v.next.return_to" > href="https://example.com/openid_return_to"/> > 2) The browser detects this and when the user posts a form with a text > element named "openid_identier", the browser intercepts this post and > performs discovery on the users identifier. > 3) Now the browser will follow the exact same discovery process the RP would > have other wise followed and get the JRD/XRD. The browser then formats the > proper request and directs the user to the OP. Remember this is directing as > against redirecting. So we are safe from phishing attacks here. > 4) The OP then redirects the User to the return_to URL, with the required > tokens etc. > 5) The RP gets the assertion verified directly and gets all the required data > (artifact binding data) back. > > I have already tested this with OpenID 2.0 by modifying the firefox browser > using jetpack, and using direct verification of OpenID 2.0. So I can assure > you that the idea works. > > Ofcource there is a lot of work to be done. Especially getting the browser > vendors on board. > > > All we need to do is to get the browser vendors on board and get the work > > > > -- > http://hi.im/santosh > > > <ATT00001..c>
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
