View source for Identity/Spread Persona/Common Questions

Placeholder: page for common questions that presenters always get asked and a canonical answer to use.

== Open ID ==

* How is Persona different from OpenID?
** Privacy and user experience: https://developer.mozilla.org/en-US/docs/Mozilla/Persona/FAQ#How_does_Persona_compare_to_OpenID.3F
** Security: By having Identity built into the browser UI, we can mitigate phishing attacks. Because it's built in to the browser, there's no way for a script to imitate the native UI.

== UX ==

* What's the rationale behind using email addresses for identity instead of something like a certificate in the browser which contains email as one of the fields?
** Email addresses are simple for users. Users know their email addresses, they also know how to create new ones if they want separate identities.
** Most sites already need (and have) their users' email addresses to engage with them.
* Is there an alternative to the popup?
** We are using a redirect flow on certain platforms that don't support popups.
** We are currently considering making this redirect flow more widely available.

== Privacy ==

* Doesn't the verifier get a log of all websites users log into? Are there libraries that do assertion verification without using the online verifier? What languages are they in?
** While the online verifier gets to see where users are logging into, the use of the verifier is not mandatory. Sites can do their own local verification.
** To make this easier, we are building verification libraries that currently make use of the online verifier but which can later be "upgraded" to do verification locally.
** There are currently libraries for Python, Perl, Node.js and PHP.

* Isn't Big Tent leaking history to Yahoo?
** No, all that Yahoo can see is that you're logging into Persona.org

== Email? ==

* How do you handle websites for which users don't want to give their email address?
** Users who don't want to reveal their real email address can easily create a new webmail account under a different name.
** Alternatively, for mailinator.com-style throw-away email addresses, users can use http://mockmyid.com
* What happens when a user wants to change an email address?
** This is a hard problem generally (not just with Persona), but we have these recommendations: https://developer.mozilla.org/en-US/docs/Mozilla/Persona/The_implementor_s_guide/Enabling_users_to_change_their_email_address

== Security ==

* Is the assertion signed or could the RP tamper with it?
** The assertion is signed using the browser's private key so it cannot be modified by the RP or the IdP.
* If you're asking for email addresses and passwords, aren't most users just going to give your their email password?
** That's possible, but the goal is for users to authenticate directly with their Persona-enabled email providers.
* Why is the fallback IdP asking for a password is the whole point of Persona is to get rid of passwords?
** This is to avoid asking users to click an email link every time they want to log into a site.
** We are currently considering giving users the option to opt out of setting a password (and choose to confirm via email every time instead).
* Can you restrict which identity providers are allowed on your site?
** Yes, the easiest way is to extract the domain from the email address returned by Persona and check it against a whitelist.
** Alternatively if your users have an IdP with native support, you can check the issuer field inside the certificate.
* What prevents an attacker from stealing an assertion on the wire?
** We recommend that sites send assertions to their back-end over HTTPS.
** To further mitigate this, assertions have a short expiry.

== RP ==

* What kinds of personal information can an RP request from the user?
** Only the email address.
* What's the incentive for RPs to implement Persona?
** Better user flow, no need to secure passwords.
* Should the button be sign in or register, or two different buttons (which do the same thing)?
** One option is "Sign in / Register" on the same button (see developers area on Marketplace).
* What will RPs have to change on their site once email providers or browsers add native support for Persona?
** Nothing.
* Do you offer a way for sites to self-host the JS file and then remove the need to load anything from persona.org?
** Currently we don't recommend this. However, we do plan on making include.js self-hostable: https://github.com/mozilla/browserid-roadmap/issues/47

== End User ==

