WEwelder·Apr 11, 2018
Whatever happened to BrowserID from Mozilla? [1]
[1]: https://github.com/mozilla/id-specs/blob/prod/browserid/inde...
In Web Authentication: Proposed API for accessing Public Key Credentialsmozilla
id-specs
Web Development2012–2018
mozilla / id-specs · Archived
id-specs
INACTIVE - http://mzl.la/ghe-archive - Specifications for Mozilla's Identity Effort
7Distinct people
10Mentions
0Explicit recommenders
88GitHub stars
What to know before exploring
What it is
INACTIVE - http://mzl.la/ghe-archive - Specifications for Mozilla's Identity Effort
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year10 dated mentions
Observed mentions: 2012-07-12 07:13:08 UTC to 2018-04-11 03:46:07 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
10 sourcesI think this is a bad idea:
You are using marketing terms like "Persona is distributed. Today" (last weeks blog title) but it isn't, because every auth request flows through mozilla servers. You are also advertising that it is so simple, the entire website example is 70 lines of python (recent talk), but it isn't, because you aren't implementing browserid, you're delegating to the centralised mozilla server.
Advertising that it is distributed and simple does not accurately communicate the current state of the implementation. Look at the spec:
https://github.com/mozilla/id-specs/blob/prod/browserid/inde...
> This assertion is a Backed Identity Assertion, as defined above. We call it assertion here for simplicity, since the Relying Party typically need only pass this assertion to a verifier service without worrying about the specific semant
Read the rest
ics of the assertion string.
It does not say that the centralised mozilla verifier is temporary, but expected.
This all leads to people getting the wrong impression. As you say, it is hard to get people to update software on their servers, but they don't even know that they have to - because it's distributed, today, and simple - so they aren't going to be looking. Another group of people are going to look at the spec and implementations and think: what is the point of yet another login scheme which just pipes everything through mozilla?
This is not going to help the adoption of browserid.
Here's a medium-level technical overview: https://developer.mozilla.org/en-US/docs/Persona/Protocol_Ov...
If that's not geeky enough, you can read the spec for the browserid protocol: https://github.com/mozilla/id-specs
Comparison to OpenID is covered in the FAQ page: https://developer.mozilla.org/en-US/docs/Persona/FAQ#How_doe...
We've got a list of recent talks, too, in case you'd rather flip through slides or watch a video: https://wiki.mozilla.org/Identity/Spread_Persona
In New Persona Beta: Millions of Users Ready to Log In using Any BrowserEr... "they" have also published the full source code involved (at https://github.com/mozilla/browserid ) and a privacy policy at http://www.mozilla.org/en-US/persona/privacy-policy/ that you can compare to said source code as desired, if you're using Mozilla's identity provider.
As far as the architecture of the overall thing, there are also http://identity.mozilla.com/post/7899984443/privacy-and-brow... and http://identity.mozilla.com/post/11145921163/browserid-desig... and a technical specification at https://github.com/mozilla/id-specs/blob/prod/browserid/inde... that describes the exact data flow involved.
And if you read those, it should become pretty clear _why_ this is better for privacy than the FB or Google login systems. For one thing, the identity provider is never told that you're logging in.
In New Persona Beta: Millions of Users Ready to Log In using Any BrowserI've just read through the Persona protocol specification document at https://github.com/mozilla/id-specs/blob/prod/browserid/inde... and was quite disappointed to find RFC5785 in use, in which HTTP is abused as an infrastructure discovery protocol.
This gives a lie to the identity being an "email address". It isn't. Ok, it's structured as a LHS@RHS form but the domain in the RHS isn't an email domain, it's an overloaded website with some problematic assumptions ladled in.
This creates a significant barrier to adoption. Many entities just won't bother: not only does it ask an apex A record to serve actual content (usually a mistake) but it requires the primary web host of a registerable domain, usually a trademark or brand identity, to carry technical material, definitely a clash of concerns.
(Why? In many companies of reasonable size, th
Read the rest
e website is managed by a completely different group of people - often a marketing team - to the internal identity service. Then, even if one team convinces to the other to install the browserid file, there is a possibility of it being deleted it by mistake during the next site refresh.)
I had hoped to find an intermediate step where a DNS SRV lookup was used to first locate the host delivering the browserid file. This follows the federated structure of email rather more closely and allows the identity service to be independent of the corporate brochureware. Even better - if the SRV lookup could be signed with DNSSEC, the transfer itself can be protected with DANE. The whole thing becomes manageable as a simple, separate unit of technology. It is thus rather more likely to gain the support of system administrators.
BrowserID Protocol Spec
https://github.com/mozilla/id-specs/blob/prod/browserid/inde...
In Announcing the First Beta Release of Persona> What the hell does the JS assertion object look like?
Needs to be updated a little bit, but check out the spec:
https://github.com/mozilla/id-specs/blob/prod/browserid/inde...
Note: You don't have to implement this yourself! You can POST assertions to https://verifier.login.persona.org/verify instead, and we'll return a JSON blob that lets you know if it was valid or not. Or you could run that same verifier locally (it's a stateless node.js server, code's on github in the mozilla/browserid repo). The exact data formats are still in flux (waiting / hoping for IETF standardization around some crypto things), so we don't recommend doing verification yourself just yet, unless you run our node.js verifier and frequently update it. We'll get that stuff locked down in one of the next Beta releases.
> How do I run an independent service?
https:
Read the rest
//developer.mozilla.org/en-US/docs/Persona/Implementin...
> In a single page, walk me through the steps to integrate?
https://developer.mozilla.org/en-US/docs/Persona/Quick_Setup
> I like OpenID because it works like email — choose whichever provider you fancy.
Persona works like email because every identifier is an email address, not an opaque OpenID URL. You don't have to have the NASCAR-esque "Sign in with OpenID Provider X, Y, or Z" login page if users can actually use an identifier that that already know. :) (To be fair, OpenID Connect is working on fixing that problem)
> I just hope those advances turn into an open protocol someday.
You're in luck! :) The protocol is open and completely decentralized: https://github.com/mozilla/id-specs/blob/prod/browserid/inde...
Mozilla operates a few centralized services to solve the chicken-and-egg problem while bootstrapping, but they're completely optional, and they automatically fall away when a browser or email provider have native support for the BrowserID protocol.
In Announcing the First Beta Release of PersonaIt's decentralized public-key based authentication, wrapped up in an extremely user- and dev-friendly package. Francois Marier did a good job of explaining it at Kiwi PyCon 2012: https://www.youtube.com/watch?v=iZBTc7iEkQY
(Think OpenID, but easier to use, easier to implement, and with better privacy protection.)
In brief: instead of a username and password at login, you get a user's email address and cryptographically signed assertion proving their ownership of that address. The assertions are ephemeral and scoped to your site, so once you verify it, you can set a session cookie and throw away the assertion. No more password column in your database, yet you still retain a direct relationship with your users.
Here's the underlying spec (working on getting it updated for Beta 1, but the principles are all there) https://github.com/mozilla/
Read the rest
https://github.com/mozilla/id-specs/
Pull requests and new issues welcome :)
In Introducing Mozilla Persona, An Identity System for the Web