Wish List for OpenID Providers

 

This wish list is intended to make OpenID a better experience for the end users and Consumer sites. Many of the items on this list can be achieved if OpenID Providers agree on standards and practices beyond those defined by the OpenID protocol.

 

• Registration
• Consumers and Providers need a large set of predefined attributes; such as email, firstName, gender, etc.
• When registering a new user the Consumer should be able to tell the Provider what attributes it would like to receive and specify which ones are optional and which ones are required.
• When prompted with a registration form at the Provider the user should be shown which fields on the form are required and which are optional and be allowed to select per field level which ones they want to submit and which ones they don't want to submit. The end user should not be allowed to change the values on the form; they should only be allowed to select which ones they submit.
• The user should be able to have predefined templates that define sets of fields to submit.
• When registering as a new user at a Provider site the user should be able to give their OpenID at another Provider and have the information imported after verifying with that Provider.
• Messages from Consumer Sites
• End users will login to the Provider accounts on a regular basis. If a Consumer site has an important message to send to an end user it should be able to send this message to the Provider to be shown to the end user. The user should be able to control from their Provider account which sites to accept messages from. A Consumer site that tries to send a message to a user who has chosen not to accept messages from this site should be informed so by the Provider.
• User Control of Identity Info
• In the Provider account the user should be able to view what fields they have submitted to which sites and what fields are required and what fields are optional.
• In the Provider account the user should be able to discontinue sharing optional fields with a Consumer site.
• In the Provider account the user should be able to make changes to their info and have it pushed to all the Consumer sites they have submitted that info to already. This provides an easy way for the users to update their information at all sites and helps the Consumer sites ensure they have the latest information.
• In the Provider account users should not be allowed to have multiple profiles. Consumers should be able to assume that each identity Provider account maps to one user profile.
• User Control of Provider Account
• Users should be allowed to delete their identity account with any Provider. The Provider should comply by removing all data associated with the account within one week. The user should be allowed to undelete the account for at least three days after deleting it.
• Transfer of Account from Provider to Provider. Users should be allowed to transfer their complete account information from one provider to another. After the account is transferred to the destination provider the source provider should delete all information associated with the account. In the destination account the user should be able to access the Consumer sites they had already established accounts with and continue controlling what information they are sharing with the sites.
• Linking of accounts between different Providers. The main purpose of this feature is so that if one Provider's service is down the user is not left without any way to access their Consumer sites. The user should be able to use another Provider for accessing their sites. A user should be able to link accounts at different Providers so that the user can use either account to confirm their identity with a Consumer. The Providers should automatically synchronize the linked accounts when the user makes any changes in any one of the linked accounts.
• When a user creates a new account at a provider the user should be asked if they would like to transfer another account to this account or to link another account with this account. This option is only given when the user initiates the account creation and has not yet entered any other information into the account.
• Role Accounts
• Imagine a case where company C has an account at retailer R and various employees of company C need to access the account at retailer R to make purchases. An OpenID account called rolesForC.myopenid.com is created with the Provider myopenid.com by John who is the owner of company C. The rolesForC account is used to establish an account with retailer R. Thus if one knows the password for the rolesForC account at Provider myopenid.com they can access the account at retailer R. However John would like to have other employees be able to access the account at retailer R without having to give them the password to the rolesForC account. In the rolesForC Provider account John should be able to specify on a per site level the IDs of other accounts that can take on the role of this account. So under the site management section of the rolesForC account John select the site for retailer R and chooses the option to add role accounts to it. John adds jane.claimid.com to the list of role accounts for the retailer R site. Now Jane can enter rolesForC.myopenid.com at the retailer R site. When she is redirected to the Provider myopenid.com she will be prompted to enter her own account. Here she enters jane.claimid.com and is redirected to the Provider claimid.com. Since Jane is already logged in to her account at claimid.com she is verified and passed back to myopenid.com with a positive confirmation. myopenid.com then passes her back to retailer R with a positive confirmation. Thus Jane is now logged into the retailer R account and can make purchases for the company. Jane does not have any control over the rolesForC account and John can remove her from the roles list for the retailer R site at anytime. In this example myopenid.com has acted as a Consumer for claimid.com. The Consumer site for this transaction should be something like "rolesForC.myopenid.com::retailer.R.com".
• It is possible for Jane to login to her jane.claimid.com account and add tom.webid.com to the roles list when the Consumer site is "rolesForC.myopenid.com::retailer.R.com". Thus Jane is able to further delegate the role account. However, John must explicitly set the rolesForC account to allow Jane to be able to further delegate roles by setting the max delegation level to something higher then the default of 0. John can also set the max delegations value for Jane to something like 3 so that Jane cannot delegate to more than 3 people.
• When a Provider gives a positive confirmation to a Consumer (the Consumer could be a Provider acting as a Consumer) it should indicate to the Consumer if a role account was used and the ID of the end user account. It should also indicate the levels of delegation between the end user and this Provider as well as the total number of users in its role list combined with the total of any previous levels. This information allows the Consumer site to be able to reject the login if it exceeds certain criteria like max level of delegation. It also allows the Consumer site to provide access rights within the account based on the end user.
• Prevent Phishing
• If a user is not already logged into the Provider account when redirected from a Consumer to a Provider, the Provider should give only a message that tells the user to first login to their OpenID provider and then give their OpenID again at the Consumer site. Providers should not give users a password entry form when redirected from Consumer sites. Users should be made aware by Providers to never enter their password when trying to enter a site using their OpenID. Users should be educated to first go to their Provider site, login to their Provider account and then go to Consumer sites. This can be acheived if all Providers agree not to prompt users for the password when they are redirected by a Consumer site.
• In the Provider account the user should be able to select a Consumer site and click on a link to automatically be logged into that site. This helps prevent phishing by making it convenient for users to login to their Consumer sites directly through their Provider account. This would require Consumer sites providing the URL of where to send the user. The Providers may also be able to get this from the HTTP_REFERER field when a user is redirected to the Provider by the Consumer site.

Omar Syed
2007.03.08