From P2P to Web Services: Trust
by Andy Oram
|
Pages: 1, 2
State-of-the-art Specifications
Liberty Alliance documents talk about circles of trust, where organizations and people in the inner circle are entrusted with more activities than those in outer circles. This is subtly differently from the web of trust. The web of trust is restricted to signature verification; a circle of trust covers potentially any online transaction and recognizes that users trust different parties to different extents.
I feel a bit queasy about automating trust relationships, even when relationships among organizations are strong and long-lasting. Manual interactions create many barriers to subversion that automated processes strip away. You might not pay much attention if another site is sending your system a message telling you to trust a transaction that's worth just five dollars. You might not realize that your system has received 10,000 similar requests for five dollars in the past fifteen minutes. Vigilance is called for.
I support the concepts behind SAML up to this point; it allows a trusted third party to do single sign-on. But it goes much further, and I expect we'll wait a long time before we see sites implement it for these larger purposes. As I pointed out, the social infrastructure required to implement authorization decisions or attributes is much greater than the tried-and-true Kerberos style of authentication. And SAML doesn't stop with trusted third parties either. It adds fourth parties, fifth parties, etc. Extending the trust model is part of their vision they call federated commerce.
In federated commerce scenarios, coordination and trust problems mushroom. Web services depend on good business practices that all these different companies can follow. Technology can help to encode the practices, but technology cannot create or enforce them, only people can. And the buyer has to trust all the companies in the chain. As Scott Berinato wrote in The State of IT Security 2003, "When you connect your network with a partner, you're also connecting to your partner's partners. Yet only 22 percent of respondents demand that partners practice safe business."
A system where two users have no pre-existing relationship or agreement, but depend upon agreements they've worked out with a third party, is called brokered or indirect trust in Liberty Alliance specifications. A system where a user enters into a negotiation with someone she doesn't know, but who is part of a general class of businesses such as hotels, is called community trust. The latter is also basically a form of dependence on a trusted third party, but the trusted third party is whoever let the hotel into the community.
Future Trends
Trust and information sharing between companies have taken place since commerce began. But the speed and ease of communication nowadays are putting a lot of strain on traditional corporate boundaries. When setting up an extranet or even a mailing list, whom should be invited to join? How much should be shared on the forum?
Standards bodies are recognizing these problems, and in recent months they've been taking steps to inform businesses about the risks of partnerships, educate them about what they should do to protect themselves and their partners, and create new specifications that start to take the social infrastructure into account.
I'll start by briefly mentioning a new stack of protocols driven largely by Microsoft, IBM, and VeriSign: WS-Security, WS-Policy, WS-Trust, WS-Privacy, WS-SecureConversation, WS-Federation, WS-Authorization.
These standards, most of them in early discussion phases, strive to tame the issue I've been complaining about: trust and its delegation. The driving forces behind them are Microsoft, IBM, and VeriSign; the first one, WS-Security, has been submitted to OASIS for approval. If we build real-world trust relationships that are strong enough to be formalized, these standards may help web services exploit that achievement. But in the meanwhile they're just piling on more and more in a complicated series of complicated specifications.
To show a contrasting direction, I'll mention some intriguing explorations in the area of trust to which I've been alerted by Paul Madsen, who has done some work on web service specifications and works for a company called EnTrust, which offers products that deal with identity management and access control for web sites. He's been working on trust mechanisms for the Global Grid Forum, a group that designs open standards for distributed computing, and has also been following work by the Liberty Alliance in that area.
One focus of the Global Grid Forum work adds nuance to the acceptance of a certificate or encryption key. Usually, key acceptance is a binary decision. It matches or it doesn't. And if your site uses a third party for authentication, you just accept whatever their decision is.
But in the real world, some keys and certificates are better than others. In fact, certificate authorities define policies that say what they did to validate the identity of the person who was granted the certificate, and the purposes for which a certificate can safely be used. The process of handing out certificates, and the information recorded by certificate authorities while doing it, is a part of the social infrastructure.
The Global Grid Forum and Liberty Alliance are trying to make some of this information part of a server's decision whether to trust an assertion it gets from a third party. The Global Grid Forum calls this qualified installation of keys -- you might install the key you get and you might not, depending on the information you get about how it was granted and how well it was protected. This work lies on the meeting ground between technology and law. While specifying a context, an authority can indicate what the limits are to its liability. The negotiation can leave each side clear what it has to take responsibility for, should things go wrong.
The Liberty Alliance issued a specification this past April for something they call an Authentication Context. I find this specification unusual because it's not about a tool or a software library. Rather, it's about what organizations do or the social infrastructure. As with the qualified installation of keys just mentioned, here we see a new interest in data that's about the transaction, the context for the transaction. This consists of information that an authority can pass along with its authentication decision, some elements of which are
- physical protection of certificates (site construction, etc.);
- technical protection of certificates (computer security);
- operational protection of certificates (audits, etc.);
- authentication method (password, smart card, etc.); and
- identification (how does the authority know the individual?).
The authority can tell you whether the authentication was based on a password, smart card, or other mechanism. It can tell you what security measures were used to protect the information from corruption. You can negotiate what context to accept and decide how much to trust the user based on the context that's passed to you.
But as stated by Eve Maler of Sun Microsystems, trust is something created between people, not between computers that just act as blind agents. In that spirit, this past July, the Liberty Alliance went even further and issued business guidelines that organizations using web services should follow. These touch on familiar practices such as accreditation, audits, privacy policies, and so forth.
A company called the PingID Network already tries to provide standards for such things as liability and quality assurance, so that businesses feel safe working long distance, PingID takes as their model the process by which banks set up global ATM networks.
Standardizing business practices can help the most robust practices spread further and faster. A PingID white paper even claims that robust practices in areas such as tracking and revocation of information will reduce the social scourge of identity theft. However, I worry that standardized practices may also put something of a brake on the valuable spontaneity and democratic interaction that drives new ideas.
The Modest and the Grand Promise
Our exploration of contemporary networking problems today culminates in another big question. Ultimately, we have to consider the visions that motivate the new web services standards. They offer what I call a modest promise and a grand promise. The modest promise is that web services will automate stupid drudgery that is currently wasting a lot of people's time and costing businesses money. I support this modest vision. I have a sense that web services will enable people to do much more with handheld devices and will be empowering to individuals.
But I haven't bought in yet to the grand promise. The grand promise is the automated search followed by placing an order in UDDI or ebXML. The grand promise is also the chain of travel sites combined in a single query employing SAML or the WS protocols. These require coordination and trust, which can't be stretched as far on the Web as the proponents like to think.
When you visit a web site, you have no basis for knowing whether anything they claim or anything they promise is true. If you get a web-based rating, as on eBay, you still cannot be absolutely sure. The best you can do is build up an independent, real-life relationship with someone and build your opinion of the online site on that person's opinion. And the more attenuated the relationships are, the less effective that kind of transitive trust is.
Why is this important? Why are all these Web standards being created in the face of an intractable problem of trust? Because, or so I think, of another of the grand promises of web services: to promote globalization, world trade, commerce without walls.
In May 2003, XML leader Jon Bosak aired hopes that XML would help in "saving the world" by making it easier for people to do global business. The vision of affluent Westerners supporting rural African communities by purchasing their fabrics, or Latin American farmers by slurping up their coffee, all without a middleman, is appealing politically. But I think it will be harder than the proponents of the global marketplace believe. We need to trust the people we're going to trade with, especially if they're located more than a twenty minute drive from us, and we currently have zero mechanisms for developing and reporting trust outside of the traditional grapevine and corporate branding.
The only way to create an economy at this point is to create human-to-human connections where it is possible to build up trust, not machine-to-machine connections where no trust is intrinsically present. Standards and technological delivery mechanisms can help at certain points; to quote Bunting, "automation reduces errors, enables the humans to focus on strategic decisions, or otherwise reduces costs and time-to-delivery." But they will leave lots of work for the human-to-human connection.
It's significant that the federated identity model discussed by the Liberty Alliance allows different sites to combine the information they have on a user, but only after the user explicitly gives permission. To take the user out of the loop would be deadly to privacy, so the Liberty Alliance model doesn't automate the linking of information. The requirement for user consent creates a hard and fast limitation on automation.
Technology enables. As it grows in power and gives power to those who use it, the burden rests on its users to use it sanely. We see illustrative failures of sanity in enabling technology for weaponry: individuals massacre schoolchildren; armed gangs terrorize backwaters in poorly governed countries; terrorists spread mayhem everywhere; governments ignore world opinion and spread lies to justify mass destruction.
As Internet technology enables individuals to work together more tightly and more freely, it enables intrusion and cheating. Research has only begun to assemble the pieces that, we hope, will also enable defensive measures and group action to identify and exclude badly behaved members.
Conclusion
So, to sum up, what do I see in the near future? We need to do something about addressing. We need an easy system that assigns each person a persistent address that is useful for all applications; ideally the system would be distributed and resistant to attack or capture. Current Web Services specifications work on the problem of trust without solving the problem of addressing--that is, the problem as I've stated it, the problem of finding someone several hours later.
As for the other issues, coordination and trust, we need modest expectations. We need to form communities within industries or other areas of interest and develop both standards and trust.
It's heartening to see the Liberty Alliance and the Global Grid Forum talking about problems of trust; they are reminding organizations to invest in processes and in research about policies that are expensive, but are ultimately more important than the technologies adopted to streamline their use. Still, the experience of earlier researchers in trust and reputation is a warning that these issues are extremely complicated, as well as hard to formalize. This is a step-by-step process that won't conquer the world--at least not any time soon.
Share your experience in our forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article
