XML.com: XML From the Inside Out
oreilly.comSafari Bookshelf.Conferences.


From P2P to Web Services: Addressing and Coordination
by Andy Oram | Pages: 1, 2


The problem with the Web is that it offers too many choices. Things have grown increasingly complex since 1991, after all. A key change is that XHTML documents now often rely on third party resources -- for example, W3C specifications and DTDs -- to tell browsers what to do. The rendering process becomes much more complicated by bringing in a third party.

And HTML is just the start of our coordination problems. XML and web services have opened up the opportunity for a great many languages and application-specific vocabularies, forcing sites to work at finding agreement on what language they're speaking.

P2P Solutions

The P2P movement proved to be a good environment for the intense exploration of coordination issues. P2P application developers had to invent new kinds of coordination from scratch. As always happens when new opportunities are recognized, a period of chaos followed where everybody went off inventing her own way of achieving her goals. The P2P movement never moved beyond this period of chaos. The developers failed to coalesce around either a Peer-to-Peer Working Group led by Intel or the JXTA [http://www.jxta.org/] protocols introduced by Sun.

Another form of coordination that occupied a lot of people's attention was the problem of classifying or typing resources. Such classification was central to many P2P applications because end-users were responsible for contributing data, and no one could compare, tally, or even find the data unless some common system of metadata was offered. Web services depend on classifications done by many standards organizations, as we'll see. That's part of the social infrastructure that supports them.


So let's turn to a technology where the problem of coordination gets really complicated, one of the most heralded advances in web services, heavily promoted by Sun and other companies in the Liberty Alliance: the Security Assertion Markup Language (SAML). The key word here is "assertion". The assertion is the unit of data that allows coordination.

SAML allows a client and server to appeal to a third party for any kind of access decision. For instance, as shown in Figure AUTHENT-ASSERTION, a user's browser sends a digital signature to the site where the user wants to do business. The server at this business site, which in SAML is called the destination, sends the signature to a trusted third party that knows everybody and their digital signatures.

This server, known as a SAML authority, sends back an XML-encoded statement called an authentication assertion, which might look like:

This person is Ellen Radolfsky.

In this simple use of SAML, the server and client depend on a third party for signature verification. This requires a much more developed social infrastructure, even aside from the issues of trust. The business server has to set up a contract with the authority to check signatures. And Ellen Radolfsky has to contact the authority to prove her identity and get a signature.

Documents about SAML don't say much about all this activity, nor do talks I've heard on SAML, but Section 4.1 of SAML's Bindings and Profiles specification makes an oblique reference to this activity by admitting that the specification makes the following assumption.

The user...has authenticated to a source site by some means outside the scope of SAML.

If you read specifications for technologies you're considering, you have to look very carefully for passages like this one. "Outside the scope" means "this is really important but we're not doing it for you." Nor do I think SAML should do this. Kerberos has been used for decades to authenticate users and servers. It's proven itself over and over, it's been incorporated into Microsoft's domain technology, it will reportedly become the authentication component used by Microsoft's Passport service, and it deserves to be extended to web services. SAML makes that possible, but it doesn't remove the responsibility from people to set up the social infrastructure that makes authentication work. Vendors may give you the impression you can install a product that understands SAML, put a couple programmers to work developing applications, and enjoy their benefits; but the organization has a lot more work to do.

Coordination gets even more complicated as we explore the SAML specification further. The authentication assertion is only one of three types defined in the SAML specification. Next there's an authorization decision assertion, which might be something like:

This person can view our company's financial plans.

Even more coordination is needed for an authorization decision assertion than for the authentication assertion. The coordination you need to enable an authorization decision assertion includes making a list of sensitive operations, as well as defining your own protocol so your destination site and your authority know what they're talking about. This simple and useful assertion can't become a resource for web sites until someone who's maintaining the destination site says, "I have some sensitive financial plans to protect" and the authority agrees to starts tracking who has a right to see financial plans. The assertion can only be implemented as a result of lots of meetings between people representing the two organizations.

Finally, we have the attribute assertion. Attributes have been a product feature for years, perhaps stored in directories such as Active Directory to represent information such as contact information and job titles. The attribute assertion allows any kind of such directory information to be made available to web services through SAML. But because of its open-ended flexibility, an attribute assertion could also be something like this:

This person calls customer service a lot.

I made this example up. But its appearance in corporate databases would be quite plausible. Companies are increasingly aware of customer service costs and are putting systems in place to warn their employees about high-maintenance customers, as well as customers who should be favored because they provide high profits. Already IBM's Autonomic Computing vision explicitly includes the provision of customer service with relatively better or worse response time to different classes of customers. I firmly expect that authentication and authorization services such as SAML will be pressed into the service of discriminating among customers.

And this leaves us with the social question of whether we want automated decisions being made that affect individuals' lives in potentially major ways. Such questions are not the focus of this article. But if we discuss social infrastructure, we should be aware of social questions concerning that infrastructure. Security standards that use attributes, such as SAML and the open Shibboleth project , associated with Internet2, speak earnestly and probably with sincerity about the importance of preserving privacy. But the key lies in what information is stored by sites using the standards, and how these sites design the information's use.

When I hear talks or read papers about SAML, and many other current standards, I think of the changing of the guard, which you can see at Buckingham Palace in London, the Houses of Parliament in Ottawa, and a few other places. When you watch the changing of the guard, you are impressed by the precision marching, the excellence of the brass band, the crisp swordplay. It's easy to think that the purpose of the guard is to carry on this show for you. But the true purpose of the guard is to protect the Houses of Parliament or wherever else they are deployed, a serious task in these days of terrorism. When evaluating the guard, you have to look beyond the display.

Similarly, when we consider the infrastructure you need to make web services security work, SAML is the brass band, the swordplay. Doing it right is important because vulnerabilities at any point are dangerous. But the real work is being done behind the scenes by Kerberos, by the authority that manages people's identities or authorizations, and by the relationship that you and your clients maintain with this authority.

SAML's achievement is to make web services, with all the interoperable benefits and standards they bring, available to carry out organizational relationships that are well-established, well-formalized, and tightly integrated. But how many organizations have relationships that are sufficiently well-established, well-formalized, and tightly integrated? Creating these relationships is where they have to focus their efforts if they plan on deploying SAML. In other words, potential partners need to get their social infrastructures in tune before they can benefit from SAML. I believe this is part of what some consultants call "enterprise readiness" for web services.

The basic third-party authentication model in SAML is probably robust, because it's an extension of what people currently do in everyday computing environments. Lots of sites are parts of Microsoft domains or other networks that allow single sign-on. But for any application, SAML requires a vast amount of social infrastructure.

UDDI and ebXML

UDDI and ebXML have, arguably, even more ambitious goals than SAML, and they have correspondingly greater requirements for social infrastructure. The goal of these specifications is to streamline and automate commerce, so that you can search for a product or service, negotiate terms, and conclude the deal in a structured way over the Internet. A business needing a certain part for a machine could start up a web service request asking who has parts of a particular size and composition; the web service could then choose a part based on cost, geographical location, or some combination of other criteria and even contact the lucky vendor directly. You could even tell the registry: "Here's a business I know of; find other businesses like it" and then choose one with which to carry out a transaction.

The standards attempting to provide this service are UDDI (Universal Description, Discovery, and Integration) and ebXML. They were invented independently by different consortiums and never managed to converge. Because the data they maintain and the relationships among businesses they promote are subtly different, merger may not be desirable. UDDI is developed under the auspices of OASIS, which also takes responsibility for most ebXML components.

I haven't heard much about UDDI recently. ebXML, by contrast, is reported to be growing in use. It's made the biggest inroads in South Korea, where large businesses push it, supported by the government there. Let's take a look at each standard and the social infrastructure it assumes.

About some pieces of information, UDDI is quite explicit and specific. It provides fields where a business can offer its address, phone number, email contact, and so forth. But what about the criteria you search for? UDDI doesn't specify that, and there's no reason for it to do so. It relies on existing specifications in the outside world. For instance, there is an official U.S. government standard that classifies every type of business in North America; it's called the North American Industry Classification System (NAICS). Individual products are also specified through the United Nations Standard Products and Services Code (UNSPSC).

These standards make it convenient to find the cheapest source for commodities such as pen refillers (an example I took from the UNSPSC site). For something more nuanced or less commoditized, more information may be required. UDDI provides a field called a tModel that has an open-ended definition, where any kind of information can be stored. But for the tModel to be useful, the companies using it have to come together, agree on categories, and classify their products reliably.

Both UDDI and the ebXML frameworks have ambitions far beyond a virtual yellow pages. UDDI provides pointers to web services, with the notion that after you find a company you want to deal with, your computer application can form a relationship without human intervention.

The parts of the transaction that take place after a successful search are handled in ebXML by a Collaboration Protocol Profile (CPP) and a Collaboration Protocol Agreement (CPA). This can be considered a standardization of Electronic Data Interchange (EDI). The vendor offers a Collaboration Protocol Profile, in response to which the buyer offers a Collaboration Protocol Agreement that is supposed to conform to the profile. Together they allow purchasers and vendors to automate parts of their activity.

The work of developing a Collaboration Protocol Profile is enormous. It can be created by a consortium of vendors, created by a major customer and imposed on vendors, or developed by committee in some other manner. In any case, it's a masterpiece of human coordination. And the Collaboration Protocol Profile is as much a legal document as a technical one.

This brings us to the third issue, trust, which I will discuss in the next article.