Identity Matters

To continue the discussion of how security and trust seem to be taking shape for applications and services in mobile networks, let me explain in a little more detail about the infrastructure that is evolving, and how its component parts need to interact.

In order to deliver the examples described in the first part, network operators (I'll call them Telcos for convenience, but the world is changing and so are the players) generally want and need players of another type, the application service providers (ASPs), to step in and help to create the complete end-to-end service that a user experiences. By providing applications and services that run over the Telco's network, ASPs provide a valuable piece of the puzzle. This is because the level of demand, pace of development, and variety of possible services would strain even a Telco's resources if they tried to chase them all and develop them in-house, by themselves. But, in order to take advantage of ASPs as part of their services architecture, Telcos must expose their network infrastructure to these outside companies.

An ASP-Telco "symbiotic" relationship has the potential to create some truly interesting services, but it requires that each party take risks. For ASPs, the risk of innovation is pretty high - if they create something that nobody wants, it can be a total loss. And even if they have success, they need to be careful to protect their intellectual property. But, the ones that are successful can make money on a global scale through the power of a Telco channel, and the capital investment required for an ASP is modest compared to a network, so there is plenty of motivation for risk-taking. For Telcos, a rapid path to new service offerings with a big selection of potential ASP partners (therefore a big selection of innovative services) translates into maximum efficiency for investing their own resources. More important, it delivers the ultimate reward of an exciting network that attracts new subscribers, retains existing ones, and generates new traffic while also increasing existing voice and data volumes. In today's highly competitive environment, that's a path they simply must be on to ensure their survival.

What about that thorny issue of opening the network to “outsiders”? That, of course, is the major risk for Telcos. By doing this, they let others introduce components that could severely impact their traffic engineering or interfere with network management. But, the tools they already have are generally sufficient to maintain control of their network resources. The more unpredictable and unmanageable problem is security – and this doesn't just mean security for the Telco, but for any information flowing through the network.

In the type of infrastructure that we're heading for, where services are created through a mashup of applications and transports, the protection of sensitive information is a very complex issue. Sensitive information is a multi-dimensional problem in this environment because every party involved in the service transaction has some of their own at stake, and must respect some from the others.

For a Telco, the first task is protecting access to their network, which they have historically accomplished by being “restrictive”. In the new environment, maintaining an interface that appeals to a wide range of ASPs is critical to attracting them. That means letting them express their applications fully on the network without forcing them into major developments to match some unique API. At the same time, Telcos need to keep on ensuring the safety of information that they move about to protect the personal data and identities of their users.

ASPs, on the other hand, during their shorter history, have operated in a more open and collaborative environment than Telcos. Keeping their user information and identities secure has been something they've managed to accomplish while inter-operating with a wide variety of partners. But, they have enjoyed the freedom to manage their applications in a far less demanding and far more forgiving service environment than the infrastructure we're heading toward. Soon, minor issues they handled easily such as obsolete or redundant identity information in their user directory, or incomplete data and record update problems, become major problems in a global-scale service which is supported and branded by a Telco that demands a spotless image to make gains against their competitors. If they exposed customers to identity theft, massive spamming, or other scams through their service, they'd be responsible for a public relations disaster befalling their Telco partner which would seriously damage the relationship, not to mention their own public image.

In order for this architecture to work nicely, all the players need to be able to trust the others to do their part for security. They can see that that this requires a common set of standards that everyone embraces for these security functions, one that lets any ASP work with any Telco to create end-to-end services for any customer. Certainly vendor-specific standards could be used (and doubtless will be in some ways – more on that later), but a more flexible solution is an open standard that ensures ASPs and Telcos can inter-operate no matter what their platform choices. From our view so far, SAML 2.0 and ID-WSF are ideally suited for this, and are well positioned to become the solution of choice. These standards are a centerpiece of our identity management products, so a legitimate cry of favoritism is acknowledged, but in actuality this is not a heavily biased opinion. We support other standards, including vendor-specific ones, in Symlabs Federated Identity Suite, and this position is based on our work with all of them. It is a collection of our experiences in customer deployments, and perhaps more important in demonstrations and trials with the larger community of organizations seeking good real-world solutions that has led us to this viewpoint.

This is a good place to pause for now, but in the next (and last, I promise) part of this discussion I'll go into a bit more detail on how SAML 2.0 and ID-WSF standards can operate to everyone's benefit in this architecture.

Pablo Sánchez