Phillip Hallam-Baker Verisign, Inc.

Whether you're just accessing a Web site, placing a phone call, watching TV or developing a Web service, sometime in the not too distant future, virtually all such transactions will converge around Internet protocols. Phillip Hallam-Baker, VeriSign's principal scientist, provides a unique glimpse of this future, explains how his company intends to capitalize on it, and turns David Berlind into a VeriSign believer.

Tech Update: How is being involved in the telco space a natural fit with your business?

PHB: On the Internet, we run the DNS infrastructure. If you want to go to Amazon.com, you'll come through our registry, and we turn Amazon.com into the IP address of the Amazon DNS server.

In the same way that our DNS infrastructure is a trusted service that guarantees you that you'll get to Amazon.com, there's an analogous layer in the telephone signaling system. Previously, when you dialed a number, the system would route you through the telephone network to the necessary exchange. With local number portability, wireless numbers, and 800 numbers, an entirely different set of infrastructures exist that need to have the capability of directing a phone number onto a physical wire, which can change.

Contrary to the way it was before, the line numbers are now actually separated from the physical lines to which they were once dedicated. This creates the need for a trusted service provider to guarantee, in the same way that the DNS works for the Internet, that when you dial a number, you're actually connected to the person you intended to reach in the first place.

If you dial 1-800-Flowers, you want to make sure that you get to the real 1-800-Flowers and, as you might imagine, 1-800-Flowers wants to make sure that when someone dials their number, it connects to them.

Tech Update: Are you saying it's possible to intercept that call now?

PHB: The guy who invented automatic telephone switching, Almon B. Strowger, was an undertaker in a small town. He invented automatic telephone dialing because one of his rivals had bribed the telephone operators to redirect all his incoming calls. So, people would call up Strowger, but the business would be stolen by a competitor.

Tech Update: Aren't laws in place to stop people from doing that today?

PHB: Sure, there are laws, but you need trusted, verifiable infrastructure. There are laws in place to deter to all sorts of security breaches, but most companies don't rely on the law to protect them from those breaches. They have to put their own measures in place to guarantee the continuity of their business.

Tech Update: So, similar to your digital certificate business, this gives parties on both ends of the line some peace of mind? A guarantee?

PHB: Absolutely.

Tech Update: Do companies like 1-800-Flowers pony up the money to get that level assurance?

PHB: Actually, that service is sold to the telephone companies. They outsource that switching task to us because we run one database and we serve multiple telephone companies. We run one database and share the cost amongst all the phone companies. It's the classic benefit of outsourcing.

Tech Update: So, if AT&T were still running the whole enchilada, this wouldn't be necessary because there'd only be one system and one database of numbers.

PHB: Right.

Tech Update: If everything is running over IP (Internet Protocol), nothing prevents me from becoming an entry point into the phone system for people running voice over IP. Already, people are sharing their IP connections with other people using wireless technologies like Bluetooth and 802.11. A person with the right Bluetooth-enabled phone is like a walking gateway into the infrastructure. How do you protect against that?

PHB: You've got the telephone system and the Internet. Merging the two is going to be real interesting. That's why we've got a foot in both camps, and we'll be there for when those two merge together down the road. There's also going to be convergence with the television system. People went bananas when they saw interactive TV. The Internet and the TV people have an affinity for each other, and it's the same with the telephone. Communications will be just like oxygen.

Tech Update: Switching gears to Web services, it seems like the little bit that's been done in Web services security (WS-Security), such as document encryption and digital signatures, just barely scratches the surface of the work that needs to be done for business to start relying on them. What security issues need to be addressed before Web services take off, and how far off is that?

PHB: There's always going to be a supply of new technologies. It's like the Golden Gate Bridge-they are always painting it. But you don't need to wait for them to start painting it in order to drive over it.

Web services is just machine-to-machine communication. People have been using the Web for machine-to-machine communication since 1993. I was doing it in 1993. That's why I was hired by CERN [the European Laboratory for Nuclear Research] to look into ways we could control pieces of our experiments with the Web.

