With a normal SRP implementation, I'd ask questions like "why aren't you checking B mod N" (you're using Wu's libs so thankfully you're not automatically boned on the server) and "why don't you hardcode N and g so you don't have to check them for safety every time you run the protocol". That's presumably the kind of feedback you're looking for.

But that's all kind a moot point because you're delivering this over Javascript. Making sure g doesn't generate a tiny subgroup, or that N isn't (say) 2 is past the point, because how can a client trust any of this?

You're not delivering the Javascript over HTTPS, but that'd be a fig leaf anyways, because the idea is to embed this in other people's websites. Every one of those those sites would need to load this script on a page that is (a) itself HTTPS, (b) with every page component also delivered over HTTPS, (c) referencing no active content from the site that could have been loaded and cached previously without HTTPS, (d) absolutely free of cross-site scripting flaws. Otherwise, the attacker you are considering when using SRP can trivially snarf users passwords.

Javascript cryptography sucks. SJCL is a very nice library, and it might even be useful in a setting like Node.js, but it does nothing to make content-controlled code a safe place to do crypto.

This system is, right now, strictly worse than an HTTPS login prompt that simply sends a username and password. I don't understand your idea well enough to say whether it can be better than asymptotically as good as that same HTTPS login system.

I get it, by the way. The idea is just "make it easier for sites that are scared by Coda Hale's blog post to implement better - than - Gawker authentication". But even stipulating that all of this scheme can be made to work securely (I don't think it can): this is an awful lot of moving parts for an awfully small value proposition.