Why Aren't fxa-auth-server's BrowserID Assertions Enough?
(still WIP)
The protocols defined in https://github.com/mozilla/fxa-auth-server/wiki/onepw-protocol enables basic login: specifically, a client application (in conjunction with a human who knows the account password) can use HTTPS APIs and some brief cryptographic operations to talk to the fxa-auth-server to obtain a signed BrowserID certificate. This certificate can be used to create BrowserID assertions, and these assertions can be used to convince specific RPs (named in the "Audience" of each assertion) that the bearer (i.e. the client app) rightfully has control over the numbered FxA account named in the certificate.
Delegation
But.. Privacy!
Persona/BrowserID offers several privacy and useability improvements over traditional third-party login systems. First, the use of public-key signatures allows RPs to verify certificates from IdPs without first establishing a shared HMAC secret (i.e. RPs do not have to register with the IdP). Second, the use of two separate public-key signatures allows RPs to verify assertions without revealing (to the IdP) which user is signing in.
However the close relationship between the FxA IdP (fxa-auth-server) and the Mozilla services using these logins (RPs) negates these benefits.
(the
Since BrowserID assertions
we need more than this
third-party convincing
delegated authority
web flow
assertion-length: Persona uses internal hidden iframes, to improve privacy (a redirect flow would reveal referrer and redirect URIs to the IdP). Iframes require postMessage. postMessage enables long messages, enabling assertions. But Iframes are difficult for compatibility (JSChannel has all sorts of weird fallbacks for older browsers), whereas redirects are easy. IdP/RP privacy is moot, removing that constraint, making redirects easier to implement compatibly, which imposes length restriction on the message, which prohibits passing assertions through a redirect, requiring "code". (that would still allow using "code" to fetch an assertion)
Missing Features of OAuth2
The need to pre-register RPs makes it unsuitable for a general-purpose login system for the Web. Registration must necessarily be scarce (otherwise the abuse-punishing properties of client_id are lost: abusers will just register a new RP for each user), which means RPs must negotiate with IdPs to be included, which will limit the number of (IdP,RP) pairs that will work, hurting adoption. In the worst case, RPs may exhibit rent-seeking behavior, demanding payment for the "privilege" of allowing their accounts to be used for login on that RP.
In the other direction, the need to hard-wire the login page to which the browser is initially redirected (1.2) limits the number of IdPs that any given RP may be willing to support, leading to the "NASCAR Effect" and making it difficult for new IdPs to compete against larger established players. There are proposals (WebFinger/etc) to implement a discovery step that resemble's Persona's discovery step, but none have much traction.
The need to submit client_id during the login process immediately tells the IdP which RP each user is accessing, in opposition to one of Persona's explicit privacy goals. Even if client_id were removed, the same information leak would occur when the RP verifies their code through an online protocol with the OAuth server. In Persona, this was addressed with two-signature certificates and offline verification.