Native support for browsers in OpenID V.Next

[Santosh Rajan]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100520/69350b44/attachment.html>