I don't see how that follows.
Refer to Peter Watkin's response, which has caught on the same point.
You seem to think a non-browser-centric version is "broken", but you haven't explained why you think that.
It isn't decentralized (you have admitted this yourself!).
Specifically, I haven't seen a privacy issue which is simply 'solved' by moving responsibility into the browser.
Integrating static JS code into the browser would make each client into the repository of its own XAuth script, instead of relying on a central site to download code from.
No, I'm saying it works as advertised,
You're advertising it as "does not break privacy". There is a disconnect here between how you declare it to be Right Now, and how your blog post explains that it will only be *if and when the browser vendors change their browsers to include support*.
From your reply to Peter's questions:
Sure, we could host extensions at <http://xauth.org>xauth.org. And then people could download them. From, um, a centralized site. How is that more decentralized exactly?
EXACTLY!!! This is how you are doing things RIGHT NOW. THAT is what makes XAuth broken. -ShadePostscript: I'll quote from the blog post - "Objection: The implementation relies on a single domain. Answer: The current implementation does this" (excerpt terminated just after you admit that XAuth's decentralization is broken Right Now and just before you attribute this to limitations that browsers have Right Now).
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
