3 ms·

There is a lot of scope for one-time emails, pseudonymous emails and other kinds of not-my-primary-email authentication systems within Persona. One simple exam

by rfk 14y ago

There is a lot of scope for one-time emails, pseudonymous emails and other kinds of not-my-primary-email authentication systems within Persona. One simple example of how this might work is MockMyID: https://mockmyid.com/ Try logging into a Persona-enabled website with anything@mockmyid.com - you will be able to authenticate without entering any password or giving away any personal information. Of course, so can anyone else, but it might give you an idea of the possibilities in this space.

eps 14y ago
But what is being authenticated exactly in this case? 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.
- rfk 14y ago
  BrowserID provides a way to say to a site "I own this email address", as well as a protocol for the site to verify such an assertion. What the site chooses to do with the information is up to them. It can be used for account creation or signup, but works equally well for authentication to an existing account. In the mockmyid case, you are saying "I own the address xyz@mockmyid.com". But the MockMyID server will happily let anyone make such an assertion, so you get a simple kind of mock identity. Of course, you shouldn't use that as your identity on any sites that you care about. Mail to anything@mockmyid.com doesn't go anywhere, and there's nothing to prevent other people from using the same @mockmyid.com address. But it's a neat example of the sort of thing that is possible.
- callahad 14y ago
  > 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 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.

by rfk 14y ago

eps 14y ago

But what is being authenticated exactly in this case? 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.

rfk 14y ago
BrowserID provides a way to say to a site "I own this email address", as well as a protocol for the site to verify such an assertion. What the site chooses to do with the information is up to them. It can be used for account creation or signup, but works equally well for authentication to an existing account. In the mockmyid case, you are saying "I own the address xyz@mockmyid.com". But the MockMyID server will happily let anyone make such an assertion, so you get a simple kind of mock identity. Of course, you shouldn't use that as your identity on any sites that you care about. Mail to anything@mockmyid.com doesn't go anywhere, and there's nothing to prevent other people from using the same @mockmyid.com address. But it's a neat example of the sort of thing that is possible.
callahad 14y ago
> 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 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.