Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
OpenID identity provider as a relying party
(2007/2/28)
Eran Sandler writes in "OpenID Vendor Lock-in (sort of)" that
"Sites should support the ability to associate multiple OpenID identities so that a user can add, remove and switch the identity used to access a certain account in a certain site."
and
"Until we reach to that point (and it will take time) [that people can get an account without fearing vendor lock in] I think we should allow the users to have all the necessary freedom in choosing which OpenID provider they want to use and enable them to quickly and effectively switch (or migrate in the case of accounts that are not OpenID enabled) without too much hassle."
Those statements are controversial, for since OpenID allows an individual to maintain their own authentication (and in the future attribute) account at a identity provider separate from any particular relying party site, some people hold an opinion that
(A) an individual should only need to use one OpenID identity with their stub-account at a particular relying party
and some people hold a more extreme position that
(B) an individual should only need one OpenID identity for their Internet transactions
whereas others take the opposite view
(C) an individual should be able to use a multitude of OpenIDs, disposable vs permanent, linked vs distinct, etc.
I'd assume that people holding position (B) predict that either OpenID will have a wide-open trust model (as most RPs do today), or that there will only be a few, widely adopted, OpenID identity providers. Yet, (as I wondered earlier this month), if the OpenID protocols were to become successful in the enterprise context for intranet authentication and federated authentication, then there is a possibility that many individuals will have at a minimum both a 'personal' and a 'work' OpenID URI.
In a selection of eight public identity providers from the list of those supporting OpenID, their signup pages required users creating a new account to supply:
| OpenID Identity Provider | Username | Password | Email address | Solve Captcha | Other |
|---|---|---|---|---|---|
| OP #1 | Y | Y | Y | Y | |
| OP #2 | Y | Y | N | Y | |
| OP #3 | Y | Y | Y | Y | display name |
| OP #4 | Y | Y | Y | Y | display name first and last name |
| OP #5 | Y | Y | Y | Y | |
| OP #6 | Y | Y | Y | N | display name |
| OP #7 | Y | Y | Y | N | first and last name home phone and address secret question and answer |
| idproxy.net | N | N | N | N | Yahoo ID |
One OpenID identity provider, idproxy.net, generates an OpenID for users with a Yahoo account, but all the rest of the surveyed providers encourage you to sign up and provide a username and password.
Shouldn't an OpenID identity provider allow a user to provide an OpenID (from another OpenID identity provider) when creating an account, so the user doesn't have to maintain yet another copy of their username and password?
On the surface this might seem a strange question, why should a identity provider also be a relying party? Since these seven OpenID identity providers assume that a user does not already have an OpenID or would not want to use their existing OpenID to manage another OpenID, this suggests one or both of the following assumptions might have been made by the organizations running the OpenID providers:
- OpenID is still in its early days and users won't have gotten any OpenIDs yet
But what about the AOL announcement? What will happen when Yahoo, Amazon, eBay and other major Internet sites also implement responders for incoming OpenID requests and their user communities suddenly become OpenID-enabled? Will the pioneer identity providers fade away?
- all OpenID OPs provide roughly equivalent service
For OpenID 1.x this might be the case, but for 2.x with attribute exchange, each provider might implement a different set of attributes. They might also use different authentication levels and techniques: a user might want to have one OpenID provider be their primary provider, but might not be able to meet that provider's authentication requirements while travelling due to a need to use a less-capable laptop, internet-enabled PDA or internet kiosk. And some identity providers might be forever tied to a particular service beyond merely identity, if for example a bank becomes an identity provider for its customers.
Beyond merely meeting the OpenID goal of reducing the number of username-and-password-requiring-sites that a user must maintain, another reason to have an OpenID identity provider itself support using OpenIDs is suggested in a quote from Mike Neuenschwander I mentioned earlier this month:
"In the interest of promoting relational continuity, the more authenticated connections the better - particularly if the user can parlay these authentications into improved reputation."
For this to work, the relying party needing the reputation also needs to join the user's identity representations across each identity provider, and have confidence that the representations are equatable. This will be challenging, but one way to start the process going is
- for identity providers to be able to trust other identity providers,
- for identity providers to be able to link a user's account in one identity provider to their account in another identity provider, and
- for identity providers to be able to differentiate their service or 'value add' and describe to a RP what they provide, beyond merely storing a user's self-asserted attributes