Certification Profile
Introduction
The identity provider industry has been establishing best practices for different types of identity providers for different use cases. Below are some of the evolving profiles. Companies who run an identity provider and would like to help evolve these profiles should contact the OIX. Some relying party services such as the Google Identity Toolkit (contact esachs@google.com) and Janrain (contact www.janrain.com) will work directly with identity providers to certify and integrate with them.
Trusted Email Profile
Use case: Many websites with a large installed-base of accounts that login with Email & password would like to become OpenID relying parties. However they only want to support IDPs who provide a higher success rate then their current approach for both registration and login rates. Instead of each website identifying those IDPs, they would like a central neutral organization like OIX to maintain a list of IDPs who meet certain known requirements. The following profile lists those known requirements.
The IDP must:
support a PAPE request to indicate that the IDP's assertion should follow this specific certification profile
Or possibly the certification whitelist provides a specific URL endpoint for this profile
meet all requirements of the GSA OpenID ICAM Profile except the requirement to avoid sending PII to the RP, and the ability to use an OpenIDConnect style flow over OAuth2 instead of OpenID v2 (see this article for an idea of the steps involved in certification)
use an authentication scheme that is at least as strong as the suggested best practices for the ICAM profile
also have procedures in place to detect likely hijacked accounts (such as monitoring for outbound spam or usage from unusual IPs) and then suspend those accounts (including their ability to login to OpenID RPs) until they perform an account recovery process
have a historic 99.5% uptime of its authentication and OpenID IDP system
support OpenID discovery based on either the domain name (using directed identity) or an Email address in that domain (using webfinger)
Or a simpler option is for the OIX to publish metadata about certified providers including endpoint information and the prefix of URLs an IDP can assert
support AX requests for the AX "email" parameter and return that parameter on every request, even if it has not changed
only return the email address that the logged in account receives over the open Internet via that SAME IDP's SMTP service (and thus is equivalent to traditional email validation)
return an unchanging and non-recycled OpenID claimed URL for the account (follow the OpenID standard to indicate recycling if necessary)
show at most one page in 99% of the consent flows once the user is authenticated
default to NOT requiring the user to re-enter their password during the OpenID flow if the user had already been authenticated by the IDP before the OpenID request was made
default to auto-approving future logins by a user to the same RP
auto-detect mobile and non-JS browsers and show consent pages that are friendly for them
provide the certifying organization with a list of the optional features below that they support so that the certifying organization can published them as metadata attached to the list of certified domains
The IDP should:
support checkid_immediate
NOT require the RP to pre-register with the IDP or enter into a legal contract with the IDP to use that IDP API (similar to the model of SMTP)
support the PAPE openid.pape.max_auth_age parameter, though it can choose to always re-authenticate the user no matter what value is passed in that parameter
support AX requests for
first&last name/nickname/age/birthdate/gender/location if those attributes are known for the logged in account
the ?A attribute with a value of TRUE if it is highly confident the account is owned by a real person. Some best practices for meeting that definition are that the account is paying the IDP for services, or the IDP has verified the account owners phone# and/or credit card #, and that # is not associated with a large (>10) number of other accounts.
the ?B attribute with the time the users authentication mechanism/value (such as password) was changed
support the PAPE ?C standard to request that the user change their authentication mechanism/value
support webfinger discovery, and allow
the RP to pass the OpenID URL of the target email address as the openid.identity and openid.claimed_id. The IDP should return an error if they cannot authenticate the owner of that particular account
the RP to pass the OpenID URL of the target email address as a hint of the target account using the ?D technique
support ?? flexibility in realm discovery so that if company A acquires company B, and a user has already approved auto-logins to company A, then company A can declare it is associated with B so the user is also auto logged in there
return the same OpenID URL to each RP so that RPs can pass it between each other to provide cross-site personalization instead of passing the Email address that is more frail since it can change
support the popup UI extension where openid.ns.ui is set to http://specs.openid.net/extensions/ui/1
support the publication of the login session status on the IDP to xauth.org
support the ability to display the logo of the RP on the consent page using either
the openid.ui.icon=true value to cause the RP's favicon to be displayed
the ?E standard to cause the RP's larger logo to be displayed
support the ?F standard for displaying the TOS of the RP on the consent page
support the ?G standard to provide a more flexible realm match for RPs to leverage the auto-approval login feature
support the ?H standard to advertise their support of the optional features listed above
Email Validation Profile
Use case: Many websites with a large installed-base of accounts that login with Email & password would like to use OpenID to validate ownership of an Email address, but NOT for login. However they only way to support IDPs who provide a higher success rate then their current approach for registration rates. Instead of each website identifying those IDPs, they would like a central neutral organization like OIX to maintain a list of IDPs who meet certain known requirements. The following profile lists those known requirements.
The IDP must meet all requirements of the Email Equivalent profile except the following requirements
default to auto-approving future logins by a user to the same RP
Untrusted Email Profile
Use case: Some IDPs can assert an Email, but do not host the Email. This includes consumer web services like Google, Facebook, Twitter, MS Live, etc. Many websites with an installed-base of accounts that login with Email & password would like to give their users the option of binding an account from such an IDP to a local account at the website that has the same Email address. However they only way to support IDPs who provide a higher success rate then their current approach for registration and login rates. Instead of each website identifying those IDPs, they would like a central neutral organization like OIX to maintain a list of IDPs who meet certain known requirements. The following profile lists those known requirements.
The IDP must meet all requirements of the Email Equivalent profile except the following requirements
only return the email address that the logged in account receives over the open Internet via the IDP's SMTP service (and thus is equivalent to traditional email validation)
The IDP should:
support the ?I standard for an AX request for a flag to specify whether the IDP has verified the user's ownership of the email address that is asserted. That standard may even need to specify how the email was verified. For example, when the user created the account, did the IDP create a signed cookie and then check for the existence of it when the user came to the verification URL (or alternatively prompted them to enter the password after coming to that URL). Or did the IDP use OpenID to contact the IDP (using any federation protocol) of the user's Email address?
support the ?J standard to indicate how the user was authenticated, including the ability to indicate this IDP authenticated the user by redirecting the user to the IDP (using any federation protocol) of the user's Email address.
URL only Profile
Use case: Some IDPs can assert a URL, but not an Email. The traditional example is a consumer web service that hosts blogs or personal home pages. Many websites with an installed-base of accounts that login with Email & password would like to give their users the option of binding an account from such an IDP to a local account at the website. However they only way to support IDPs who provide a higher success rate then their current approach for registration and login rates. Instead of each website identifying those IDPs, they would like a central neutral organization like OIX to maintain a list of IDPs who meet certain known requirements. The following profile lists those known requirements.
The IDP must meet all requirements of the Email Equivalent profile except the following requirements
support AX requests for email
only return the email address that the logged in account receives over the open Internet via the IDP's SMTP service (and thus is equivalent to traditional email validation)
Email Hosting Profile
Use case: Some SaaS vendors host email for many domains, but not all of those domains will have published the necessary discovery information on their domain to advertise their chosen OpenID IDP. Some RPs will be willing to trust those SaaS vendors' claims that they run the IDP of a particular domain. Instead of each website identifying those IDPs, they would like a central neutral organization like OIX to maintain a list of IDPs who meet certain known requirements. The following profile lists those known requirements.
The IDP must meet all requirements of the Email Equivalent profile except that (1) discovery will be handled through statically published metadata by the hosting SaaS provider and (2) some domains will handle their own user authentication but they must have the ability to handle account recovery in-person or via a billing relationship with the user.