That's right, you're not a 'provider', you're a 'relying party' - but you are unconditionally relying on the bootstrap mozilla service. You're not supposed to swap that out and rely on some other service, you're supposed to look at the assertion provided by the browser (or the javascript shim right now, while we bootstrap). Who you verify the assertion with depends on the user's email address.

So, if tomorrow Google added support for browserid to Gmail, and jo@gmail.com tries to log in to your website, he would claim to be jo@gmail.com and pass you an assertion to that effect. You need to check that with Gmail. Of course, Gmail being popular you've probably already checked the assertion of many people claiming to have Gmail logins, so you already have the Gmail key cached, and can verify the assertion without any http requests to anywhere.

Right now, Gmail does NOT implement browserid, so the assertion which you receive will be that jo@gmail.com is vouched for by the mozilla browserid service, so you will end up checking the URL you've hard coded.

But if it's hard coded we can't proceed to the next stage, which is the distributed promise of browserid. AND, it puts lets less pressure on the likes of Gmail to implement browserid because no one will be checking gmail.com/.well-known/browserid.