XAuth critiques

John Panzer jpanzer at google.com
Tue Jun 8 23:49:48 UTC 2010


On Tue, Jun 8, 2010 at 4:33 PM, SitG Admin
<sysadmin at shadowsinthegarden.com>wrote:

>  >I'm having trouble seeing how some additional once-per-year cache
> revalidation requests to xauth.org's IP would change the amount of
> information leakage in any appreciable way.
>
> Single point of failure = NON-centralization.
>

OK, so now we're back to talking about reliability rather than privacy?
 It's very hard to respond when the topic keeps changing.

Reliability: If Akamai's edge cache network and its second and third level
backups all fail, the once-per-year revalidation requests to retrieve XAuth
code will fail too.  In which case, the web page should probably show a
fallback UI (the one it has today, for example) and make the user explicitly
choose their IdP.  Or they could probably hit reload and recover from the
network hiccup too.


>
> I assume the caching cannot be reset, and that your intent is to get
> browser support within the year so it never has to be revalidated; this
> would limit blocking/interception attacks.
>

I'm picking a year as that's common practice for content that never changes.
 It would almost certainly start out much less than that as early adopters
shake out the kinks.


>
> I don't, however, understand why you can't set up a local proxy server,
> temporarily bounce the JS request through it, and set the cache accordingly.
> Post the source code, let everyone review it, then let users download it
> from mirrors (verifying the hash against anywhere it is published), creating
> a truly decentralized setup. (For at least another year, they wouldn't have
> to worry about setting up the cache again.)
>

You can.  The source code is at http://github.com/xauth/xauth and is under
an Apache 2.0 license.  You can set up a local proxy, or map your
xauth.orgto 127.0.0.1 in /etc/hosts and run your own server, or
probably do other
things with extensions.  There is absolutely nothing stopping you from doing
this.  In fact I hope you do, and share the results with the community!


> There *is* a slightly higher barrier to entry, then, but it would do a
> great deal to alleviate the concerns of those of us who see a centralized
> service which *may*, in some idyllic future, become what it was promised to
> be.
>
>
Anyone who wants to pay the higher barrier to entry is free to do so; XAuth
will work perfectly for them once they've jumped over the barrier.

I don't think, though, that it's reasonable for us to demand that everybody
be forced to jump over a pretty major barrier without a compelling reason.
 So far I haven't seen such a reason.

-John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100608/1bc1c753/attachment-0001.html>


More information about the specs mailing list