<div dir="ltr"><div>On Wed, Feb 19, 2014 at 5:28 PM, Brian Warner <span dir="ltr"><<a href="mailto:warner@mozilla.com" target="_blank">warner@mozilla.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* This is basically a mozilla-internal service framework: one can argue<br>
that plumbing is not the place for science<br>
* As an internal system, it has less influence on the outside world.<br>
It's probably ok if we're not using something inspiring and cool.<br></blockquote><div><br></div></div><div> Is
it just an internal service? Is it not how non-Mozilla RPs would ask
for attached services also? When I download "Cut the Rope" on my FxOS
device, and it offers to sign me up for its leaderboards by asking for
some profile data, won't I be approving access to that data via
fxa-oauth-server?<br>
<br></div>Reading up on the horror stories of Facebook and Github's
holes in their OAuth2, I'm a wee bit apprehensive. But I'll write
anything I have to.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 19, 2014 at 5:28 PM, Brian Warner <span dir="ltr"><<a href="mailto:warner@mozilla.com" target="_blank">warner@mozilla.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 2/13/14 7:14 PM, Ryan Kelly wrote:<br>
<br>
> The naively-obvious (and therefore likely to be wrong) alternative is<br>
> to make FxA a proper BrowserID IdP and let RPs use the <a href="http://persona.org" target="_blank">persona.org</a><br>
> login flow, maybe with special "forceIssuer" flag or whatever.<br>
><br>
> It'd be interesting to enumerate the benefits of the OAuth2 approach<br>
> over the already-kinda-exists-if-you-squint BrowserID approach.<br>
<br>
</div>Ah, now *that* is a good challenge :-). Here's what Chris and I were<br>
able to come up with: I'll admit that some of these are weak or circular<br>
arguments.<br>
<br>
Missing features:<br>
<br>
* delegation: FxA RPs (e.g. Marketplace) need more than just proof that<br>
the calling browser has control over the account. They<br>
also want access/control over some of the user's data on<br>
other servers (e.g. read name+avatar on a Profile server,<br>
get device-location on a Where's-My-Fox server). Persona<br>
doesn't have this sort of authority-delegation built-in,<br>
so we'd have to invent it. OAuth2 was more-or-less built<br>
for this.<br>
* revocation: Marketplace cares more about timely session revocation<br>
(e.g. when you change your FxA password, or deal with a<br>
stolen phone) than your average RP. Persona uses fairly<br>
lazy expiration (~12 hours), which is too slow. We'd need<br>
to build something better (pubsub?) in either case. It's<br>
slightly easier to reason about subscribing to learn about<br>
early expiration of a base64 token than a BrowserID cert<br>
(we'd need to introduce serial numbers, like CAs do).<br>
<br>
Performance concerns:<br>
<br>
* BrowserIDs assertions are about 2kB, due to the RSA/DSA crypto values,<br>
and some folks think that's a lot of data to fling around. OAauth2<br>
tokens are minimal (128 or 256 bits).<br>
* the Persona login process involves multiple iframes, hidden iframes,<br>
API calls, and crypto work, even in the fully-signed-in case, which<br>
makes it relatively slow. OAuth2 has two browser redirects and no<br>
client-side crypto.<br>
<br>
Privacy features we can't benefit from:<br>
<br>
* Mozilla runs both the IdP and the RPs, which makes the privacy win<br>
(provided by Persona's decoupled pubkey-based verification) kinda<br>
pointless<br>
* both approaches basically avoid per-(RP*user) account secrets, which<br>
is Persona's other main win<br>
<br>
Engineering:<br>
<br>
* This is basically a mozilla-internal service framework: one can argue<br>
that plumbing is not the place for science<br>
* As an internal system, it has less influence on the outside world.<br>
It's probably ok if we're not using something inspiring and cool.<br>
* We don't necessarily know OAuth2 that well, but there are a lot of<br>
people out there (including Github and Google) using it successfully<br>
for similar purposes, so we have people to learn from.<br>
* Sadly, Persona is kind of underfunded right now, making it harder to<br>
justify using it. Clearly that's a chicken-and-egg situation. I'd like<br>
to see some long-term vision to address this: could/should we improve<br>
Persona to the point where it's a good solution for this non-standard<br>
use case? Cert-chain -based delegation? More audience-specific bearer<br>
tokens? But we need to learn more about this space before we're likely<br>
to get it right. So we build something that works, identify what<br>
Persona needs, then improve Persona with that knowledge in hand.<br>
<br>
cheers,<br>
-Brian<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Dev-fxacct mailing list<br>
<a href="mailto:Dev-fxacct@mozilla.org">Dev-fxacct@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/dev-fxacct" target="_blank">https://mail.mozilla.org/listinfo/dev-fxacct</a><br>
</div></div></blockquote></div><br></div>