The issue is, how much of it will be standardized, and how much will developers have to do for themselves? We're trying to do it in stages so that we produce a compact, focused work unit that the developers can use to solve a concise set of problems in a standardized way. WS-Security will have the same set of security services that you get when you have a secure multi-user operating system.

If you use something like VMS, one process can't stomp on another process. The same technology is in Unix and Windows NT and now, Apple with OS X. They've all got that basic protected memory technology and provide a series of security services so that when you do a subroutine call, you know what not to expect. With WS-Security, we're looking to provide the same set of guarantees.

Tech Update: When you say guarantees, are you saying that one Web services transaction won't stomp on another?

PHB: It means an attacker cannot come in and take a message from one transaction, and replay it a bit later, or take a message and modify it or just look at the traffic.

Tech Update: WS-Security seems like it will need to cover a lot of ground. What parts of WS-Security deal with these problems?

PHB: We have not yet decided on the scope of the WS-Security standards group that is a part of OASIS [Organization for the Advancement of Structured Information Standards]. Our first face-to-face meeting is next week, so I can't give you an exact scope just yet. When you get one of the development platforms for Web services like .NET, Apache, WebSphere, or something else that's Java-based, you'll eventually get a toolkit of security technology that you can apply to your applications.

However, technology is not enough for security. You also need to understand the security requirements of your particular application, and you need to have a trust infrastructure to make it work. If you're only doing Web services within one organization, then you can just put a wall around it. A firewall will work fine, but if you have one company's data center trying to talk to another company's data center, you're going to need more security. As soon as those bits leave your fortress and head into wild, you have to have some security en route.

Tech Update: Considering that these machine-to-machine communications need to be secured and you are having your first face-to-face meeting next week, what realistically is the timetable for getting these problems solved so that developers can secure those communications in a standard fashion?

PHB: Just to review what needs to be secured, the basic things to remember are C-I-A: confidentiality, integrity and access control. Web services security addresses the first two, and it interfaces to your access control through authentication and authorization mechanisms. Those mechanisms may be provided by your local machine or by a federated authentication system such as Liberty or Passport. With those basic pieces in place, you can then do Web services on the Internet and go beyond a single data center.

As far as timetables, we're having that first face-to-face meeting of the technical committee. With SAML [Security Assertion Markup Language], we had a similar setup and a very large initial meeting. It took 15 months to get the specification finished. In many ways, SAML is a more complicated specification. There were more choices to be made that had a significant impact on the final specification than with WS-Security. But, even with WS-Security a lot of design decisions have to be made.

Tech Update: Do those design decisions have to do with how specifications like SAML--specifications where the hard work has already been done--will snap into the WS-Security?

PHB: Essentially, the group is about making sure that they do snap in and everybody has agreed what specifications--like SAML, XRML, XKMS, XML Signature and Encryption--will be the ones to snap into WS-Security.

Tech Update: Will trust brokering always be required to deal with the "A" part-access control--of C-I-A?

PHB: You will always need trust brokering if you are going to do things on a large scale. You will always need direct trust too. If you decide not to use a trust broker, you are implicitly going to be setting up some form of direct trust with your partners. But, if you offload all your trust onto a broker, how do you trust that trust broker? That direct trust piece will have to be included, and you'll have to be able to set up those bilateral trust relationships at the very least with your trust broker.

If you want to do this promiscuous e-commerce, or if you want to have your supply chain integrated and working with any one of 10,000 suppliers (and some of our customers have ten thousand suppliers), you do not want to be in the business of authenticating 10,000 suppliers and keeping up with which ones of them are credit worthy licensed to trade, or have ISO 9000 certification

Tech Update: Back to the original question: In addition to brokering trust, will you bridge incompatible access control mechanisms?

PHB: I can't make any product announcements.

Tech Update: IBM and Microsoft have made it pretty clear that they'll rely on a company like yours to manage that part of the business.

PHB: Right. We already do that type of thing in our payments business. If a merchant takes credit cards, they may have a merchant account with one of the 10 or 20 merchant acquirers that exist in the U.S. at this point. Traditionally, that scenario has required a leased line and protocols that were developed 20 years ago. That kind of infrastructure is expensive to maintain.

