So there's now a protocol for the browser to transparently share payment data with websites but we still can't get something to let the browser transparently log us in to websites?
Example scenario: user signs up for a site on Chrome desktop. When they visit the site from their phone, they're automatically signed in, they don't even see a login screen.
Gotta start somewhere. Proposals that come with a working prototype probably fare much better than those that are purely theoretical.
Persona was a good nobel idea, but like many Mozilla endeavors without a commercial goal it was doomed to failure, a few devs and devops costs money (a lot in the US, let's say 3 devs - 2 devops, office space, benefits etc.. easily 1m). Slightly OT beyond Firefox has Mozilla done anything commercially successful? Mobile software failure (cant imagine Android FF pays for itsself), device failure, SSO failure. How much revenue % is accounted for beyond the Google search integration?
Update: Just thought they made Rust and Servo that's pretty cool and my post sounds a little shitty, Rust seems awesome, but commercial avenue (back to reality) seems extremely limited here..
Done properly, it hopefully would've been. (There was even some branding around the vague hope that it would eventually be a standard - "BrowserID"). As it stands... the Persona devs never even tried to create an extension for Firefox to show what they were trying to do (there's some early mockups that explain some of it), nor did they attempt to standardise it. The project was mismanaged to failure.
> has Mozilla done anything commercially successful?
Mozilla is primarily a non-profit organisation, "commercially successful" is not the goal. Mozilla Corp, the wholly owned tax-paying subsidiary, is simply a legal tool to make it less difficult to sell things like search integration, not to be a commercial success.
The question is whether much of their work successfully furthers their goals as outlined in their mission statement and manifesto.[0]
In it, he made a very compelling case on exactly why developers within Mozilla considered Persona's design to be fundamentally flawed beyond a point where it was worth expending the effort and resources to promote and pursue further:
Persona had a "intractable point of centralization" designed into the protocol in the form of the fallback relay that defaulted to login.persona.org. Eventually, the browser was supposed to integrate this functionality and act as this relay, and in a perfect world where Persona is standardized and available in every browser, the fallback relay could, in theory, no longer need to exist.
However, the harsh realities of the web platform unfortunately means that day may never come, even if Persona were to become reasonably successful. There will always be a significant portion of users who remain on older browsers that won't necessarily support the newest features, either by ignorance or by necessity, and very few serious web products are going to risk closing themselves off to such a significant potential source of visitors/revenue just to make use of a shiny new browser feature. This is why most web developers' adoption of ES2015+ are limited to those features where transpilers and polyfills are available (see the abyssmal adoption rate of ES6 Proxies, despite longstanding support in latest versions of major browsers, as an example: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...).
This means that Persona would need to have the login.persona.org fallback available and supported indefinitely in order to have any chance of widespread adoption by developers, which brings us back to the point on intractable centralization: Nobody asides from Mozilla can meaningfully host a fallback relay for Persona without having to also fork the Persona community, because Persona was not designed to allow for any possibility of fallback-relay negotiation between the client (the app the user is trying to authenticate with) and server (the server providing the Persona identity) directly, mainly out of the very noble intention to prevent any loss of user privacy that might result from allowing the client to exchange user info with the server directly (the browser or fallback relay was meant to serve also as an additional layer of security and a gatekeeper to confidential user info).
Ultimately, Mozilla had no choice but to become a single point of failure on a critical piece of authentication infrastructure for the internet if Persona were ever to gain widespread adoption, and this certainly didn't fit with Mozilla's vision for an open and decentralized internet. The team eventually realized this, and ended up winding down development and support for the Persona platform at least in a large part because of it, in hopes that other projects would learn from its mistakes and flourish. Unfortunately that hasn't happened yet, and I think it has a bit to do with the fact that the team's learnings got drowned out in a perfect storm of negative publicity in response to their dropping support for Persona. Apparently the concept itself was quite well loved among developers, despite issues in this particular actual implementation, which is really the silver lining here, and is what makes me really optimistic about the future of authentication on the web.
Dan lamented in the video that "if we hadn't been within Mozilla, we wouldn't have been so audacious as to have predicated the design, predicated the decentralization of the system, on the browser natively implementing our protocol... I honestly think this is something that could have been solved in a different way if we weren't a browser vendor. We were blinded by our context."
It's a really poignant point, in my opinion, and I completely agree that the right way to approach a problem like this is to first develop a solution that can stand on its own merits with or without browser support, then proving itself to be decentralized and open enough to support a rich ecosystem of competing service providers and implementations, and compelling enough to gain widespread adoption. While browser support could and should be obviously beneficial in terms of providing a more streamlined UX, predicating on it opens up the possibility for very severe failures of the imagination, as the Persona team has learned. And if a solution exhibits all the properties I just mentioned, then it becomes a very natural candidate to base a browser standard proposal on, because these are the very same properties that are often deemed most desirable in real web standards to begin with.
I personally can't wait to see what comes out of the current project Dan's working on, Portier, which is positioned to be a spiritual successor to Persona: https://portier.github.io/
Being able to click "log in" and have logged in, and having functional single logout, with a decent UX over the whole thing, is the holy grail. Facebook has the current solution, and browsers don't. Portier does not even attempt to solve the same problem as Persona did, and by being a "self-hosted" application, it can't.
And the use case you mentioned, for an arbitrary web page to ask the _user_ (because there's no reason why the browser absolutely needs to be an intermediary here. More on this in a bit) who it should be talking to in a decentralized manner, has been a solved problem for quite a while in the form of the WebFinger standard, whereby the user simply needs to provide an email address from a provider that implements the protocol on its domain (though it's not often used as a standalone protocol, it is actually quite well adopted as the discovery mechanism behind OpenID Connect, and I have used it in practice through the remoteStorage project: https://remotestorage.io/).
Portier certainly doesn't claim to be trying to copy Persona's approach to authentication on the web exactly, and specifically it makes a conscious effort to avoid predicating the system's usefulness and any of its fundamental design considerations on native browser support (that's of course not to say that they would refuse to integrate with browsers if the opportunity does eventually present itself), a decision that stems from the lessons learned from the failures of Persona: https://github.com/portier/portier.github.io/blob/master/Non...
At the end of the day, Portier strives to succeed Persona as an authentication mechanism, not as a browser-integrated authentication mechanism. And Facebook's current "holy grail" UX around authentication is living proof that you don't need explicit browser support to provide a great auth experience for the end-user. Whether Portier can be successful in replicating an experience like Facebook's while providing a useful degree of decentralization and user privacy as its mission statement declares remains to be seen, of course.
One of the best-case scenarios for Portier is if WebFinger/OIDC were to become widespread and Portier itself somehow obsolete.
I am affiliated with the project but have been putting in much less time than I'd like, admittedly.
Except that you do - otherwise the user needs to tell every website their email address manually, and every website needs to run its own instance of Portier or else you wind up with horribly confusing messaging in the authentication flow - "I'm trying to log into example.com, why is Google asking me to allow access to contoso.com?". Both of these are dealbreakers for something that is supposed to solve the problem of identity on the web.
The bit of Persona that was at all interesting was that it was to be integrated into the browser, Persona would remember identities, and it was a very simple API that didn't involve running a heavy server to handle. You could authenticate against Persona with a handful of lines of javascript and a handful more of PHP, and if the user was already logged in to their identity provider, it was one click to authenticate to a new website.
Portier provides absolutely nothing interesting over an OpenID Connect client + fallback auth mechanism - it's a simple broker.
Form autofill for email is available in just about every major browser, which makes this process as almost as seamless as clicking a Facebook sign-in button, when the user would like it to be, but still offers users the option to provide any arbitrary identity from any OpenID Connect provider for each site if they choose.
> every website needs to run its own instance of Portier or else you wind up with horribly confusing messaging in the authentication flow - "I'm trying to log into example.com, why is Google asking me to allow access to contoso.com?"
I'm not sure how this scenario can ever come about, since Portier is just a dynamic broker for OpenID Connect. Portier itself is only responsible for the "I'm trying to log into example.com" part of the flow, by associating the user's email to a OpenID Connect capable server responsible for performing authentication for that domain. The hypothetical "why is Google asking me to allow access to contoso.com?" part of the flow can only occur if there was a bug in the target server's OpenID Connect implementation that somehow replaced "example.com" with "contoso.com", which has nothing to do with whether or not that server is running Portier itself.
I feel like there may be some misunderstanding on what role Portier performs in the auth flow. But if not, we'll probably just have to agree to disagree on the assertions that the only interesting part of Persona was that it was integrated into the browser, and that Portier offers nothing interesting over static OpenID Connect providers + fallback. Dynamic discovery of authentication providers based on an email was by far the most interesting part of Persona for me, because it meant users can use any arbitrary identity provider they chose, without the developer having to explicitly implement support for every single one of them, as long as the identity providers spoke a common protocol (Persona Identity Provider for Persona, or OpenID Connect for Portier). And this is exactly the part of Persona that Portier is attempting to replicate, except with an already well-adopted protocol that works well without any explicit browser support.
No, because in this case, Portier is running on contoso.com and the website I'm actually trying to auth to is example.com - from the target server's perspective, contoso.com is the site trying to auth against it.
> Dynamic discovery of authentication providers based on an email was by far the most interesting part of Persona for me
OpenID Connect does this as well.[0] If IDPs don't support it, why would they support Portier?
[0] http://openid.net/specs/openid-connect-discovery-1_0.html
The description on Wikipedia for Cerberus/Kerberos is pretty apt when applied to the protocol too:
> Cerberus was the offspring of the monsters Echidna and Typhon, and usually is described as having three heads, a serpent for a tail, and snakes protruding from parts of his body.
They just seem to continuously standardize things that are very user hostile and only serve content distributors.
Example Nr 1 you are going to quote is the DRM stuff (understandably, it's the most controversial for good reasons, both inside and outside W3C). What other very user hostile examples are there?
For example, no amount of contribution would have stopped Netflix et al from pushing through EME as a web standard.
Or, perhaps more likely, browser vendors would continue to not kill Flash until 2020 (at the earliest) when Adobe ends support, and then browsers would drop support for the insecure plugin and then Netflix would go the native apps route.
If everyone is a "peer" and an enormous number of those peers make a succinct, persuasive argument that EME is incompatible with W3C's mission statement of "Web for All" and "Web for Rich Interaction"[1], one would think that would make a difference in the direction the W3C takes.
Instead I'm eating popcorn watching players with deep pockets choose tactics in their battle to control an industry. And that battle is what shapes this web API.
So the claim of, "your peers are listening and they value your feedback," is about as convincing as a hold message from Comcast.
Not really. Anyone can join the W3C, and anyone can participate in a working group / contribute to a standard.
However, most people would agree that the balance of power effectively lies with the browser vendors. You can propose a standard all you like, but if you can't get a browser to adopt it then it's not going to get any traction. And although it's true that some browser vendors make their money off the web (Google) others very much don't (Apple).
It lies with two groups: the implementers (as nothing can become a standard without implementations, though there's plenty of precedent for using obscure ones!) and the W3C Members (i.e., the paying organisations who pay to get a seat; not those who contribute on mailing lists/GitHub/whatever, not those who are officially on the working groups as "invited experts") who ultimately vote on the proposed standard (and there Google has as much say as the BBC and Boeing and the University of Edinburgh.
Starting at ~10 000 USD per year, sure