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.