We connect the merchants to their bank or merchant acquirer without having to connect to any of these upscale banking protocols, using TCP/IP, and it's a Web service. Maybe it's not using traditional Web service protocols like SOAP, but it is an HTTP transaction and down the road it will be in SOAP.

The big benefit of this "switch" for the merchant acquirer is that, in the same way he can connect up to one merchant through this switch, he can connect up to any of the others. For the merchant looking to connect to another merchant acquirer, the switching costs of replacing protocols and leased lines have suddenly vanished.

As a merchant, you can go to anyone of your suppliers and say "Ho ho, things have changed. Instead of it taking me three months to swap you out for another guy, it's only going to take me three minutes."

The pricing power goes to the merchant now. That's the type of thing that happens with Web services, and when you put things through an intermediary who can connect you to anyone of those suppliers. We do this in the area of payment and I can't give you additional product plans, but there are lots of opportunities for the same type of service in Web services.

Tech Update: Earlier, you mentioned other criteria, such as solvency and credit rating, that you would make available so that your customers could qualify customers.That sounds like you're getting into an entirely different layer of business service and information, going beyond determining whether someone can physically deliver what I need. Is this another aspect of the services you will provide?

PHB: At a high level, you just described a series of trust services, and we're in the business of providing trust services. I can't tell you which of those if any we would supply, but they're illustrative of the type of things that VeriSign could do.

Tech Update: Well, you brought them up as examples. Is it reasonable to say that they are areas that VeriSign is interested in?

PHB: Yes, we are interested in them.

Tech Update: Tell me about integrity. The "I" part in C-I-A.

PHB: You probably don't want your bank revealing your bank account details, but that's not the worst thing that can happen to you. Far worse is for the bank to cash a check for $5,000 on your account that you didn't write. That's an integrity attack and that's worse.

The integrity of the information itself and of the communications process, as well as the people at both ends of the transaction, are key. With respect to what's been published about WS-Security, some of those issues are being addressed already. But, it's really not without some complexities that will stretch out the finalization of a standard.

Tech Update: Going back to the question I asked earlier, to really get the bare minimum that minimizes the pain points for Web services developers so that they don't have to cook this stuff on their own, how long are we looking at in terms of time?

PHB: To get fully developed standards, you're probably looking at 12 to 18 months. However, you're going to see preliminary releases before that time. One of the other areas of focus is interoperability, and IBM and Microsoft are already showing WebSphere talking to .Net. We dropped our thing in, but we're not at the stage where we sell a software platform. It's more a specification.

Tech Update: Will these specifications be published and will they be royalty-free?

PHB: We'll put that into the standards process at some point. We've said that we'll publish the specification. You have to wait until WS-Security foundation is in place until you can start publishing more application layer standards.

Tech Update: Short of a published interface or API to put you in the middle, how are you doing that now if there's no spec?

PHB: We developed all the software internally. We have very high audit requirements and stringent controls on how someone interfaces with our systems, so we develop the software ourselves. We've put that out as a royalty-free binary release, and we'll release that as open source once we get our legal act in order.

Tech Update: What is that technology called?

PHB: The Trusted Service Integration Kit.

Tech Update: When you say that this will be open-sourced, are you saying that competitors will be able to launch services that are compatible with the API without an encumbrance?

PHB: If a customer wants to integrate with VeriSign services, they can use our kit. If they're application developers, they can integrate this into their applications.

Tech Update: If it's open-source, what's to prevent competitors from being compatible with it and offering a competing service based on the same spec?

PHB: At the moment, it's a binary release, and we said that we'd make it open source, but we haven't done that yet. Some of our competitors in the PKI space have software products and have tried to deploy them as a service to compete with our services. They have all discovered that there's more to doing a software service than just having the bits. There's a lot of complexity.

Tech Update: In other words, are you saying that if you publish a specification, you may very well end up being the best implementer of that spec? That's what the idea of complying with standards and competing on implementation is all about, isn't it?

PHB: Right. We're providing the power that people can plug into. People want to plug into the big network, not the small one.

Tech Update: One of the reasons to put your code into open source, though, is to get the imprimatur of a group like the Web Services Interoperability Organization (WS-I) or OASIS on the VeriSign way of doing things. Would that be beneficial to you?

