login.persona.org should be a true IdP

[benadida]

with authentication and provision endpoints, so a native implementation can fallback to it normally.

[lloyd]

interesting... Is this fully designed? For the web case, would we use the authentication and provisioning endpoints? Or would these endpoints be only a convenience for native implementations?

I think working through the implementation for 30 minutes will shake out most of the issues. I am glad to do this, and all I need is full, yet terse, context on all of your ideas about how this will work and why.

The greatest issue I see right now is in explicitly defining the overlapping roles of the current persona servers and the native implementation. Understanding precisely how much of the implementation will actually get moved to the native implementation is critical in understanding what exactly the authentication endpoint will display to a user and whether this is a new orthogonal feature for native implementations, or a small restructure of our existing resources.

[benadida]

@lloyd this is the thing we spent a few hours discussing a while back, and I believe you were included. This has to do with appending the GET parameter to the .well-known, the same solution we're using for BigTent.

So yes, I believe this is fully designed, and written up in the spec, and I'm pretty sure you were part of that discussion, but of course we can discuss again if there are any doubts!

For the shimmed case, I don't think we would need to use the auth and provisioning endpoints explicitly, since we're trying to have a dynamic single-page web app. But it's not just a convenience for native implementations, it is required. Otherwise, native implementations can't use the fallback IdP.

[lloyd]

Woah there, Ben: I'm not pushing back here.

I remember this idea, I understand the importance, I just don't remember the feasibility assessment and understanding precisely how we would pull it off.

I just don't feel like this project is sufficiently clear to open an issue about.

I'm curious about things like:

1. if the user already has a persona account and then moves to their phone and enters an email from their existing account, are the asked for their password?
2. if the user enters an email that is not known by persona, do they have to choose a persona password to record the verification? At what point is that password picked? Is it inside the Auth endpoint?

I'm just trying to figure out the nature of the relationship between the phone implementation and our servers. I've presented the persona servers in the past as a combined "Implementation Provider" (shim) - and "Secondary identity authority" - now we're trying to split these two things apart.

I just want to make sure we don't hit an artery.

/cc @ozten @jedp

[benadida]

@lloyd sorry, my tone was off because I was writing too quickly before running out on an errand. I didn't mean to sound defensive.

I do think we have thought it through quite fully, but let's check.

(1) yes, same account, nothing different between native and shimmed, that's the goal.

(2) great question, and yes I think that would be part of the auth endpoint that has to serve as an account creation flow, too.

The one conclusion I remember is that we did NOT want the shim flow to be served the same way as the native flow, precisely because of (2). In particular, I think the shimmed flow should be unaffected by these changes. Two paths, each optimized for its own setting, same trust base.

[seanmonstar]

I would love to resurrect this, and potentially take it. It was sparked by a comment in our PICL/Signin discussion today, and felt this should be solved. Is more discussion needed, like on the list? Or can I just get to getting?

[benadida]

@seanmonstar that would be super cool.

An interesting goal, though it may be hard, would be to separate the Persona implementation from the Persona fallback IdP completely, so that the implementation uses the fallback IdP exactly like it would a normal IdP. What I find particularly interesting about that is that, if you do do that and you don't want a screen refresh, you might find that you need the IdP++ features we've been talking about :)

[ozten]

We need to make this change to enable the current plan for landing Persona in Firefox Desktop.

Background:
Fx will launch a doorhanger with an Identity Picker. For a new email address, Fx does discovery using a new WSAPI on the email address.

Primary email addresses are authenticated through a popup controlled by chrome.
Secondary email addresses are authenticated using a new flow separate from the Persona shim's dialog flow. This also happens in a chrome controlled popup.

The provisioning and authentication frontend code is created on two new urls. The /.well-known/browserid for Persona is augmented with these urls. Many existing wsapi services are re-used in these two new flows.

The shim continues to have a provisioning and authentication flow, to keep performance good and avoid extra redirects and full page loads.

This work should be able to land without breaking anyone in production. It will be used only from special builds of Firefox Desktop, so we could iterate over several trains, before it hits actual users.

Pull request work in progress: #3982

[callahad]

For a new email address, Fx does discovery using a new WSAPI on the email address.

Is there any reason Fx doesn't independently do its own discovery, client-side?

[ozten]

Is there any reason Fx doesn't independently do its own discovery, client-side?

Technically, no.

There are several benefits to starting with a wsapi:

• Changing the discovery protocol saved our bacon twice in the last year, which suggests it might be useful to keep this flexibility
• A web service can cache discovery centrally which will greatly speed up problematic lookups (which we've seen many in production)
• Our existing algorithm is tricky and security sensitive, so we should take our time developing the client based version
• This WSAPI only exposes the domain portion of the email
• Reduce patch size for bug#845546 and faster time to market

Benefits to starting with client side discovery:

• Improved privacy by not sending the hostname portion of the email to a centralized service

[callahad]

Thanks for documenting that... sold :)

[ozten]

Deployed https://desktoppersona.personatest.org from the issue-2497-refactor-to-idp branch.

Will work on ftp downloadable builds of Fx that use it.

[callahad]

Hi! To help us better focus, I'm "closing" all issues that have been open for more than six months. These have been tagged "cleanup-2014" so that we can go back and review them in the future.

For more information, check out this thread: http://thread.gmane.org/gmane.comp.mozilla.identity.devel/7394

If you believe this bug is still a major issue for you, please comment, submit a pull request, or discuss it on our mailing list: https://lists.mozilla.org/listinfo/dev-identity

Sorry for GitHub notification spam!