I like the idea of maybe switching Persona from callbacks to promises, but other than that I'm not sure this proposal is that much more practical than Persona...
The obvious issue I see is that there's no easy way to polyfill this with existing browser APIs, to my knowledge: Edge doesn't expose the signed in Microsoft Account to my knowledge, for one example and IE typically doesn't have a "globally acknowledged" Microsoft Account... You could bootstrap off the OAuth/OpenID Connect endpoints of the providers, but you end up with the same Persona issues of bootstrapping from email providers. At least it should be fewer providers (one per sniffed browser, presumably) but it's also potentially a larger headache because there are plenty of browsers without accounts, too. What about Opera? Lynx? What about Some New Awesome Browser? Do you use a fallback provider like Persona's login.persona.org? Doesn't that just reintroduce some of the same "workflow pain" we're trying to correct?
Also, Persona works well without being an explicitly W3C-endorsed standard (and would work better if it was, but not required for bootstrapping), where this proposal really would be best if you got it to be a W3C standard ASAP, because you are even more relying on it required as browser chrome (whereas, again, Persona is designed well as a polyfill).
I also don't think you can get away from the statefulness of Persona's navigator.id entirely, because you still presumably want the abilities to allow a user to: resume an existing session, log out, and/or switch accounts/identities.
At the moment, I'm still thinking the best solution is still more and better advocacy for Persona (and more email provider bridges, maybe), but I'm going to sleep on this.
Also, you can't entirely ignore (as an RP [relying party]) which account system your user came from, because a user quite possibly wants to use the same user account from multiple browsers and they'd all might use different account systems so you potentially wind up with the same "link an account" problem of the various OAuth/OpenID Connect worlds without the nicety of a global identifier that you can easily transport between browsers such as Persona's use of any identifying email address.
Maybe your web browser on desktop is Chrome and on mobile is Safari?
The obvious issue I see is that there's no easy way to polyfill this with existing browser APIs, to my knowledge: Edge doesn't expose the signed in Microsoft Account to my knowledge, for one example and IE typically doesn't have a "globally acknowledged" Microsoft Account... You could bootstrap off the OAuth/OpenID Connect endpoints of the providers, but you end up with the same Persona issues of bootstrapping from email providers. At least it should be fewer providers (one per sniffed browser, presumably) but it's also potentially a larger headache because there are plenty of browsers without accounts, too. What about Opera? Lynx? What about Some New Awesome Browser? Do you use a fallback provider like Persona's login.persona.org? Doesn't that just reintroduce some of the same "workflow pain" we're trying to correct?
Also, Persona works well without being an explicitly W3C-endorsed standard (and would work better if it was, but not required for bootstrapping), where this proposal really would be best if you got it to be a W3C standard ASAP, because you are even more relying on it required as browser chrome (whereas, again, Persona is designed well as a polyfill).
I also don't think you can get away from the statefulness of Persona's navigator.id entirely, because you still presumably want the abilities to allow a user to: resume an existing session, log out, and/or switch accounts/identities.
At the moment, I'm still thinking the best solution is still more and better advocacy for Persona (and more email provider bridges, maybe), but I'm going to sleep on this.