This Internet fix is no pipe dream

Some people may think me a total whack job, but I think I have a serious plan for making the Internet secure. And it’s not a pipe dream. The Internet can be made significantly safer starting today.

In May of last year, I published my thoughts on how to save the Internet in a whitepaper [PDF] and a series of Security Adviser posts, including “Fixing the Internet” and “Defending ‘Fixing the Internet’.” At the time I believed that it would take a bunch of new protocols to begin to pull off my vision, and I still believe that, at least for the full vision.

[ Did Roger finally get it right? Or should he have stuck to his earlier theories in “Fixing the Internet” and “Defending ‘Fixing the Internet’“? Check them out and comment below. ]

However, I did a disservice by not discussing the protocols and standards that already exist today, particularly a number of relatively new security protocols that are already helping to make the Internet a safer place. Created by many, many experts, these protocols aren’t pie-in-the-sky dreams, but have already emerged as de facto standards. Any future Internet-based security system will likely use them, and perhaps contain all of them.

These are some of the protocols that are helping to build a more secure Internet:

Simple Object Access Protocol (SOAP) is a platform independent, XML-based protocol for sending messages (that is, data) between Web services and participating networks. If HTTP is the circulatory system, SOAP messages are the red blood cells.

Security Assertion Markup Language (SAML) is an XML-based standard for communicating identity, authentication, and authorization information between security domains. SAML 2.0 is quickly being accepted and adopted by most major players.

Web Services specifications and extensions (WS-*) are various (often unrelated) messaging standards related to Web services and frequently surrounding the security of Web services. The Web Services (WS) specifications themselves deal with how various applications and computers can successfully and reliably communicate over untrusted networks such as the Internet.

WS-Security is a general-use communications protocol covering security specifications as applied to Web services. It discusses how to ensure confidentiality and integrity across the Web. WS-Security uses SOAP messages to ensure end-to-end security at the application layer.

WS-Federation incorporates the mechanisms and protocols to allow unrelated security domains to securely communicate identity and authentication information. This standard enables separate authentication domains to communicate, creating the foundation for larger realms of trust across ever larger security domains, perhaps global in scope. WS-Federation is a big deal.

WS-Trust is a Web service specification dealing with identity/authentication security tokens. It covers provisioning, de-provisioning, renewing, and validating participating tokens. Used with WS-Federation, WS-Trust allows applications in different security domains to broker trust relationships between entities that might otherwise have a hard time doing so.

Security Token Service (STS) is a Web service that issues security tokens as defined in the WS-Security and WS-Trust specifications. Any authentication provider that issues security tokens can be considered a STS if it conforms to some general principals as described in the specification.

OpenID is a decentralized way to exchange identity/authentication tokens between the provider and consumer of a Web service. It can manage and protect multiple types of authentication, including passwords, digital certificates, and two-factor security tokens. A single user can have multiple OpenID credentials and submit the appropriate one when requested. Supported by many of the world’s largest vendors, OpenID is expected to become a de facto Web browser standard in the near future. Microsoft recently announced that its CardSpace implementation (in Windows XP Pro and later) and Windows Live IDs already conform to the OpenID specification.

Putting it all together

Essentially all these open standard protocols and specifications will allow huge, interconnected identity and authentication systems to be created between multiple, disparate parties. In relation to cloud services, these standards are often the way you will connect to them. Cloud services allow services and servers to be “matrixed” via the Internet. The specifications mentioned above allow the identity and authentication services necessary to connect to cloud services to be “clouded” themselves.

You will be able to get one or more security tokens from one or more authentication providers and use them as you see fit. Each security token can have one or more claims. A claim is any information attribute associated with a particular identity. A claim could be a real name, a date of birth, a statement that you are over 21 years old — anything. For any particular identity, you can supply as much information as you like, or no more than required, for a particular service. You might remain completely anonymous or go pseudo-anonymous.

Pseudo-anonymity allows you to stay anonymous (that is, not reveal your true identity) by using another identity to which a trusted third party attests. You could remain anonymous to a particular service as long as the service provider accepts the third party’s attestation. For example, in most parts of the United States you have to be 21 years or older to buy alcohol. When you buy alcohol, the store doesn’t care about your name or address (which is on your license); it only cares that the ID you are showing is truly yours and that you are older than 21. A pseudo-anonymous online ID might confirm that you are over 21 without revealing any other information about you, so you can buy alcohol over the Internet. What a great world it would be where you could reveal no more and no less about yourself than the information necessary to complete the transaction.

All of these new specifications and standards will allow us to build huge identity metasystems, where many disparate identity/authentication systems can be connected to create large circles of trust. These trust networks will include not only banks, manufacturers, and retailers, but also huge cloud services, including competing service providers, all of whom will be able to vouch (to varying degrees) for their users.

The upshot is that the boundaries created by the fact that every commercial Internet service today has its own, isolated authentication system will be removed. The user of one cloud service will be able to move seamlessly to another. An individual company will be able to offer a service to the cloud, and get different users from different clouds to their service. Even national identity systems, now separate, will be connected with each other and with the cloud. The Internet will be both more secure and more useful.

Yes, this vision has a way to go, but the protocols are already in place and in use by vendors who are already working on products that support this proposal. This is not a pipe dream. It is the culmination of decades of work on identity management, and it will be coming to a Web near you in the not so distant future.

I’ve updated my “Fix the Internet” paper (now in version 2.0) to reflect the role of these existing protocols and to offer a simpler alternative solution (called Solution No. 2) that can be implemented today without the need for any new protocols. You can download the updated draft here. Save the Internet!