I don't think the Persona project recognizes what a barrier to entry the lack of a reasonable discovery method really is. There are a host of potential issues:
1. For the [email protected] identifier, it assumes that example.com has an A record. Many, many organizations choose not to have an A record at the top level, while still publishing an MX record to support email addresses.
2. If there is an A record, it assumes that there is a web server listening on port 443. If there isn't, /.well-known/browserid can't be retrieved. What is the fallback mechanism, and how does it affect our users if we adopt Persona in the future? What if this probe is flagged by an IDS, blacklisting the source IP?
3. If there is a web server listening on port 443, it assumes that it will serve resources for example.com. What if it doesn't and gets the /.well-known/browserid from the default host, which is an entirely different domain? What if this probe for an unsupported host is flagged by an IDS, blacklisting the source IP? What if example.com isn't the CN or a SubjectAltName in the SSL certificate? Is the certificate validated? Do I now have to purchase a commercial certificate for a domain that I never intended to be a web site?
4. When a user first enters an identifier, such as [email protected], it assumes this is not only a valid email address, but a valid login. What happens if a user has used an email alias in the fallback that cannot be used to authenticate in our system when we adopt Persona? What if the organization doesn't support Persona, and doesn't want its domain used in the fallback mechanism? Is there an inherent identity theft risk in using a fallback system? Can a rogue web developer create a temporary /.well-known/browserid and backend that will allow them to authenticate as anyone at the organization, then cover their tracks by removing the file?
All of these issues can be neatly solved with DNS discovery. If an organization wants to support Persona, let it publish an SRV record. If one doesn't exist, Persona should tell the user, "Your domain does not support Persona."
For many domains, the A record do not go directly to the actually webserver of the company. Many domain has redirects for SEO reasons, and often get this services directly by their DNS provider (and often do not allow https). Persona prevents this kind of setup. I am also a bit curios if a certificate under one domain can verify a email user of an different domain.
Generally - if one is going to throw around the word "federated" but without properly leveraging the DNS, then the wheel is probably being reinvented; along with a host of layering violations that result in the many misbehaviours discussed here.
The absence of SRV lookup capability in Mozilla is open issue (bug #14328) since 1999.
I do think that the Persona developers are conflating identity with e-mail too much; I can't use it for Mozilla's bug tracker, for example, because I actually value receiving mail and they have no plans to have split identity/e-mail information.
No, not really. Because Mozilla is running the Fallback server in the meantime.
There's no "meantime" here - unless a Very Large Social Network adopts this protocol, I suspect the Fallback server will be the IdP most people use.
SRV is definitely the ideal record. In this case I can see why a pure HTTP approach was chosen (it avoids browser dependancies) and it irks me that developers of web-based tools tend to develop inside the HTTP bubble rather than using the broad and highly capable infrastructure of the Internet, because this kind of constraining outcome is the result.
SRV would be an excellent choice for HTTP/2.0 as well, rescuing us all from apex quasi-CNAME hacks and the like.
However in my initial remark you can substitute in the use of "a well-known subdomain"[1] for "SRV record" and still achieve a better separation of concerns than simply using the RHS of the identity string.
[1] c.f. DKIM's slightly hackish but effective use of an intermediate underscore to denote infrastructure DNS entries. Won't work for A records though IIRC.
Well, that's quite a major downside, don't you think ? Isn't one of the main purpose of persona/BrowserId a better respect of privacy ?
No need for per-site passwords (the only passwords are master password and, possibly, secret for key escrow). No need for any discovery and third parties, as you're identified by your own key, which contains a name (or nickname or whatever) — the most natural approach to identities (which has minor problem with nickname collisions, but that's about it). And, privacy-wise — no need to reveal email address if you don't want it, too.
Edit/Add: WebID looks even more nice http://webid.info/, as it's actively developed by W3C WebID Community Group, while gpgAuth development is stalled and project seems dead.
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, the 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.