Federated Identities
Today's online identities are moving towards a "federated" model. A federated identity consists of information tied to a single account that multiple services may recognize. All identities (even federated ones) depend on two components: the authority that generates the identity and the authority that checks the identity. As an example, suppose that your identity consists of a Yahoo! username and password. When you create a Yahoo! account, Yahoo! is the generating authority. Thereafter, only Yahoo! can verify the authenticity of the identity. (You can argue that biometrics don't require identity generation, but at some point, an authority has to link the biometric signature with an identity. Otherwise, the biometric signature is just meaningless data.) When people think about federated identities, they usually think of OpenID, one of the oldest systems around. But some people may have the wrong idea about OpenID. It's not some sort of "decentralized" or "distributed" identification authority, as I've heard some people describe. So let me clarify one point: OpenID is not an authority; it's really just a standard way for sites to use federated identities from various centralized authorities (providers). Each OpenID provider generates and verifies its own identities. In other words, OpenID authentication ultimately requires a single, central authority. Consider the consequences if, say, Yahoo shuts down tomorrow. Well, all Yahoo! OpenID identities will disappear as well. You can't very well use a Google OpenID provider to authenticate your Yahoo! OpenID account. (Well, maybe if Google buys Yahoo!, they can choose to share user databases, but by then, they've become a single authority.) Now, the greater technology community loathes centralized power, which may be why many people want to believe that OpenID is decentralized. After all, critics often question the tremendous power of centralized organizations (such as Spamhaus and its control over the fate of mail). I also agree that centralized authority is usually a deal breaker. Unfortunately, while you can decentralize the use of your identity (by using it with multiple services), authentication must be centralized. At some point, some authority has to be able to declare that a particular identity belongs to you, and the only one who can really verify an identity is the one who created it, no matter how that authority delegates the final verification. Some people claim that other federated identities such as Google, PayPal, Facebook, and even CryoKey are somehow more centralized than OpenID. In reality, these authentication system are no more centralized than any particular OpenID authority/provider. They all provide federated identities and a single sign-on authentication flow, though outside of OpenID, the other authorities are fragmented and cumbersome. Furthermore, external authentication is normally just an option (unless a site actually chooses otherwise). In fact, blending multiple optional authentication systems is a great way to participate in a truly distributed authentication system. A truly "decentralized" or "distributed" authentication system can't rely on any one authority/provider, which rules out OpenID. In a "decentralized" authentication system, multiple authorities would be able to verify a single identity. But allowing multiple authorities to verify an identity just exposes the identity to more vulnerabilities. On the other hand, a "distributed" authentication system would require identification from multiple authorities. Think of the kinds of identification you must present when you get a job; you normally need at least two forms of ID, but you get to choose from a list of allowed identifying materials. The Internet equivalent would be requiring at least two accounts for identification from a list of maybe a dozen possible authorities. Anyway, most sites don't really care if authentication is "decentralized" or "distributed". Most sites only care about single sign-on, which is just one part in the larger world of federated identities. And users do welcome federated identities because they're tired of creating and managing their hopelessly overflowing closet of accounts, most of which they rarely use. Theoretically, federated identities would help reduce the sign-up barriers for new users and encourage repeat visits. I personally avoid creating new accounts because I don't want to add another account to my manifest, and if I can't remember a rarely-used account, I'd rather just avoid the site altogether than go through a forgotten password flow. Sadly, to date, most of the smaller and more casual sites haven't adopted the various single sign-on implementations because of the back-end complexity combined with the fragmented authorities. Higher security sites also avoid federated identities due to trust/security concerns. The gains are simply not worth the efforts, especially for smaller operations. We built CryoKey to address the limitations of existing single sign-on solutions, especially in cases such as limited network connectivity and multi-factor capabilities. CryoKey is very good at augmenting existing authentication, and fits in very well in truly distributed authentication systems. Services that need strong security can incorporate CryoKey without adding to the usability burden. And we're constantly making improvements to simplify integration with existing sites. As a bonus, CryoKey is also easier to embed into client applications (although these days, most applications have moved to the web, so client integration isn't as important now). CryoKey also has one fairly useful feature: it can generate identities for any domain without requiring any special "provider" implementation. As a result, any domain can now offer a federated identity. In contrast, other systems work only with specific domains. In the case of Google's federated login system, you could log in using any Google account, including accounts in domains managed under Google Apps. In OpenID's case, a site would need a complex "provider" implementation to recognize identities for their own domain. But what if you wanted to use external identities such as your hellokitty.com account? Yeah, CryoKey can do that - without any additional effort! Single sign-on solutions are currently very fragmented and difficult to integrate. Every provider has its own solution to meet its own agenda, which just pushes more complexity to the integration process. OpenID, though relatively popular, is no magic bullet either due to its own complexities and points of failure. But CryoKey is different because we are solely an identification service, so we don't have to confine our authentication model to meet other internal requirements. As a result, we can take the necessary steps to dramatically lower the barriers to using single sign-on authentication. CryoKey is an option that we hope everyone will consider if they're looking for a simple identification solution.
