Browser ID

One of the features we’ve added to Persona’s new Observer API is the ability for websites that use Persona (“Relying Parties”) to add their name and logo to the login screen. To do this, just add a siteName and/or siteLogo property to your ... [More] navigator.id.request() call. The default login screen only shows the website’s domain name, as illustrated below: By adding siteName, you can put additional text in the right-hand RP area: navigator.id.request({ siteName: "Tahoe LAFS" }); Or you can use siteLogo to add an image: navigator.id.request({ siteLogo: "/logo.png" }); You can also use both, in which case the name will appear below the logo. In all cases, the website’s domain name is displayed below the siteName and siteLogo, so the user knows for sure which site is going to receive their email address. Restrictions (Use SSL!) There are a few restrictions to be aware of: siteName must be plain text: no markup is allowed. Unicode and whitespace is ok, but keep it short or the dialog box may clip. siteLogo must be a site-relative URL with an absolute path (i.e. it must start with a ‘/’ slash). In the future, we’ll probably relax this requirement and enable absolute URLs and even data: URIs. Images larger than 100*100 pixels will be scaled down to fit. siteLogo requires SSL. The login dialog is served over HTTPS, so the logo image must also be served over HTTPS (to avoid mixed-content warnings), which means your login page (the one that calls navigator.id.request()) must be served over HTTPS too. If you try to use siteLogo from an HTTP-served page, your users will actually get an “improper usage of API” error from the Persona code. But, as a respectable RP who cares about your user’s privacy, your whole site is already being served with HTTPS, right? Right? Support for siteName and siteLogo rolled to production yesterday, so take a look at the docs and give it a spin. And let us know how it works for you, through our mailing list, the #identity IRC channel on irc.mozilla.org, or on Twitter with “#browserid”. [Less]

One of the features we’ve added to Persona’s new Observer API is the ability for websites that use Persona (“Relying Parties”) to add their name and logo to the login screen. To do this, just add a siteName and/or siteLogo property to your ... [More] navigator.id.request() call. The default login screen only shows the website’s domain name, as illustrated below: By adding siteName, you can put additional text in the right-hand RP area: navigator.id.request({ siteName: "Tahoe LAFS" }); Or you can use siteLogo to add an image: navigator.id.request({ siteLogo: "/logo.png" }); You can also use both, in which case the name will appear below the logo. In all cases, the website’s domain name is displayed below the siteName and siteLogo, so the user knows for sure which site is going to receive their email address. Restrictions (Use SSL!) There are a few restrictions to be aware of: siteName must be plain text: no markup is allowed. Unicode and whitespace is ok, but keep it short or the dialog box may clip. siteLogo must be a site-relative URL with an absolute path (i.e. it must start with a ‘/’ slash). In the future, we’ll probably relax this requirement and enable absolute URLs and even data: URIs. Images larger than 100*100 pixels will be scaled down to fit. siteLogo requires SSL. The login dialog is served over HTTPS, so the logo image must also be served over HTTPS (to avoid mixed-content warnings), which means your login page (the one that calls navigator.id.request()) must be served over HTTPS too. If you try to use siteLogo from an HTTP-served page, your users will actually get an “improper usage of API” error from the Persona code. But, as a respectable RP who cares about your user’s privacy, your whole site is already being served with HTTPS, right? Right? Support for siteName and siteLogo rolled to production yesterday, so take a look at the docs and give it a spin. And let us know how it works for you, through our mailing list, the #identity IRC channel on irc.mozilla.org, or on Twitter with “#browserid”. [Less]

One of the features we’ve added to Persona’s new Observer API is the ability for websites that use Persona (“Relying Parties”) to add their name and logo to the login screen. To do this, just add a siteName and/or siteLogo property to your ... [More] navigator.id.request() call. The default login screen only shows the website’s domain name, as illustrated below: By adding siteName, you can put additional text in the right-hand RP area: navigator.id.request({ siteName: "Tahoe LAFS" }); Or you can use siteLogo to add an image: navigator.id.request({ siteLogo: "/logo.png" }); You can also use both, in which case the name will appear below the logo. In all cases, the website’s domain name is displayed below the siteName and siteLogo, so the user knows for sure which site is going to receive their email address. Restrictions (Use SSL!) There are a few restrictions to be aware of: siteName must be plain text: no markup is allowed. Unicode and whitespace is ok, but keep it short or the dialog box may clip. siteLogo must be a site-relative URL with an absolute path (i.e. it must start with a ‘/’ slash). In the future, we’ll probably relax this requirement and enable absolute URLs and even data: URIs. Images larger than 100*100 pixels will be scaled down to fit. siteLogo requires SSL. The login dialog is served over HTTPS, so the logo image must also be served over HTTPS (to avoid mixed-content warnings), which means your login page (the one that calls navigator.id.request()) must be served over HTTPS too. If you try to use siteLogo from an HTTP-served page, your users will actually get an “improper usage of API” error from the Persona code. But, as a respectable RP who cares about your user’s privacy, your whole site is already being served with HTTPS, right? Right? Support for siteName and siteLogo rolled to production yesterday, so take a look at the docs and give it a spin. And let us know how it works for you, through our mailing list, the #identity IRC channel on irc.mozilla.org, or on Twitter with “#browserid”. [Less]

