Native support for browsers in OpenID V.Next

Santosh Rajan santrajan at gmail.com
Thu May 20 17:33:18 UTC 2010


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 <chris.messina at gmail.com>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 <santrajan at gmail.com>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
>> specs at lists.openid.net
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100520/578bac45/attachment.html>


More information about the specs mailing list