OpenID and its Implications
My ISP started some services that implement the OpenID specification. Of course I was interested, because I am always curious about the evolution of security measures and what problems they are trying to solve. OpenID is a distributed identification validation framework. It is designed to address problems of scale and usability while still providing a measure of security.
First, let's explore the evolution of how we get to where people think OpenID is needed. We started with every web service from message boards to image sharing sites having their own credentials. In essence every site had to be their own identity provider, but there wasn't a problem of trust because if you can't trust yourself, how can you trust anyone else. This provided a problem for users. They had to remember the user name and passwords for dozens of sites. Sometimes the user name had to be an email address, and other times it could not be an email address, etc. The next idea was the Single Sign On (SSO) approach, where if a site trusted the SSO provider, they could use those validated credentials for itself. The problem here was one of scale. First, there were several large resources that had the same idea such as Yahoo! and Google. Of course, Yahoo! won't trust Google and Google won't trust Yahoo!. Again, the user still had to remember several user names and passwords--but there were fewer of them to remember. If only there was a way to have one place to manage my credentials and use them on every site....
This is the problem that OpenID is trying to solve. With OpenID, you have a URI as your identifier. You can use this same URI on every OpenID enabled site. You can turn any HTML document into your identity by adding a couple <link> entries in your HTML header. The concept is to put the user in control of their own identity, and manage it themselves. In the words of my son, "Shamazing!" The link entries point the consumer (i.e. blogging software, client management software, etc.) to the identity provider (the ID server) so that it can validate whether that ID is owned by you. That means that in order to know who it is that is giving a comment, you only need to require the OpenID and all the rest is taken care of by you.
Now, there is an important distinction to make. Even though OpenID says it is an authentication framework, it does not authenticate! It validates your OpenID, not performs user authentication. Huh? How can they call it an authentication framework? The spec leaves the method of authentication up to your ID provider. It might require a user name/password combination like everything else, or it might use a stronger public key infrastructure, or it might not use anything at all. It's up to the ID provider to choose the method and strength of authentication. The OpenID specification does due diligence to ensure that you aren't going to be intercepted by a man in the middle attack, so the only problem left is whether you trust the ID provider or not. OpenID will only validate that an ID provider recognizes that the URI you provided belongs to you, not whether the ID provider is trustworthy.
What good is it then? It does provide a mechanism to manage the URIs that people use. The consumer software (i.e. your blog provider, etc.) can choose whether or not it accepts/trusts URIs that are guaranteed by a particular ID provider. It also can choose to trust or deny trust to individual accounts. That means that mean spirited trolls can be dealt with, and it means that known spammer ID providers can be outright ignored. It might be important to note that many spammers use a host of DNS names, so it might have what looks like a hundred ID providers even though it is served up by the same server. It might be best to look at the IP addresses when denying spammers.
Honestly, I believe OpenID provides some good benefit to the world in general. First, it puts ID management where it belongs--in the user's hands. Second, it does away with the SSO pissing contests by recognizing that a single authentication system cannot scale to meet the demands of the insanely large user populace. Lastly, it provides one thing for a user to remember to use their identity wherever they want. It allows corporations to manage their own identities while participating in cooperative development projects.
There are additional extensions to the base OpenID spec to allow a consumer site to find out more information about the identity of someone. Here's the kicker: the user doesn't have to share the information if they don't want to. The user is in control of whether they allows a site to consume their email address or not. If the consumer app requests information the user is sensitive about, the ID provider will ask the user if they want to share the requested information with the site or not. Of course the consumer site is allowed to reject comments and such if the information isn't shared, but the user is ultimately in control of their own identity.
Technorati Tags: openid identity architecture
First, let's explore the evolution of how we get to where people think OpenID is needed. We started with every web service from message boards to image sharing sites having their own credentials. In essence every site had to be their own identity provider, but there wasn't a problem of trust because if you can't trust yourself, how can you trust anyone else. This provided a problem for users. They had to remember the user name and passwords for dozens of sites. Sometimes the user name had to be an email address, and other times it could not be an email address, etc. The next idea was the Single Sign On (SSO) approach, where if a site trusted the SSO provider, they could use those validated credentials for itself. The problem here was one of scale. First, there were several large resources that had the same idea such as Yahoo! and Google. Of course, Yahoo! won't trust Google and Google won't trust Yahoo!. Again, the user still had to remember several user names and passwords--but there were fewer of them to remember. If only there was a way to have one place to manage my credentials and use them on every site....
This is the problem that OpenID is trying to solve. With OpenID, you have a URI as your identifier. You can use this same URI on every OpenID enabled site. You can turn any HTML document into your identity by adding a couple <link> entries in your HTML header. The concept is to put the user in control of their own identity, and manage it themselves. In the words of my son, "Shamazing!" The link entries point the consumer (i.e. blogging software, client management software, etc.) to the identity provider (the ID server) so that it can validate whether that ID is owned by you. That means that in order to know who it is that is giving a comment, you only need to require the OpenID and all the rest is taken care of by you.
Now, there is an important distinction to make. Even though OpenID says it is an authentication framework, it does not authenticate! It validates your OpenID, not performs user authentication. Huh? How can they call it an authentication framework? The spec leaves the method of authentication up to your ID provider. It might require a user name/password combination like everything else, or it might use a stronger public key infrastructure, or it might not use anything at all. It's up to the ID provider to choose the method and strength of authentication. The OpenID specification does due diligence to ensure that you aren't going to be intercepted by a man in the middle attack, so the only problem left is whether you trust the ID provider or not. OpenID will only validate that an ID provider recognizes that the URI you provided belongs to you, not whether the ID provider is trustworthy.
What good is it then? It does provide a mechanism to manage the URIs that people use. The consumer software (i.e. your blog provider, etc.) can choose whether or not it accepts/trusts URIs that are guaranteed by a particular ID provider. It also can choose to trust or deny trust to individual accounts. That means that mean spirited trolls can be dealt with, and it means that known spammer ID providers can be outright ignored. It might be important to note that many spammers use a host of DNS names, so it might have what looks like a hundred ID providers even though it is served up by the same server. It might be best to look at the IP addresses when denying spammers.
Honestly, I believe OpenID provides some good benefit to the world in general. First, it puts ID management where it belongs--in the user's hands. Second, it does away with the SSO pissing contests by recognizing that a single authentication system cannot scale to meet the demands of the insanely large user populace. Lastly, it provides one thing for a user to remember to use their identity wherever they want. It allows corporations to manage their own identities while participating in cooperative development projects.
There are additional extensions to the base OpenID spec to allow a consumer site to find out more information about the identity of someone. Here's the kicker: the user doesn't have to share the information if they don't want to. The user is in control of whether they allows a site to consume their email address or not. If the consumer app requests information the user is sensitive about, the ID provider will ask the user if they want to share the requested information with the site or not. Of course the consumer site is allowed to reject comments and such if the information isn't shared, but the user is ultimately in control of their own identity.
Technorati Tags: openid identity architecture