* Why is JavaScript required?
** See the [https://developer.mozilla.org/en-US/docs/Mozilla/Persona/FAQ#Why_does_Persona_require_JavaScript.3F FAQ].
* What's the story with shared computers?
** The first time you use Persona we assume you're on a shared computer. The second time, we ask you.
** On shared computers, the certificate validity and session duration are kept very small.
* It's unfortunate that users have to pick a new password for persona.org. Will that go away?
** Yes, when a user's IdP switch to native Persona support or when an identity bridge for it is released.

== Bridging ==

* Are there plans to create a Facebook identity bridge?
** We have built a prototype for it, but decided not to use it because most users don't know what their Facebook email address is.
* Is there potential for an OpenID 2 bridge?
** We have talked about building OpenID bridges on the list: https://groups.google.com/d/topic/mozilla.dev.identity/Xo5iZavY3HE/discussion
* Do you think that building a bridge to GMail makes Google less likely to implement full native support? Have you talked to Google about it?
** No, the bridge is a first step to show what a native experience feels like. The experience can be even better with native support.
** We'd love to see Google run an IdP and cut us out of the loop: https://ozten.com/psto/2013/08/29/fc4-persona-questions/
* Is there a way for a Google Apps domain to delegate to the GMail bridge?
** No because we don't have an authoritative way of finding out from Google whether or not a domain is hosted on Google Apps.

== IdP ==

* Does the certificate given by your email provider expire?
** Yes, in fact there are two expiries.
** When the browser generates its public and private keys, it sets an expiration on them.
** When the email provider signs the browser's public key, it sets an expiration on the signature.
** If either of these expirations have passed, the certificate is deemed invalid.
* Why do we force the use of HTTPS and not use DNS?
** Because unsigned DNS is insecure and DNSSEC is not widespread enough: https://groups.google.com/forum/#!msg/mozilla.dev.identity/dP44TDzBnhI/3MijAKI1oR8J
* Does Persona rely on TLS certificate authorities, which is a centralized point?
** Yes, just like the rest of the web.
** This means that Persona benefits from the ongoing work to make TLS more secure and transparent.
** Note that it also relies on another centralized point: DNS.
* How does someone become an IdP?
** Like this: https://developer.mozilla.org/en-US/Persona/Implementing_a_Persona_IdP
** The hardest part is signing certificates, which is why we provide a standalone daemon for this: https://npmjs.org/package/browserid-certifier
* Which Persona identity providers support 2-factor auth currently? Will the fallback IdP support 2-factor auth?
** We are only aware of the GMail bridge.
** We hope to add 2-factor support to the fallback IdP: https://github.com/mozilla/browserid/issues/3045
* Isn't Persona's security entirely dependent on the email provider keeping other people away from your emails?
** Yes, but so are other sites. If an attacker can read your emails, he/she can reset your password on most sites and gain access that way.
** An identity provider is by definition an entity that you trust not to let other people impersonate you.
* If someone is doing a DoS on your HTTPS site, can they break/compromise authentication for your domain?
** It depends whether or not Persona.org has already noticed that you site has native support.
** If it has, it will show some kind of "IdP down" message, otherwise it will use the fallback IdP.
* How does IdP key revocation work?
** When an IdP changes to a new key, existing certificates will become invalid since verifiers will fetch the new public key.
** Note that verifiers will most likely cache the certificates for a short period of time.
** We recommend that IdPs set appropriate caching headers on their support documents.
* How can Persona.org claim to verify an ISP's users without the ISP being involved and having the ability to revoke these?
** The fallback IdP sends a confirmation email to a user the first time they use an email address. Only the owner of the email address can read that email and click the link.
* How do you find the IdP's public key when you verify an assertion?
** It is inside the support document: https://developer.mozilla.org/en-US/Persona/.well-known-browserid
* Can this work with 2-factor authentication?
** Yes, the authentication mechanism is entirely up to the identity provider.
** All that an IdP needs to supply is a login page and a way for the browser to get certificates signed.
* What happens to the existing persona.org passwords once a domain adds native support?
** They are no longer used because native IdPs take precendence over the fallback IdP
* What happens when an identity provider goes down?
** Initially, users of that IdP can't login.
** If it's like that for an extended period of time, then Persona will switch back to the fallback.
** Just like with email servers, they are never all up and they are never all down. At any given time, you can find a broken email server, but the system as a whole is highly resilient due to its decentralized nature.

== Native ==

* When will Persona be part of Google Chrome and is Google still committed to BrowserID?
** We are currently building native support for Persona in Firefox. Once that's done, we will start talking to other browser vendors.
** Until then, it is a bit premature since we don't know for sure what problems browser developers will run into.

== Mobile/Apps ==

* How does it work on mobile?
** If you can display a web view, you can use Persona.
** Note that Persona replaces the authentication step, not authorization.
** Most apps will want to authenticate once and then exchange a token that will be used for any further communication between the app and the server.
** This is better than asking users to login every time they open the app, or saving the user's credentials on the phone directly.

== Misc ==

* How does the system move private keys around a user's multiple devices?
** It doesn't move any keys, each device has its own private key.
** You can have more than one valid private key at any one time.
* Do we have any thoughts about what the FIDO Alliance [8] is doing?
** TODO!
* Can you use your own domain and use a different username for each website you log into?
** Yes. If you have your own domain, you can make up a different email for each site and configure your IdP to use the same password for all of them.
* "Is it possible to reset my Persona password using my phone number?"
** No because we don't store your phone number.
* Is Persona accessible?
** Our user testing has shown that it is, but it is obviously an ongoing issue and you should file a bug if you run into any problems.
* How can I contribute to Persona / BrowserID?
** https://wiki.mozilla.org/Identity/#Get_Involved
* What guarantees do I have that you're not going to drop this project and leave me hanging?
** Federation of identity is very important to Mozilla and we are dedicating significant resources to it.
** We use Persona on most Mozilla properties, so we can't just turn it off.