My request is to support a more classic login flow where an app can simply redirect to BrowserID.org/login?callback=http://myapp.com/foo and browserid will redirect back to the application on the specified callback, passing it the assertion. The app can then verify the assertion as usual and proceed.
This has the advantage that BrowserID will work with minimal effort on more limited browsers like for example Android and iOS applications that simply open a WebView or browser on devices that simply do not have the UI to support popup windows. Or third party iOS browsers that generally do not support popup windows.
This will also greatly improve things for native applications that run just BrowserID in a webview. They can then pass a callback with a custom protocol that can be captured by the native app more easily. This is a common technique on both Android and iOS.
@st3fan importantly, this has the big disadvantage that it ties down everything to browserid.org, which is a centralized architecture we want to move away from.
I think we should explore better SDKs for mobile without forcing a centralization of the protocol.
I understand. Maybe browserid.org can just be the springboard and do the discovery and redirect to another service if needed?
st3fan: can sites even detect that they are in a UIWebView, as opposed to Mobile Safari? Would you have to detect that the popup open failed?
benadida: only, surely, for limited capability browsers? Which are always going to need the browserid.org JS shim anyway, so rely on browserid.org.
@gerv Yeah we can probably detect that.
@gerv @st3fan so one idea I've had is that I think we can detect when window.open fails and have our JS shim do a redirect flow based on the same API in that case. We need to prototype this, but what do you think?
(note that this would also help things work in Chrome for iOS, which has a funky window.open due to iOS restrictions.)
Closing as same fix as #2034
I don't think #2034 has quite addressed the same problem. I love the idea of browserid but am absolutely unwilling to make an otherwise static-ish website require client scripting just to log in.
Would it be possible to allow a site to implement its own discovery-redirect-springboarding, doing the usual JS work on the server side without needing to rely on browserid.org?
@eevee - could you explain your idea and the reasons why you'd like to do the scripting server side in more detail?
One thing we'd love to do is integrate Persona better into our user profile set up. It'd be great if we could reques a user email address & password along with other profile info and request validation/sign-up to Persona server side. We could serve the results, let them know of any errors and inform the user that an email will be sent for verification. If the Persona sign-up/login process can be integrated into to a site rather than through js modals I think it will help us align ux/branding better and reduce the amount of steps to get our users to sign up. Currently our users must have a persona account to use the Open Badges backpack. They're struggling with understanding what Persona has to do with our site and their badges. We provide instructional content but they're getting stuck.
All that said, I have a feeling I could do more reading on the Persona specs and maybe there's a better way to integrate it that I haven't figured out yet.
@kayaelle the problem is that not everyone will be using a Persona account. Some will be using the Google account, or Yahoo, or Mozilla, or others. We don't define how they authenticate their user (which may include 2 factor auth), so we can't provide an API like that.
Some things that we've done to try to make Persona fit in the site better:
1. try using "Sign in with your Email" instead of "Persona".
2. We reduce the amount of our branding in the dialog
3. You can pass a siteLogo and backgroundColor to navigator.id.request() to make the dialog more branded to your site.
@seanmonstar - hmmm...that's good to consider. Since right now we're primarily working with the open badges backpack we don't have control over the dialog display directly. We may do as you suggest and set profiles from our site first and then send them to the backpack. Thanks for the response!
@shane-tomlinson I've thought on this some more and I admit a website could only store credentials used for itself, and would still need a password for securing them, so a local shim would look exactly like traditional login. But here's my half-baked train of thought.
The end goal is for browsers to have built-in support for Persona, right? At which point none of the persona.org JS even needs to be loaded, and the only JS left is a handful of calls to navigator.id methods, most of which will just do an ajax request anyway. It'd be unfortunate to rely on JS ultimately just to navigate to a URL, when this could work just as well for the common case:
<link rel="login" href="/auth/verify">
<link rel="logout" href="/auth/logout">
When the browser sees a login tag it could offer login chrome and POST the assertion, remembering the logout URL for later. Single-page apps and sites wanting fancier behavior could still hook into navigator.id.
I see several immediate advantages:
The most obvious drawback is that opt-in fallback mechanisms are easily overlooked. But offered as a simple default, it would give anyone password-less login without writing a line of JS, and might be easier to reason about for sites with existing traditional auth who already have a logout endpoint, flash messages, etc.
Back in the present: the persona.org shim could detect such <link> tags and do the navigator.id dance itself, though that leaves the problem of what replaces browser chrome. Which brings this full circle; a site could implement full login with only:
<a rel="login" href="https://example.com/auth/verify"><img alt="Sign in!" src="signin.png"></a>
No idea how feasible this is, especially this late in the game, but I'd feel much more comfortable using Persona if it defaulted to a declarative approach like this.
ping :) this might perhaps belong in a new ticket, but the context here seems valuable.
@eevee sorry about the lack of response. I haven't ignored this. I've been thinking if it would make things better, or introduce other problems.
I'm actually running into the problem right now of needing login for a fairly mundane website. I really like the ideas behind Persona, but I can't justify making a bunch of static text and old-school HTML forms inaccessible without JS support.
@eevee fair enough. I'll continue to think about this. Can't promise what I'll think of though :)
Added this to our feature request backlog as mozilla/persona-roadmap#70
@eevee @charmander i've done some initial work on this, and linked the Pull Request to this issue. join the discussion (if you want) over here: https://groups.google.com/d/topic/mozilla.dev.identity/12PW2Z-YPps/discussion