Embedded Files
Eric Sachs, Product Manager, Google Security
Originally posted 9/18/2008 (last update 10/27/08)
Federated Login has been a "holy grail" in the identity community for a long time. We have known how to do the technical part for a long time. However the industry has constantly tried, and failed, to find a model that was (1) simple for end users, and (2) had a reasonable trust model between the RP (the relying party, which is the site you want to log into) and the IDP (the identity provider, who will identify you to the RP). Google has been experimenting with different user interface models for federated login using the following design principles:
Design for usability
Leverage what users already know - In particular, leverage the login models with which end-users have experience
Design for widespread adoption - Don't just focus on a small number of IDPs, or just on technically savvy end-users
Allow for gradual migration - In particular, make it work for sites that already have a large set of user accounts who are authenticated without using a federation scheme
One user interface ("UI") model we have been testing has been working surprisingly well. At this time, we want to share the details to gather comments. We also want to look for websites who could help run experiments on this UI design to generate metrics on how well it works. In addition to the UI research below on login boxes, we have also published other user research on related topics on this site including a working demo of this flow and information on a variant of the UI below that simply asks for Email address.
The UI we are suggesting is closest to that of websites like Buy.com and Amazon.com. As an example, here is the current Buy.com login UI:
Notice that unlike a traditional login box which just asks for username/password, they add an additional question for the user to answer. While in some ways this complicates the login box, it actually simplifies the combination of the login box + signup option.
Below is a modified version of the Buy.com UI which uses the UI model we are suggesting. Can you see the difference?
We changed the sentence "I am a new customer" to "Help me login" and the phrase "account?" to "password?" Those small changes are all that is required, but it provides a range of options for the login flow that were not available before. For a website other then buy.com, you would replace the buy.com reference with the name of the actual website (such as in the example below for the website acme.com).
Supported Use Case
In the following sections, we will provide some examples of different use cases that this login UI can support.
Scenario 1: New user from a trusted IDP
If an AOL user comes to the buy.com site with their current UI (as opposed to the suggested modified UI), and has never created an account at buy.com before, then they would enter their @aol.com E-mail address, and choose "I am a new customer." In that case, buy.com would show them an account creation form. However, let's assume buy.com is willing to act as an RP, and it has decided to trust AOL as an IDP. Assuming they switch to the UI model suggested above, then when the user visits the buy.com site, they would enter their @aol.com E-mail address, and choose "Help me sign in." Admittedly the phrase "Help me sign in" is not as explicit as "I am a new customer" however so far our usability tests have shown it works just as well (though we would like help getting more data to confirm that fact).
In this scenario, buy.com could detect that the domain name is for an IDP that it trusts. It could then redirect the user to AOL to verify their identity. Assuming the user approves sharing their identity, then the user will be redirected back to buy.com which can automatically create an account for them, and log them in.
The RP websites (such as buy.com), may also have a separate link/button to promote the option to sign up. Traditionally such a link would take a user to a page where they would be asked to enter their E-mail as well as specify (and confirm) a password. The RP can still provide such a link/button with the login box suggested above, however on the sign-up form we would suggest hiding the password (and confirmation) fields until the user has typed their E-mail address. The RP can then use JavaScript to determine if the domain is a trusted IDP. If so, then after the user submits the form the RP can redirect the user to that IDP. If the domain is not from a trusted IDP, then the password (and confirmation) fields can be automatically displayed (though it might be simpler to request that information after the user submits the first page of the form, or even to wait until the user receives an E-mail validation form and ask them to specify their password at that point.
Scenario 2: Repeat user with an IDP enabled account.
If the same AOL user from scenario 1 visits buy.com's site on another computer, they would be presented with the modified login box UI. In most cases, the user will choose "Help me sign in" just like they did the first time. Buy.com will again redirect them to AOL to verify their identity, and when AOL redirects the user back, buy.com can detect that a local account already exists for the user, and can log them in. However, in our usability studies, we have found more users are confused by this UI the second time they visit then the number of users confused by this UI the first time they visit. The confused users assumed they must have a buy.com password, because that is the experience they are used to for sites where they can login. Fortunately, even though they are confused, nearly all users did enter their E-mail address and clicked the login button. As long as they do that, it does not matter whether they chose Yes or No in the UI, nor does it matter whether they typed a password. Buy.com just needs to know that their domain is aol.com, and can then redirect them to AOL to verify their identity.
Google is evaluating different ways to minimize this confusion. One option is that users who go through scenario 1 should be presented with an educational page by the RP after an account has been automatically created for them. That page can explain to them how they should log in the next time (see the example below). Another optimization is that in scenario 2, if the user choses the wrong option before clicking login (such as saying they did have a password) then the RP could warn them after verifying their identity with the IDP.
Scenario 3: New user from a domain that is not an IDP
Scenario 1 describes how buy.com would handle a user from AOL. However if a new user enters an E-mail from a domain that is not a trusted IDP, then buy.com would simply show the exact same UI it does today to help the user create an account with a buy.com password. An additional option is to ask the user if they have an account with a large IDP who will have already validated a user's E-mail address. Examples include Google Accounts, Facebook, MySpace, MS Live, etc. If so, the user could be sent to that IDP to verify their identity and E-mail, and in the future they could login to the local site by just entering their E-mail and choosing "help me sign in." In that case the local site could lookup which big IDP was associated with that E-mail address, and redirect the user there.
Scenario 4: Legacy user from a domain that is not an IDP
In this document we use the term "legacy user" to refer to someone who already has an account at the RP and which uses a local RP (buy.com in this case) password. If such a legacy user enters their E-mail/password in the login box, then buy.com would log them in as it does today. However that assumes the user is from a domain that is not a trusted IDP. As in scenario 3, an additional option is to ask this user if they have an account with a large IDP, and if so use that IDP to authenticate the user in the future.
Scenario 5: Legacy user from a domain that is an IDP
If a "legacy user" logs in with an E-mail address that is from a trusted IDP like AOL, and provides a valid buy.com password, then in this situation the RP can promote the option to "bind" their existing buy.com account to a federated login using AOL as an IDP. If the user chooses that option, they will be redirected to AOL, and then back to buy.com. Buy.com can then associate their AOL identifier with the pre-existing buy.com account. Buy.com could optionally disable the user's ability to login with their legacy password.
Scenario 6: Help me sign in
Usability testing indicates that some new users will simply select "No, help me sign in" and then click the Sign In button. For those users, the login box can display an error requesting the user's E-mail, but users respond better if they are redirected to a page which gives more context about what is happening and then asks for their E-mail address.
Design Principles
The five scenarios listed above are the most common use cases. There are some edge cases discussed further below, however it is worth first discussing how this UI fits into our design principles:
Design for usability
This UI adds very little additional information/options to a traditional login/signup scren. It may even simplify some websites who have seperated the username/password login option from the signup option.
It can support browser auto-fill for legacy users, as well as new IDP verified users.
If the user is already logged into their E-mail provider (which they normally are), and has asked their IDP to remember RPs that they have visited before, then the # of steps needed to login to buy.com is the same as with a legacy account, i.e. the browser does autofill, and the user just clicks login.
Leverage what users already know
While the login UI of buy.com/amazon.com is not widely used, there is already data that shows it works well (and even better then a traditional login box in many situations).
The suggested UI also leverages an E-mail address to identify the user's IDP. However for advanced users, as described below, they can use other methods to identify their IDP.
We also avoid expecting the user's to know more then they do today. Specifically, a user who does not know anything about the concept of federated login or the relationship between the RP & IDP can still use this login UI to sign in with a federated identity.
Design for widespread adoption
This UI allows the RP to trust any number of IDPs, just as traditional E-mail based login systems support any number of E-mail providers.
The UI can be used with different federation protocols. For example, the RP might use OpenID with some IDPs, SAML with others, and a proprietary protocol with a few big IDPs. Some large E-mail providers like AOL, Yahoo, Microsoft, & Google already provide federation protocols that could be used with this UI.
Google has had positive results in usability testing of this UI with "average" Internet users who are not technically savvy, and who are in different age ranges.
Allow for gradual migration
A website that is considering becoming an RP can switch to this UI model, and then evaluate the impact on logins/signups before trusting any IDPs
The impact on legacy users should be minimal
The RP can control what IDPs it trusts, and even switch their users back to legacy logins if the IDP becomes untrustworthy
The RP can allow users with legacy accounts to continue to use their legacy password
While Google has had good results with this user interface, it still requires the RP to trust the IDP. In some cases, it will be difficult for the RP to trust any IDP. For example, Google offers the Google Checkout service which lets users pay for purchases they have made on other websites. This requires Google to meet many special certification requirements that traditional e-commerce site do not need to worry about, including special certification on how we authenticate our users. Online banks similarly have certification requirements on how they authenticate their end-users.
However, many websites do not have these types of restrictions, and so we hope that some of those sites will experiment with this type of UI, and report their results so that this UI model can be refined. One thing to remember is that most websites which rely on E-mail based logins already trust the E-mail provider to validate the owner of an E-mail address, not just for account creation, but also for account recovery. So technically, those websites already act as RPs to those E-mail providers.
Login Identifiers
In the scenarios described above, an E-mail addess was always used as the identifier in the login box. However, it is worth noting that this is not a requirement. For example, in most cases it would be sufficient for the user to just type their domain name. In fact, if the IDP uses opaque federation identifiers, then that would allow the user to consistently login to that website from different computers, but without any globally unique, or personally identifying information, being shared with the RP. Even if the IDP uses global identifiers such as URLs, the user could still enter the domain name of their preferred IDP, even if it was not their E-mail provider. For example, some users might enter facebook.com or myspace.com to leverage those popular social networks' identity services. Other users might enter pip.verisign.com to leverage Verisign's 2nd factor authentication service. A smaller group of users might enter a full URL (like an OpenID validated URL for their blog), or a mobile phone number which can be validated by sending it an SMS message.
However, there is a tricky balance to be found between promoting these options to advanced users, and avoiding confusing regular users. Some websites that have experimented with federated login technology have tried adding specific buttons for particular IDPs, in addition to their regular login box. For sites with technical users, that has minimal impact, however sites with a wider audience have reported that their regular users get confused by these additional options. In addition, there is a chance that the same user might login via the regular login box one time, and then later try to use one of the custom IDP buttons. That requires the website/RP to present additional UI to try to detect those situations, and this can further complicate the signup process.
We hope that different websites will experiment with different UI options to promote these options. For example, a website might change the sentence "Enter your E-mail address" to "Enter your E-mail address or IDP" where the word IDP provides a popup with more details. Another website might add a sentence to the bottom of the login box that says "Logins supported from: X Y Z" where X, Y, & Z are small icons for some large IDPs who are not E-mail providers such as MySpace & Facebook.
New Account Signup Flow
One of the biggest reasons the industry has focused on federated login is to minimize the work required for a user to signup for a new account at a website. When users are presented with a traditional signup page that asks for E-mail, password, & password confirmation, it is quite common for 30-50% of users to not finish the process. So in this next section, we look at the specifics of how the signup flow interacts with federated login using a few scenarios:
Scenario 1: RP just needs a consistent identifier
Some websites do not care about the user's E-mail address, but they ask for it anyways because it is easier for users to remember that then to ask the user to create a username on the site. The simplest signup page for such a site would simply ask for E-mail address, password, and password confirmation. If a new user enters an E-mail for a trusted IDP, then the user will be sent to the IDP to get approval to verify their identity, and will then be sent back to the RP. The site can simply skip the signup page completely, and log the user into the website. So there are two possible flows for end users:
legacy signup: 1 login page which collects their E-mail, and a 2nd page which asks for E-mail, password, password confirmation
IDP signup: 1 login page which collects their E-mail, and a 2nd page which asks the user to click a button to approve sharing their identity
Scenario 2: IDP who uses opaque identifiers
If the IDP supports using opaque identifiers, then a user may have told the IDP to auto-approve any identity verification request by an RP. This has minimal privacy impact because the only information the IDP is sending the RP is an opaque ID, however it creates a single-sign-on experience for end-users that is more like what they are accustomed to in an enterprise single-sign-on system. The primary privacy concern of this option for some users is that if they are logged into the same IDP on two different machines, then RPs can track their activity across those two computers. Of course some users may not want to be tracked in that manner, while others will consider it a helpful feature to make their Internet experience more "portable" across computers. In this flow, the IDP signup takes only 1 page, the login page.
Scenario 3: IDP hint
Before the user visits the RP's website, they may be on the website of an E-mail provider, or a site that can provide the E-mail domain of the user. For example, if the referral URL is mail.aol.com, then the RP can be quite confident the user is an AOL user. If the referral URL is a websearch provider, then it is possible that the user was already logged into the websearch provider, and thus the websearch provider could pass along the user's E-mail domain as a URL parameter for a redirect caused by an ad click or websearch click. Another option is for a browser extension to detect the last IDP that the user logged into, and send that parameter in the HTTP headers along with other information such as the user's language preference list. If this IDP hint is passed to the RP's site, and the RP is willing to trust it, then it could send the user to that IDP immediately. If this flow is combined with that of an IDP who uses opaque identifiers, then the signup process can be 0 steps. However in most cases, the RP will treat this is just a hint, and will modify their login box to say something simple such as "Login with your @aol.com account" which would take the user to the AOL IDP, and a smaller option underneath that says "Or use a different account" which would display the same login box that the RP uses when the IDP hint is unavailable.
Scenario 4: Terms of Service
The scenarios above describe the most optimal user experience, however many sites have more complicated requirements. For example, the site might require users to agree to a Terms of Service. In scenario 1 this would add a 3rd page to the IDP signup scenario, and make it more pages (though still less work) for the user. Depending on your legal requirements, it may be possible for you to avoid showing the TOS on a full page, and instead log the user into your site, but show a visual banner of some type near the top that includes a link to the TOS to make sure users have a chance for informed consent. Unfortunately in some cases your site might have more complex legal requirements, such as requiring that users click a box to confirm they have read the TOS. Some IDPs may even be willing to show the TOS of the RP on their approval page, however the RP's lawyers will need to evaluate whether that meets their legal requirements.
Scenario 5: Training Page
In "Scenario 2: Repeat user with an IDP enabled account" we mentioned that returning users are sometimes confused by this suggested login UI, but that the confusion can be reduced by adding a "training page" during the new account process. Unfortunately that page does add a step to the account creation process. However, if your site already needs to show a page after the IDP verification, such as a Terms of Service page, you can combine the two.
E-mail Identifier
One of the trickiest parts of the new account flow that we have found in the use of federated login is the use of E-mail as identifiers. Most websites use E-mail addresses to enable their legacy users to login. If an RP then starts to trust an IDP who provides E-mail, it needs a way to map legacy users to federation identifiers. If the IDP does NOT support E-mail validation as part of the federation protocol, then there are a few techniques the RP can use:
If the RP gets a new federation identifier from the IDP during a login, then instead of immediately creating a new account for the user, it can prompt the user to ask whether they have an existing account. If the user says yes, then they can be asked to provide the password of that legacy account so that the federation identifier can be bound to it. Unfortunately this adds another step to the signup flow for ALL users who try to use federated identity. However the RP could combine it with a page that shows a Term of Service and/or Training information as described in scenarios 4 & 5 above.
An alternative to #1 is to prompt the user for their E-mail address after the IDP verified their identity. That E-mail can be compared to existing accounts. If it matches a legacy account, then the user can be asked to provide the password of that account. If it matches an account that already has a different federation identifier, then the user can be asked whether to use the old or new federation identifier. If it does not match an existing account, then a new account can be created and the RP can send a message to that E-mail address with the traditional one-time use URL to verify ownership of that E-mail.
The RP can detect cases where a user filled out the RP's login box with an E-mail address that did not match a legacy account, and then chose "help me sign in." In that case, if the IDP sends back a new federation identifier, the RP might choose to hide the prompt that asks the user if they have an existing account on the assumption that the user typed their E-mail correctly. Of course, there is a chance that the user mistyped it by accident.
The RP can detect cases where a user filled out the RP's login box with an E-mail that refers to an E-mail domain for which the RP has NO legacy users. In that case, the additional prompt to check for an existing account is not needed. For new websites who start using this suggested login UI from the beginning, this may work well. But for established websites, it probably will not help much.
Some IDPs do support the ability to request the user's E-mail address at the same time that the IDP sends a federation identifier. In some cases, the E-mail address itself is actually the federation identifier. However, that can be problematical if the E-mail provider recycles E-mail address when an end-user deletes their account, or if the E-mail provider allows the user to change their E-mail address (such as if they got married and changed their last name). For IDPs who support the ability to combine federated identity with E-mail validation, the RP can use that protocol. Unfortunately it removes the potential optimization of "Scenario 2: IDP who uses opaque identifiers" because the IDP will not be able to auto-approve requests for a user's E-mail address since that is personally identifiable.
Note: One edge case is that the user's E-mail address on the IDP might not be an exact match for the E-mail address they used with their legacy account. For example, a Google mail user can have an E-mail address such as adam.smith@gmail.com, but they can also receive mail at adamsmith@gmail.com. Some Gmail users have legacy logins that use those E-mail addresses with "." characters in different locations then their primary address. The RP will need to keep a list of the domains that operate this way, and whenever it compares a legacy E-mail address to an E-mail assertion it gets from the IDP, it will need to remove all "." characters before the "@" sign from both E-mail strings before doing the comparison. For legacy users, the RP should probably continue to keep the legacy E-mail address for the user instead of replacing it with the one asserted by the IDP. The advantage of doing that is that the user may have filtering setup in their mailbox based on the location of those "." characters.
Longer term, a more privacy sensitive RP can monitor to see if all the legacy users in a given domain are now using federated login. If so, it could potentially stop storing the E-mails for that domain, and only ask the IDP for that domain to send the opaque identifier of the user. However, if that IDP disables their IDP verification service, or it becomes unstable, then the RP cannot authenticate the users from that domain. Therefore, a more conservative RP is likely to continue to require E-mail addresses because they can be used as a backup way to authenticate users in that situation by sending the user a traditional E-mail verification or Forgot Password link.
Attribute Collection
Some RP websites need to gather other information about the user in their signup flow such as zipcode, country, gender, etc. Generally this information is collected at the same time a user would be shown a Terms of Service page as described in "Scenario 4: Terms of Service." However, if the IDP supports E-mail validation, they mail also support the exchange of other attributes. Thus, if the RP trusts an IDP who provides E-mail validation, and has already decided to use that feature, then it should check whether the IDP also supports the exchange of other attributes because that may be used in some cases to further simplify the signup process. However, the RP should be prepared for the situation where some users at the IDP do not have all requested attributes (or don't allow the IDP to share them with the RP), in which case the RP will need to collect them.
In Google's usability tests, we found that there are some common attributes that are unlikely to be personally identifiable, and which users tend to be very comfortable sharing from an IDP to an RP. Those include Country, Zip Code, Language, & Time Zone.
Comparison Summary for Sign Up
A key goal of federated identity is to make the new account signup process simpler. Below is a summary of the steps required in one of the most common cases, which is a website which needs an E-mail, ZipCode, & Terms of Service. If the Website is not an RP, then new account flow is as follows:
Step 1: User clicks a Create Account button
Step 2: On the next page they are prompted for (1) E-mail address, (2) password, (3) password confirmation, (4) ZipCode & (5) Terms Of Service
Below are the steps if the Website is an RP, and the user is logged into an IDP which the RP trusts. This assumes the IDP supports a federation identifier & E-mail address validation.
Step 1: User enters E-mail address in login box and chooses "Help me sign in"
Step 2: On the IDP they are prompted to approve sharing their identity & E-mail address
Step 3: On the RP site they are asked to enter their Zip Code, agree to the Terms of Service, and they are also shown "training" information on how to login in the future
Note that the federated signup process is more steps, but in our usability studies the removal of the double password prompt is a significant benefit. We hope that some websites will experiment with this type of UI, and report back the % of users who finish the new account flow using the federation technique as opposed to the traditional method. That % is also likely to vary based on the IDPs user interface and functionality, so it will be helpful for websites to report the % success for different IDPs so that the IDPs can learn what techniques work best.
Comparison for Sign In
The second key goal of federated identity is to make the sign in process simpler for user's who already have an account. The comparison here is complicated by the "saved password" feature of some browsers. If the end user is on a machine that does not have any saved credential information for a particular RP, and they are already logged into their IDP/E-mail provider, then it is less work for the user to login using federated identity (especially if they would have otherwise have used a hard to remember password at the RP site). However, in the common case, a user is logging into a website from their home computer and their credentials will have been pre-filled into the login box by the browser. In that case the user simply has to click the login button, and it is hard to make the process much simpler then that. If the user logged into an RP site using federated identity, and the browser did not save any credential information, then the user will have to type their E-mail address every time they come back to that site (though some browsers at least support type-ahead). The behavior varies by browser, but when possible, the RP should try to leverage the browser's ability to save the user's E-mail address for auto-fill or type-ahead purposes.
Implementation Guidelines
If your site does choose to implement the user interface guidelines described in this document, we have provided a checklist to help you evaluate your implementation.
Appendix
Desktop Apps
The UI flow described above works on the web, even with different (and sometimes proprietary) federated identity protocols. However for a desktop app (or a mobile client app like a J2ME app), this mechanism is much harder to use with those identity protocols because they are generally designed to be used with web clients. If your website needs to support legacy client apps that cannot be modified, like Outlook, then you may not be able to use federated login unless the IDP is willing to use some background mechanism to sync a copy of their passwords to your RP. However if your client apps can be modified, then one option is to use the OAuth (www.oauth.net) protocol. That defines a standardized flow for a desktop app to request a token from your RP that will be used for data access, however initially the token is invalid. The client app then, if possible, launches a web browser and sends the user to your site to first login, and second to be shown a screen they can use to make that token valid. Once the user is in their web browser, they can use the technique above to login with a federated identity, but then are redirected back to your RP site to show the token approval page. If the client app cannot launch a web browser, it can direct the user to launch one manually (even on a different computer), and go to a URL on your website where they will first login (using federated identity). After they are logged in, your site can ask the user to enter the token that needs to be approved by having the client app display it. After the end-user has used one of these two mechanisms to approve the client token, the client app will then be able to access the user's data.
The technique above works well when the client-app only works with one, or a few, sites. However if a client-app is being built to work with any site that supports a particular data-protocol (such as the new OpenSocial REST APIs), then this technique will need some special setup because OAuth requires the client app to know what URLs to use for interacting with the data provider site (to request a token, to request data, and to redirect the user to approve the token). The client app usually needs to be pre-configured with that information, though the OAuth community is discussing ways to enable that to happen automatically in a standard manner.
Account Settings page
If a website becomes an RP, then in addition to modifying its login box, it should also modify the UI of its account settings page. For a non IDP user that wants to change their E-mail address, then the RP needs to check if the old or new domain is a trusted IDP. If the new domain is a trusted IDP, then the user needs to be sent to that IDP to get the associated federation identifier. For an IDP user, the option to change the password should be removed, and instead they should just have the option to change their E-mail address (which technically is bound to an IDP). If they choose the option to change it, then the RP should first attempt to redirect the user to their IDP using the OpenID PAPE extension to force the user to re-authenticate (assuming the IDP supports that feature). Then the user should be asked for their new E-mail address. If it is for a domain that is not an IDP, then the user will also need to be asked to specify a password. Otherwise they should be redirected to the IDP of the new domain to verify their identity.
Forgot Password flow
The proposed login box UI uses the generic "help me sign in" term. Some legacy account holders might choose that option if they forget their password, so the RP will need to detect that situation and sent them to the forgot password flow. Some RPs may still keep a separate link on their login page that specifically links to the forgot password flow. We hope that RPs will experiment with different wording/location of that link (as well as not showing it), and report back the comparative usage rate.
Browser auto-fill, tab order, and signup
RPs who use this approach should be carefull note to break the login autofill feature of browsers. The fieldnames of the E-mail address and password fields should not be changed. The tab order of the fields should be (1) E-mail (2) the two radio box options, (3) the password field, & (4) the login button. The addition of item 2 (the radio boxes) will add one step for legacy users, however what major websites have found is that the autofill feature of browsers is so commonly used that tab order for existing users is of minimal importance. By default, the radio box option should be set to "I have a password," however if the previous login on that computer was done using federated login, then the RP should set a permanent cookie on that computer to remember that preference and to changet the radio box to the "help me login" option. For new users who need to signup, they have the option to choose "help me login" and then to click login. However if the RP has room of the page, it is also good to have a single signup button since that is fewer steps (however in that case the RP should use a modified signup form as described in scenario 1 of the Supported Use Cases section.
Session Timesouts and Reauthentication prompts
See http://sites.google.com/site/oauthgoog/Home/reprompts
Websites with strong authentication requirements
Some websites, such as online banks, are unlikely to be able to trust consumer E-mail providers to act as IDPs for authenticating their customers. Those sites frequently ask users to register a username (as opposed to E-mail address) that is used to login to their site, however numerous studies have shown that users have a hard time remembering unique usernames for sites in addition to password, which is the main reason most sites use E-mail addresses instead of usernames. However, those sites could experiment with using the UI suggested here as one form of authentication, and then also using a second authentication mechanism. For example, after the user has been authenticated by their IDP, the site could check what second factor of authentication should be used to verify the identity of that particular account. It could be an image that the user associated with their account, a PIN code, a physical token, mobile phone, etc.
Scaling the set of supported IDPs
Some websites may want to aggressively support as many IDPs as possible. However, there are technical and legal/trust barriers to achieve that goal. On the technical side, there is no single standard for federation protocols. Even when multiple IDPs use the same protocol, there can be some variance in how they use it. For example, some IDPs might support OpenID using global identifiers (like URLs) and others via opaque identifiers. Or some IDPs might support the OpenID discovery protocol for their top level domain name, like gmail.com, while others require the RP to know that a subdomain should be used. However the protocols in this space are evolving, especially the automatic discovery mechanisms which allow an RP to support different ways of interacting with IDPs, and then checking which methods a particular IDP supports.
On the "trust" side, there is the potential for brokers to exist that operate an identity provider's IDP service for them, just as some company's outsource hosting their E-mail or website. Those brokers could develop a reputation, or even legal contract, for a certain quality of service, user experience, and protocol support. That would then allow RPs to support any IDP operated by a trusted broker.
Phishing Increase
Some potential IDPs will be concerned that becoming an IDP will make it easier for their end-users to fall prey to phishing attacks. That is because an "evil" RP could intercept the user when they would normally be sent to the IDP, and instead show the user what looks like a login page for their IDP. The RP could then use that phishing page to collect the user's credentials. We do not have a magic answer for that problem. A similar problem also exists with web delegation protocols like OAuth. In the case of web delegation protocols, the user demand for access to their data was too high for websites to ignore, especially when users would give their credentials to 3rd party sites which would then scrape the main site for the user's data (such as social networks scraping a user's E-mail address book). End-users have a similar demand for federated identity, and because of the lack of it, many users will simply use their exact same password on their E-mail provider's site as they do on many other sites where they login with that same E-mail address. It will be up to individual IDPs to decide how to balance demands from their end-users with concerns about potential increases in phishing attacks.
Eric Sachs
Product Manager, Google Security
E-mail: google.com (username esachs)
Page updated
Google Sites
Report abuse