If you had followed my signature link, you would have seen that I had more or less blogged about this idea one year back, june 23 2009 to be precise.
On Thu, May 20, 2010 at 10:43 PM, Chris Messina <[email protected]>wrote: > I would suggest providing these ideas to the Firefox team working on the > account manager: > > http://www.mozilla.com/en-US/firefox/accountmanager/ > https://wiki.mozilla.org/Labs/Weave/Identity/Account_Manager > > The best way to move this work/concept forward is to develop working > prototypes that provide some direction here. Microsoft has been pushing > InfoCards for several years which aims to do something very similar and > would also be worth investigating for completeness. > > You might also be interested in the conceptual mockups that I did with > Mozilla last fall: > > http://factoryjoe.com/social-agent > > Chris > > On Thu, May 20, 2010 at 6:22 AM, Santosh Rajan <[email protected]>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 >> >> >> >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs >> >> > > > -- > Chris Messina > Open Web Advocate, Google > > Personal: http://factoryjoe.com > Follow me on Buzz: http://buzz.google.com/chrismessina > ...or Twitter: http://twitter.com/chrismessina > > This email is: [ ] shareable [X] ask first [ ] private > -- http://hi.im/santosh
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
