<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 19, 2014, at 2:47 PM, Josh Mize <<a href="mailto:jmize@mozilla.com">jmize@mozilla.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000"><p wrap="">
On Thursday, 13 Feb 2014, 7:14PM, Ryan Kelly wrote:
<br>
</p>
<blockquote><p>The naively-obvious (and therefore likely to be wrong)
alternative is to
make FxA a proper BrowserID IdP and let RPs use the <a href="http://persona.org">persona.org</a>
login
flow, maybe with special "forceIssuer" flag or whatever.
It'd be interesting to enumerate the benefits of the OAuth2
approach
over the already-kinda-exists-if-you-squint BrowserID approach.<br>
</p>
</blockquote><p><br>
I'd greatly appreciate it if someone could explain a little more
about why the naively-obvious approach is so likely to be wrong,
and to enumerate</p></div></blockquote><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000"><p>the benefits of the OAuth2 approach.<br>
</p></div></blockquote><div><br></div><div>The primary benefit is that other well funded motivated organizations with security engineers have already turned the fuzziness of OAuth 2 into defined APIs that seem to work for their use cases, which are similar to our use cases. </div><div><br></div><div>So:</div><div><br></div><div>1) we could fork their Oauth2 APIs and adapt them for our use</div><div>2) we could augment BrowserID assertions and our custom APIs to address these additional use cases and invent a whole bunch of technology to do what Oauth2 already does</div><div><br></div><div>I have confidence that #1 will likely yield a useful and reasonably secure API that we can deliver in a short time frame. </div><div><br></div><div>For #2, we'll probably iterate on the API a while, implement it, discover some bugs when we actually try to use it, fix the API, etc. That's substantial risk for what I consider plumbing. What will we have to show for it? A system only used internally at Mozilla that likely does the same thing as Oauth2 and looks pretty similar, and we'll spend the next 2 years answering questions why we're doing it differently from the way everyone else does it.</div><div><br></div><div>-chris</div><div><br></div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000"><p>Thanks,<br>
Josh Mize<br>
</p>
</div>
_______________________________________________<br>Dev-fxacct mailing list<br><a href="mailto:Dev-fxacct@mozilla.org">Dev-fxacct@mozilla.org</a><br>https://mail.mozilla.org/listinfo/dev-fxacct<br></blockquote></div><br></body></html>