You may have noticed that, as of tonight, https://browserid.org redirects to https://login.persona.org. The main site and login dialog have been re-branded, as we announced a few months ago, to Mozilla Persona. This is one big step in preparation for ... [More] our Beta Launch in mid-August. If you used BrowserID before today, you will automatically inherit the new look-and-feel, and everything will continue to work for your users without interruption. In the process, we added some great new features, which we’ll tell you about on this blog over the next few days. As always, we welcome your feedback via Twitter using #mozpersona or #browserid, and on our mailing list. [Less]

You may have noticed that, as of tonight, https://browserid.org redirects to https://login.persona.org. The main site and login dialog have been re-branded, as we announced a few months ago, to Mozilla Persona. This is one big step in preparation for ... [More] our Beta Launch in mid-August. If you used BrowserID before today, you will automatically inherit the new look-and-feel, and everything will continue to work for your users without interruption. In the process, we added some great new features, which we’ll tell you about on this blog over the next few days. As always, we welcome your feedback via Twitter using #mozpersona or #browserid, and on our mailing list. [Less]

You may have noticed that, as of tonight, https://browserid.org redirects to https://login.persona.org. The main site and login dialog have been re-branded, as we announced a few months ago, to Mozilla Persona. This is one big step in preparation for ... [More] our Beta Launch in mid-August. If you used BrowserID before today, you will automatically inherit the new look-and-feel, and everything will continue to work for your users without interruption. In the process, we added some great new features, which we’ll tell you about on this blog over the next few days. As always, we welcome your feedback via Twitter using #mozpersona or #browserid, and on our mailing list. [Less]

Last Monday, we identified a security hole in the implementation of our Verifier. We deployed a fix in 6 hours. The full details of the issue are available on the wiki. If you’re running a site against our Verifier, you are safe. We did our best to ... [More] identify whether this issue affects other verifiers. To the best of our knowledge, there are no other implementations affected. If you happen to be running a custom verifier, please contact us so we can help you check. Sign up for important Persona service announcements We would also like to take this opportunity to introduce a new communications channel, persona-notices, for those who use Persona in production but don’t have time to read our developers list or this blog. We will only post to the new list regarding topics that may require action by those who rely on Persona, such as: security issues in popular Persona libraries and plug-ins advance warnings about deprecations and incompatible changes to the API changes to the URLs and/or IP addresses of the Persona services In an effort to keep traffic to a minimum, fully backwards-compatible changes, like the introduction of new features, will not be covered on persona-notices. We encourage all relying parties (RPs), identity providers (IDPs) and developers to join this list now. If you have any other suggestions on how to improve our communication with those who rely on Persona, please let us know. [Less]

At the end of last year we introduced an experimental feature called requiredEmail which let websites ask a user to log in with a specific email address, rather than prompting users to select any address. Unfortunately, the use cases we had ... [More] envisioned never materialized, and requiredEmail failed to find traction with our early adopters. Since requiredEmail only acted as a shortcut through our UI, its removal will not break existing sites. Thus, after speaking with all known users of requiredEmail, we’ve decided on a rapid deprecation schedule. Starting July 18th, the requiredEmail option will be deprecated and ignored. Websites using Persona will continue to work without interruption, as users will simply see the normal Persona login dialog which gives them the option of entering an email address of their choice. While we expect to revisit this idea in the future, we’re taking the step of deprecating requiredEmail now so that we can focus on building a lean, stable, and well-supported foundation for Persona. On that note, let us know how we’re doing! Feedback is always welcome on our mailing list, in our IRC channel, or on twitter via the #mozpersona hash-tag. [Less]

A new feature landed in Persona last month that promises to make the sign-in process even smoother by asking users to consent to site-specific Terms of Service and Privacy Policies as a native part of the login flow.This means that sites using ... [More] Persona can easily present their own terms of service and privacy policy to users in an obvious, seamless, and uniform location. Moving user consent into the sign-in dialog also lets websites get rid of their “I agree” checkboxes, while still being certain that users were informed of and consented to the site’s terms on every sign-in.Supporting this API is dead simple, saves users a click, and means one less form for websites to manage. We think it makes sign-in easier for everyone, and we’d love to see more sites using this new, optional feature.  To lean more, check out our documentation and let us know what you think via our mailing list, IRC channel, or by tweeting with the #mozpersona hash-tag. [Less]

A new feature landed in Persona last month that promises to make the sign-in process even smoother by asking users to consent to site-specific Terms of Service and Privacy Policies as a native part of the login flow.This means that sites using ... [More] Persona can easily present their own terms of service and privacy policy to users in an obvious, seamless, and uniform location. Moving user consent into the sign-in dialog also lets websites get rid of their “I agree” checkboxes, while still being certain that users were informed of and consented to the site’s terms on every sign-in.Supporting this API is dead simple, saves users a click, and means one less form for websites to manage. We think it makes sign-in easier for everyone, and we’d love to see more sites using this new, optional feature.  To lean more, check out our documentation and let us know what you think via our mailing list, IRC channel, or by tweeting with the #mozpersona hash-tag. [Less]