Notes from April 2010 OpenID Summit discussion on Certification/Whitelisting
IDP Whitelist
- One IDP chosen by RP (Website that extends the APIs of one provider like Twitter/FB/orkut/etc. OpenID used internally or to federate with tight partners.)
- <6 IDPs chosen by RP (RPX UI w/o advanced OpenID box, EasyHybrid for FB+Twitter who support the protocol)
- Large whitelist maintained by external organization such as OIX
- No whitelist
IDP Certification Profiles/Use-Cases
- US government citizen logins LOA1 (no PII)
- ...extending to LOA2/3/4
- Synchronous Email validation (simpler protocol like EasyHybrid, simple UI is a requirement, Email hint is an open question)
- What would Google and Yahoo and Facebook require from Email based IDPs to "not confuse exsting half a billion users"? (see Allen Tom's preso)
- E-Commerce transactions for purchasers (little to no PCI requirements for authentication) - anything more then what G/Y/F need?
- E-Commerce administrator accounts with CC# access (strict PCI requirements for authentication) - very similar to LOA3?
- Account recovery of Email by non Email provider (bank, credit card company, cellular provider, etc.)
- Synchronous mobile phone # validation (as opposed to sending SMS messages or phone calls)
- "drivers license" type data validation (less protocol, more a matter of how IDP validates that information)
RP Whitelist/Certification
- none
- small RP list, such as for OpenID used internally
- pre-registration by RPs, similar to registered OAuth
- RP certification, such as PCI compliance, before they can access some OAuth feeds like CC#
CHECKLIST OPEN DISCUSSION
#1: Synchronous Email validation (simpler protocol like EasyHybrid, simple UI is a requirement, Email hint is an open question)
Same as #2 minus the second (and future) time login requirements
#2: What would Google require from Email based IDPs to "not confuse exsting half a billion users"? (see Allen Tom's preso)
IDP should pass the OIX ICAM profile except that need for per-RP IDs is not required
One specific requirement is that the IDP's authentication scheme must be at least as strong as the OpenID best practices for the OIX ICAM profile
UPTIME
IDP needs to provide 99.?% uptime for its federation feature
USABILITY
The IDP consent flow must have an average approval rate of 8/9?% - what is average for out-of-band verification?
If user is already logged into IDP, there should be at most one page in 99.?% of the cases
The one consent page should follow an industry standard for simplicity
The RP must be able to request a consent page and protocol flow that is friendly for mobile devices and non-JS browsers
The RP should be able to provide visual branding to be shown on IDP consent page
The RP should be able to request that their TOS be displayed on the IDP consent page
The IDP must return a global, unchanging and non-recycled identifier for the account
The IDP should support a more flexible realm match for RPs to leverage the auto-approval login feature
EMAIL VERIFICATION
The IDP must 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)
Crazy IDPs who let users who have dots in their email address, or "+" following by anything should be shot -- ?? but how do deal with it?
The IDP should allow the RP to pass the user's email address as a hint -- ?? but how should it be used
The IDP should allow the RP to pass the user's email address as a requirement -- ?? but what if user fat-fingered it?
ATTRIBUTES
The IDP should return a flag if it is highly confident the account is owned by a real person as defined by some future best practices. For example the person is paying the IDP for services, or has verified ownership of a phone# and/or credit card # that is not associated with a large number of other accounts.
The IDP should return the first&last name/nickname/age/birthdate/gender/location if those attributes are known for the logged in account
FUTURE LOGINS
The IDP must default to auto-approving future logins by this user to the same RP with an acceptance rate of 9?%
The IDP should support a mechanism that enables an RP to detect if a user is logged into the IDP, and if the user has previously agreed to automatically log into the site (checkid_immediate/hassession)
The IDP must support reauthentication requests by the RP, i.e. password re-prompting
The IDP should publish a URL that will start a flow to change the user's authentication mechanism (like changing their password)
The IDP should provide an API that the RP can use to detect if an account from the IDP has been deactivated or has changed their email address or has recently changed their authentication mechanism (like changing their password)
CONTRACT
The IDP & RP should not require a pairwise legal contract, but should instead rely on the IDP being certified as meeting these requirements
The IDP should NOT require pre-registration by the RP.
The RP should NOT require the IDP to accept any liability for individual assertions, but should instead report problems to the IDP's certifier
The IDP must support one of the following protocol/versions - openid???, saml???, oauth2 EasyHybrid profile