BrowserID Identity Provider #348

Closed
tilgovi opened this Issue Mar 28, 2013 · 3 comments

Projects

None yet

4 participants

@tilgovi
Contributor
tilgovi commented Mar 28, 2013

We might consider being a browserid provider for @hypothes.is. The advantage I see is that the front end flow for Persona can be easily adapted. If we implemented an IdP it would be one way to demonstrate getting the authentication flow out of the sidebar which would fix #339 and contribute toward #343.

6a68 commented Jul 23, 2013

@tilgovi So, in the Safari/FF default "from visited" case, an IdP would work without special whitelisting after an initial auth. If third-party cookies are blocked, though, IdP support wouldn't help you.

Persona checks if the user has an IdP session by hitting an IdP endpoint in a hidden iframe, termed the provisioning page. If you haven't visited the site in this browser before, the iframe is considered third-party, so we can't see your session cookie. The dialog would then redirect to display another IdP page, the authentication page. Once the user lands here, your IdP has been visited as a first party, and you're fine--the login will complete, and future clicks on the Persona button will be a much shorter round-trip.

I'm probably going a little fast, happy to explain more. You can read more about this flow on MDN, see the 'provisioning page' section for details.

@tilgovi tilgovi was assigned Jan 4, 2014
@tilgovi tilgovi added 2 - Working and removed in progress labels Apr 22, 2014
@tilgovi tilgovi removed the steak label Jul 28, 2014
Contributor

@tilgovi this is sounding more possible based on yesterday's chat. 😄

Contributor
tilgovi commented Sep 24, 2014

Closing. If we do this it will be a separate repo.

@tilgovi tilgovi closed this Sep 24, 2014
@nickstenning nickstenning removed the 1 - Ready label Sep 24, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment