On Wed, Jun 9, 2010 at 7:46 AM, Peter Watkins <[email protected]> wrote:
> > Before diving back in, I want to make one point. One reason I've been > arguing > so strongly for not starting with a centrally hosted JS file was expressed > pretty well by Phillip Hallam-Baker earlier in this thread: > > "my experience of HTTP is that it is almost impossible to change a scheme > once deployed." > > John, you've written that "It is trivial to replace the XAuth JS core with > calls to a browser solution." but I don't see that. We're going to have > lots of RPs and IdPs with Web apps coded to reference the xauth.org > site. It will become entrenched in the websites, just as the old urchin.js > code became entrenched for Google Analytics users (2.5 years so far and > still folks use urchin.js even though ga.js is better and there is no > visible UX impact when switching). 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: <script type="text/javascript" src="http://xauth.org/xauth.js";></script> to something like <script> if (!document.XAuth) { document.write('<script src="', 'https://xauth.org/xauth.js', '" type="text/JavaScript"><\/script>'); } </script> ...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 https://xauth.org is the implementation of last resort. (I'll take this discussion to the xauth list.) 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. > How do you replace xauth.org JS in the > browser? Are you seriously suggesting that browsers learn to recognize > calls to xauth.org and treat them differently from other iframes? Every > browser vendor has to add if/else code in their core rendering engines > to make the switch to in-browser XAuth? I don't see that happening, and > I say that having watched more straightforward change requests languish. > > On Tue, Jun 08, 2010 at 10:38:49AM -0700, John Panzer wrote: > > On Tue, Jun 8, 2010 at 7:07 AM, Peter Watkins <[email protected]> wrote: > > > > > On Mon, Jun 07, 2010 at 09:46:35PM -0700, John Panzer wrote: > > > > > What makes you think their IdP wouldn't be doing this based on the > user's > > > > preferences? > > > > > > Because that would just move the NASCAR problem from the RP site to the > IdP > > > site. Your current draft says the IdP can specify a list of RP domains > when > > > it deposits a token. In order to give the end user control over what > sites > > > this should be used at, the IdP would need a UI for determining what to > go > > > in this "extend" list. And it would have to so so when adding each > token! > > > This would certainly be a poor UI. I can imagine better ones, but more > to > > the point, the marketplace can decide what the best UI is in this case. > > Better ones like what? I'm serious. The current XAuth spec has an > IdP/Extender > deciding upfront which RP should be allowed to see the end user has a > relationship to the IdP. I cannot imagine how you'd build a UI to fix that > problem. If you can imagine a UI improvement, please describe it! > 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. > > > > This is a great example of why this should be in-browser. With an > > > in-browser > > > solution, a user could be prompted each time an RP asks for XAuth > tokens, > > > and could decide at that time which IdP tokens to reveal, and whether > to > > > always reveal the same set to that RP, etc. > > > I think this would be a poor UI too -- it's well known that most users > will > > simply end up clicking "OK" in this situation, and the experience is > worse. > > But without getting into that argument: You could implement essentially > > the same UX using JS -- the RP doesn't get the data sent back via > > postMessage() unless the xauth.org JS says it can. You could probably > have > > a better UX with an in-browser solution, but not a qualitatively > different > > one. In other words, this is not a strong differentiator for in-browser > vs. > > JS solutions. > > Sure it is. In-browser, I get to decide which XAuth client-side handler to > use; > 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. > I can decide to use one that prompts me fairly often, or I could opt for a > "less private" handler that stays out of my way. With the current hosted > solution, how would I choose to use a different UX? Use a GreaseMonkey > script > to completely replace the JS you host at xauth.org with something entirely > different? While technically feasible, that sounds like a terrible > proposition, > suggesting to users that they install a hack to replace the core piece of > a central identity system. With a centrally hosted solution, users are > pretty > well stuck with whatever UI(s) the central provider wants to offer. > 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. > > > I agree that an in-browser solution could provide a better UX; in fact > > that's my argument (make it work, then make it better) ;). > > And, as a few of us have reminded you, your company has the 4th most > popular > desktop browser on the market. If you really want this to be in-browser, > you > have a great way to start doing that. As Eran said, you're in a much better > position now than Dick, David, et. al. were when starting OpenID. > > Chromium is open source and accepting patches ( http://www.chromium.org/developers/contributing-code). 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. > > > > > > I think that browser support would make some > > > > > > things easier -- perhaps defending against "pretend" IdPs that > use > > > social > > > > > > engineering to get themselves on your IdP list -- but (a) those > > > > Many phishers don't really care about having legitimate-looking URLs. > > > Some would try using this to phish someone's Facebook credentials, > > > I do agree that we need more comprehensive defenses against "bad actors" > on > > the Internet. This is a separate discussion, but the ability to have > > Why? I'm responding to your threat example, and you say you want XAuth > in-browser, and you agree that in-browser would help not only UX but also > defend against your attack. So why does this become a separate discussion? > 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.) > > I don't know how to make sense of your simultaenously saying you want this > in-browser and trying to avoid any discussion of various threat vectors > that > support the idea of moving the code to the client. > 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. > > > If for example xauth.org had a good way to ask for the Internet's > opinion of > > a site, it could ask the user to confirm for the small subset of sites > that > > it thinks are hinky (or which it has no information about), with > appropriate > > warnings. An immune system for the Internet, if you will. > > Sounds like a traditional browser phishing filter. Make XAuth a spec rather > than a centrally-hosted implementation and the market will provide those > kinds > of solutions. > 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 http://xauth.org/spec/ needs to be more clearly separated from the implementation at xauth.org. 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. > > > On the other hand, this is also something that is not a differentiator > > between in-browser and JS-based implementations; either one could consult > > such a service and pop up (infrequent, scary) warnings. > > It is a differentiator for the potential host of xauth.org. Publishing > realtime blacklists is a legal minefield -- look at the history of RBLs > for email, and how those good guys have been sued left and right by the > spammers. Heck, OIDF is worried about paying for bandwith for xauth.org, > what makes you think that they'd want to take on legal risk of trying > to warn users away from shady websites? > 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 :) > > > > > (Note that exactly the same issues arise when downloading extensions. > JS > > > is > > > > just a way of delivering always-latest-version extensions to your > > > browser.) > > > > > > And the solutions are similar -- code-signing and publishing extension > info > > > on https pages, as Firefox does. > > > How does this avoid having to trust a central site (the extension site > and > > the owner of the signing key)? Or do you see the case of retrieving JS > via > > If this is code run in-browser that implements an agreed-upon API, then > users > can choose freely between different implementations. Maybe I'll be able to > choose between your extension, Microsoft's, and one written by Dan > Bernstein. > As long as the system is a centralized JS file, then users' only hope of > customization is stuff like GreaseMonkey hacks. > My comment was addressing trust, not ease of implementation. The objection I was answering was that users need to trust xauth.org 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 www.chromium.org 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 xauth.org, you should likewise not trust anyone to compile your browser for you. Re: Agreed upon API --the interface is XAuth.extend, XAuth.expire, XAuth.retrieve. Modification requests should happen on the xauth mailing list (http://groups.google.com/group/xauth). I think it's pretty close to baked for v1 right now. John
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
