Checklist
4b - Can a new user from an IDP domain be created, and without sending a separate E-mail to the user to verify their E-mail address?
4c - If 4b works, does the RP's account settings page show the E-mail address from the IDP as associated with the account?
5a - When a new user is signed up using an IDP, how simple is the page the RP displays after the IDP sends them back to the RP?
5b - Does the page, or the next one, show a visual "training" image for how to login the next time?
5c. If a new IDP user enters their E-mail and a password into the login box, are they shown a re-education screen to remind them to use the "help me login/sign" button in the login box in the future?
6a. If a new user enters one E-mail in the login box, but the IDP returns a different E-mail that has never been used with the RP, will the RP help the user finish creating an account?
6b. Same as 6a, but if the E-mail returned by the IDP already has an account at the RP, does the RP automatically log the user into it?
6c.For a non IDP users who enters an existing E-mail, and chooses help me sign in, does the RP send the user to the forgot password flow?
6d. Same as 6c, but if the user is a legacy user with an E-mail from an IDP domain, are they prompted to upgrade to federated login?
7a. For IDP users, does the Account Settings page hide the password change option, but still allow the user to change to a new E-mail (including an IDP email domain)?
7b. For non IDP users, does the Account Settings page allow the user to change to a new E-mail (including an IDP email domain)?
This document provides a checklist for RPs implemented the user interface described in Google's federated login research.
1a - Does the login page have a special link for signup that is separate from the login box with the "help me login/signin option?"
1b - Does that signup link take the user to a form where the password (and confirm password) fields are hidden?
1c - If the user enters an E-mail for an IDP domain on the signup form, does the RP redirect the user to the IDP?
1d - If the user enters an E-mail for a non-IDP domain on the signup form, does the RP at some point collect the password (either by auto-displaying those fields in the form, or asking for them after the form is submitted, or asking for them after the user verifies ownership of the E-mail address)?
2a - Test if a legacy non-IDP user still works after switching to the new UI
2b - Test if a legacy user with an E-mail in an IDP domain is prompted to upgrade to federated login, and the upgrade process works.
2c - Rerun 2b, but have the IDP return a different E-mail then the one associated with the legacy account. Does it work, and does the IDP switch that account to be associated with the new E-mail?
2d - Rerun 2b, but test the scenario where the legacy E-mail and the IDP asserted E-mail are the same, except they are @gmail.com addresses with "." characters in different places. Does it work, and does the IDP keep the old E-mail?
3 - If the legacy system support username logins as well as E-mail based logins, does it ensure that multiple usernames cannot be associated with the same E-mail?
4a - Can a new user from a non-IDP domain be created?
8a. Does the RP use the same HTML field names for the E-mail/password entry boxes in their old and new login box? If not, then the password autofill feature of browsers will break when the RP switches to the new UI.
8b. Is the tab order of the fields of the login box (1) E-mail, (2) radio box for two options, (3) password, (4) login button?
8c. If a user logs in via federated login, then does the RP set a cookie to change the default value of the radio box to "help me login?"
8d. If the default value of the radio box was set to "help me login?" but the user logs in without federated login, then is that cookie removed?