PHB: First, the WS-I will have to specify what their imprimatur is and how to get it, and then we'll have to do work to obtain it. We've not yet announced the release. We've said we'll put it out there, though.

Tech Update: Does the binary release work with both Windows and Java?

PHB: It works with both, but it's written in Java. If you're working in the .Net Framework and you want to interface to our trust service or integrate that service into your application, you have to go to a third party. People have been saying that the place this code is useful is in the Java world.

Tech Update: But nothing prevents a developer from running the Java process next to a .Net process in a way that gives .Net the access it needs to the trust services.

PHB: No. That's one of the things that Web services are about. Anything should be able to talk to anything-it's all about communication. We don't have to re-implement everything to make it work.

Take CORBA [Common Object Request Broker Architecture], for example. They had this great technology, which by the way we have stolen blind.

We've taken idea after idea after idea from CORBA, and we learned from their bad ideas. When I joined CERN, I wasn't meant to be doing the Web.

I was supposed to be working with CORBA. In order to make CORBA work, you had to take all of your data off your legacy platform and put it into this standard new object broker system. That's nice, but the legacy system is a system that works and that you can depend upon. You shouldn't have to get rid of the old system.

Tech Update: You said people want to work with the biggest, plug into the big network for trust and other services. If VeriSign ends up in a position in which you are the intermediary that's bilaterally securing and coordinating relationships between all sorts of businesses, suppliers, and buyers, then you're also in a natural position to operate the biggest, baddest UDDI directory as well.

PHB: VeriSign has been involved in UDDI from the very beginning, and we're very interested in maintaining our leadership in the directory space. We understand that for Web services to succeed, there has to be a directory infrastructure. The challenge is that once you have a directory established, then people will see the value in it. Once DNS was established, people realized, "Hey, this is a very important infrastructure. I'd like to be doing it as well." But, before we got there, it took a lot of hard work. Getting from A to B is very hard. That's one of my jobs at VeriSign. The way I see it is that VeriSign is the leader in trust services, and they pay me and the people in my group to keep them in that leadership position in five to ten years time.

Tech Update: Before companies put Web services into production, they'll need to do a lot of quality assurance testing. To the extent that you certify downloadable code with Authenticode, won't businesses need similar digital certificates applied to Web services so that once they put inter-organization Web services into production, all parties involved know (for security, performance, and any other reason) that the production code hasn't changed since they last tested it? Is that another business for you?

PHB: The Authenticode system is designed to give a very specific level of security. When a user goes to the web and downloads software, they should get at least the same degree of assurance, as they do with shrink-wrapped software, as to the origin of that downloaded software.

Tech Update: Web-facing systems get hacked all the time. It seems as though this would be absolutely imperative to have a similar structure for Web Services, wouldn't it?

PHB: Maybe that type of assurance is something you'd want to see a secure UDDI directory providing.

Tech Update: The W3C is incredibly sensitive to all this Web services work taking place outside of the W3C. Do you think the W3C is becoming increasingly more irrelevant as these specifications are vetted in other forums?

PHB: Well, the SOAP 1.2 and WSDL 1.2 specifications--both of which are being worked on in the W3C--are absolutely fundamental to Web services.

Tech Update: But beyond that, the rest of the work is happening elsewhere.

PHB: What the W3C has been saying is that they have a certain amount of resources and they would rather concentrate on other standards as well than diffuse all over the place.

Tech Update: I've heard people complain about how W3C director Tim Berners-Lee is focusing the W3C's resources on the Semantic Web versus Web services and how that is a problem.

PHB: I'm very lucky at VeriSign because the company has committed an immense amount of resources to support my personal research. Tim arguably has at least as much right to say, "Hey, I've a right to go do research. Most of the Semantic Web work is funded by Advanced Research Projects Agency (ARPA). The Semantic Web is a large part of what they do, and it's a very interesting, compelling vision of what the Web can be. At corporations like VeriSign we're focused largely on what happens in the next year. But, one thing that is different about VeriSign is that we are also focused on what's happening in ten years. We're very interested in the Semantic Web, but its potential is not going to be filling the balance sheets of companies with a short term vision in this quarter or the next quarter.