<div class="gmail_quote">On Wed, Jun 9, 2010 at 7:46 AM, Peter Watkins <span dir="ltr"><<a href="mailto:peterw@tux.org">peterw@tux.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Before diving back in, I want to make one point. One reason I've been arguing<br>
so strongly for not starting with a centrally hosted JS file was expressed<br>
pretty well by Phillip Hallam-Baker earlier in this thread:<br>
<div class="im"><br>
"my experience of HTTP is that it is almost impossible to change a scheme<br>
once deployed."<br>
<br>
</div>John, you've written that "It is trivial to replace the XAuth JS core with<br>
calls to a browser solution." but I don't see that. We're going to have<br>
lots of RPs and IdPs with Web apps coded to reference the <a href="http://xauth.org" target="_blank">xauth.org</a><br>
site. It will become entrenched in the websites, just as the old urchin.js<br>
code became entrenched for Google Analytics users (2.5 years so far and<br>
still folks use urchin.js even though ga.js is better and there is no<br>
visible UX impact when switching).</blockquote><div><br></div><div>Somewhat different: -- urchin.js has to be on every single web page, xauth only on one per site, this makes the problem much more tractable. But, I think this needs to be addressed up front by the xauth group; my suggestion is to change the snippet from the current:</div>
<div><br></div><div><script type="text/javascript" src="<a href="http://xauth.org/xauth.js">http://xauth.org/xauth.js</a>"></script></div><div><br></div><div>to something like</div><div><br>
</div><div><font class="Apple-style-span" face="arial, helvetica, sans-serif"><script></font></div><div><font class="Apple-style-span" face="arial, helvetica, sans-serif">if (!document.XAuth) {</font></div><div><font class="Apple-style-span" face="arial, helvetica, sans-serif"> d</font><span class="Apple-style-span" style="line-height: 14px; white-space: pre; "><font class="Apple-style-span" face="arial, helvetica, sans-serif">ocument.write('<script src="', '<a href="https://xauth.org/xauth.js">https://xauth.org/xauth.js</a>', '" type="text/JavaScript"><\/script>');</font></span></div>
<div><span class="Apple-style-span" style="line-height: 14px; white-space: pre; "><font class="Apple-style-span" face="arial, helvetica, sans-serif">}</font></span></div><div><font class="Apple-style-span" face="arial, helvetica, sans-serif"></script></font></div>
<div><font class="Apple-style-span" face="arial, helvetica, sans-serif"><br></font></div><div><font class="Apple-style-span" face="arial, helvetica, sans-serif">...and then the API XAuth.extend() etc. can be implemented by, basically, anybody. The first module to install document.XAuth gets to handle the implementation; if nobody does, then <a href="https://xauth.org">https://xauth.org</a> is the implementation of last resort. (I'll take this discussion to the xauth list.)</font></div>
<div><font class="Apple-style-span" face="arial, helvetica, sans-serif"><br></font></div><div><font class="Apple-style-span" face="arial, helvetica, sans-serif">This of course assumes that the interface is stable enough for a v1. Given that it's pretty limited I have hopes this is the case.</font></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> How do you replace <a href="http://xauth.org" target="_blank">xauth.org</a> JS in the<br>
browser? Are you seriously suggesting that browsers learn to recognize<br>
calls to <a href="http://xauth.org" target="_blank">xauth.org</a> and treat them differently from other iframes? Every<br>
browser vendor has to add if/else code in their core rendering engines<br>
to make the switch to in-browser XAuth? I don't see that happening, and<br>
I say that having watched more straightforward change requests languish.<br>
<div class="im"><br>
On Tue, Jun 08, 2010 at 10:38:49AM -0700, John Panzer wrote:<br>
> On Tue, Jun 8, 2010 at 7:07 AM, Peter Watkins <<a href="mailto:peterw@tux.org">peterw@tux.org</a>> wrote:<br>
><br>
> > On Mon, Jun 07, 2010 at 09:46:35PM -0700, John Panzer wrote:<br>
<br>
</div><div class="im">> > > What makes you think their IdP wouldn't be doing this based on the user's<br>
> > > preferences?<br>
> ><br>
> > Because that would just move the NASCAR problem from the RP site to the IdP<br>
> > site. Your current draft says the IdP can specify a list of RP domains when<br>
> > it deposits a token. In order to give the end user control over what sites<br>
> > this should be used at, the IdP would need a UI for determining what to go<br>
> > in this "extend" list. And it would have to so so when adding each token!<br>
<br>
</div><div class="im">> This would certainly be a poor UI. I can imagine better ones, but more to<br>
> the point, the marketplace can decide what the best UI is in this case.<br>
<br>
</div>Better ones like what? I'm serious. The current XAuth spec has an IdP/Extender<br>
deciding upfront which RP should be allowed to see the end user has a<br>
relationship to the IdP. I cannot imagine how you'd build a UI to fix that<br>
problem. If you can imagine a UI improvement, please describe it!<br></blockquote><div><br></div><div>The IdP tells XAuth what to set when the user visits a web page at the IdP. The web page can implement any UI at that point. The one thing it can't do that could be done in a browser would be to display the full list of IdPs and let a user edit them in a central place -- given that most users will have one IdP though, this seems to me to fall into the "improved UI" rather than "fundamental feature" category. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> > This is a great example of why this should be in-browser. With an<br>
> > in-browser<br>
> > solution, a user could be prompted each time an RP asks for XAuth tokens,<br>
> > and could decide at that time which IdP tokens to reveal, and whether to<br>
> > always reveal the same set to that RP, etc.<br>
<br>
</div><div class="im">> I think this would be a poor UI too -- it's well known that most users will<br>
> simply end up clicking "OK" in this situation, and the experience is worse.<br>
> But without getting into that argument: You could implement essentially<br>
> the same UX using JS -- the RP doesn't get the data sent back via<br>
> postMessage() unless the <a href="http://xauth.org" target="_blank">xauth.org</a> JS says it can. You could probably have<br>
> a better UX with an in-browser solution, but not a qualitatively different<br>
> one. In other words, this is not a strong differentiator for in-browser vs.<br>
> JS solutions.<br>
<br>
</div>Sure it is. In-browser, I get to decide which XAuth client-side handler to use;<br></blockquote><div><br></div><div>How many users are going to _want_ to swap out XAuth client-side handlers, or even understand the issues? Certainly, in the long run, you'd want to be able to do this. Again, this is an "upgrade" rather than a "fundamental feature" from the POV of end users.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I can decide to use one that prompts me fairly often, or I could opt for a<br>
"less private" handler that stays out of my way. With the current hosted<br>
solution, how would I choose to use a different UX? Use a GreaseMonkey script<br>
to completely replace the JS you host at <a href="http://xauth.org" target="_blank">xauth.org</a> with something entirely<br>
different? While technically feasible, that sounds like a terrible proposition,<br>
suggesting to users that they install a hack to replace the core piece of<br>
a central identity system. With a centrally hosted solution, users are pretty<br>
well stuck with whatever UI(s) the central provider wants to offer.<br></blockquote><div><br></div><div>See my document.XAuth suggestion above -- I think it should be perfectly reasonable for early adopters to start installing extensions to replace or augment XAuth. In fact I think it's very important that people start experimenting; but this only works if IdPs and RPs are actually using XAuth in the wild so you can see which UIs work and which don't. Chicken and egg problem, which is solved by bootstrapping via a central JS repository.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> I agree that an in-browser solution could provide a better UX; in fact<br>
> that's my argument (make it work, then make it better) ;).<br>
<br>
</div>And, as a few of us have reminded you, your company has the 4th most popular<br>
desktop browser on the market. If you really want this to be in-browser, you<br>
have a great way to start doing that. As Eran said, you're in a much better<br>
position now than Dick, David, et. al. were when starting OpenID.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Chromium is open source and accepting patches (<a href="http://www.chromium.org/developers/contributing-code">http://www.chromium.org/developers/contributing-code</a>). If you believe this is important, it's perfectly possible for you to write an XAuth extension and contribute it. If it's awesome I suspect the Chromium team will gladly accept it and it'll get incorporated into Chrome. I think, per Allen's email, it's very reasonable to do things in parallel here.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> > > > > I think that browser support would make some<br>
> > > > > things easier -- perhaps defending against "pretend" IdPs that use<br>
> > social<br>
> > > > > engineering to get themselves on your IdP list -- but (a) those<br>
<br>
</div><div class="im">> > Many phishers don't really care about having legitimate-looking URLs.<br>
> > Some would try using this to phish someone's Facebook credentials,<br>
<br>
</div><div class="im">> I do agree that we need more comprehensive defenses against "bad actors" on<br>
> the Internet. This is a separate discussion, but the ability to have<br>
<br>
</div>Why? I'm responding to your threat example, and you say you want XAuth<br>
in-browser, and you agree that in-browser would help not only UX but also<br>
defend against your attack. So why does this become a separate discussion?<br></blockquote><div><br></div><div>Because it's a much bigger, more complicated discussion that deserves its own thread and probably should be CC'd to the xauth mailing list. It also, IMHO, requires some degree of centralization (unlike xauth itself) because the whole point is to collect data from across the Internet and analyze it. Or perhaps some peer network could be built that does this without centralization. It's a much bigger topic than just xauth too. (But see below.)</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I don't know how to make sense of your simultaenously saying you want this<br>
in-browser and trying to avoid any discussion of various threat vectors that<br>
support the idea of moving the code to the client.<br></blockquote><div><br></div><div>Moving code in-client doesn't make it any better at knowing reputation of bad sites on the Internet. This particular threat isn't addressed by moving the code into the browser. It _is_ a legitimate threat which is why I said it would be good to discuss; it's just not relevant to the client-vs-server discussion we're having here. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> If for example <a href="http://xauth.org" target="_blank">xauth.org</a> had a good way to ask for the Internet's opinion of<br>
> a site, it could ask the user to confirm for the small subset of sites that<br>
> it thinks are hinky (or which it has no information about), with appropriate<br>
> warnings. An immune system for the Internet, if you will.<br>
<br>
</div>Sounds like a traditional browser phishing filter. Make XAuth a spec rather<br>
than a centrally-hosted implementation and the market will provide those kinds<br>
of solutions.<br></blockquote><div><br></div><div>XAuth should be more cleanly defined as a spec. The messaging (which is largely aimed at end users) conflates the spec and the service; since end users only ever see the service this is appropriate, but XAuth's spec at <a href="http://xauth.org/spec/">http://xauth.org/spec/</a> needs to be more clearly separated from the implementation at <a href="http://xauth.org">xauth.org</a>. Rough consensus and running code: No decent spec ever starts out as a spec, it starts out as an implementation and gets scrubbed into a specification. XAuth is just doing that in the open.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> On the other hand, this is also something that is not a differentiator<br>
> between in-browser and JS-based implementations; either one could consult<br>
> such a service and pop up (infrequent, scary) warnings.<br>
<br>
</div>It is a differentiator for the potential host of <a href="http://xauth.org" target="_blank">xauth.org</a>. Publishing<br>
realtime blacklists is a legal minefield -- look at the history of RBLs<br>
for email, and how those good guys have been sued left and right by the<br>
spammers. Heck, OIDF is worried about paying for bandwith for <a href="http://xauth.org" target="_blank">xauth.org</a>,<br>
what makes you think that they'd want to take on legal risk of trying<br>
to warn users away from shady websites?<br></blockquote><div><br></div><div>That's why it should be a separate service. And more to the point for the purposes of this dicussion, _it isn't a differentator between deciding on an in-browser or server-based implementation of xauth_. Such a service _has to be server based_. Which is another reason for it to be separate from xauth, because we want to be able to move xauth into the browser :)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> > > (Note that exactly the same issues arise when downloading extensions. JS<br>
> > is<br>
> > > just a way of delivering always-latest-version extensions to your<br>
> > browser.)<br>
> ><br>
> > And the solutions are similar -- code-signing and publishing extension info<br>
> > on https pages, as Firefox does.<br>
<br>
> How does this avoid having to trust a central site (the extension site and<br>
> the owner of the signing key)? Or do you see the case of retrieving JS via<br>
<br>
</div>If this is code run in-browser that implements an agreed-upon API, then users<br>
can choose freely between different implementations. Maybe I'll be able to<br>
choose between your extension, Microsoft's, and one written by Dan Bernstein.<br>
As long as the system is a centralized JS file, then users' only hope of<br>
customization is stuff like GreaseMonkey hacks.<br></blockquote><div><br></div><div>My comment was addressing trust, not ease of implementation. The objection I was answering was that users need to trust <a href="http://xauth.org">xauth.org</a> not to be evil, and that an in-browser implementation solves that. My point was that an in-browser implementation requires users to trust that <a href="http://www.chromium.org">www.chromium.org</a> not be evil (not insert data collection viruses), so there's still a central point of trust. Well, okay, there are like 3-4 points of trust for all users across the entire Web, one per browser provider, and this is certainly better than a browser monoculture, but I think the general point stands -- if you don't trust anyone to run <a href="http://xauth.org">xauth.org</a>, you should likewise not trust anyone to compile your browser for you.</div>
<div><br></div><div>Re: Agreed upon API --the interface is XAuth.extend, XAuth.expire, XAuth.retrieve. Modification requests should happen on the xauth mailing list (<a href="http://groups.google.com/group/xauth">http://groups.google.com/group/xauth</a>). I think it's pretty close to baked for v1 right now.</div>
<div> </div><div>John</div></div>