>
My understanding of Browser ID is that it's a way to provide an email address to a site operator that doesn't need to be confirmed. It's a single-step subscribe/account creation, rather than an authentication per se.That's mostly right. The BrowserID protocol gives you a way to say to a site "Hi, I'm someone@mockmyid.com, and here's the proof." That proof is, in part, a certificate that has been cryptographically signed by the user's email provider.
Now, to verify that, instead of asking the user for a password, or emailing them a confirmation link, you just have to check the cryptographic signature on the certificate. So in this case, you'd go request mockmyid.com's public key at https://mockmyid.com/.well-known/browserid, verify the signature, and if it all checks out, you can let the user into your site!
As for being a "single-step subscribe/account creation", you're spot on. Since there aren't any per-site passwords anymore, there's no difference in the flow for a returning user and a brand new user, since they both say "Hi, I'm name@example.com, and here's the proof." If that user exists in your database, great! log em' in. If not? Yay! You have a new user. Ask them for any additional information you might need.