CNET también está disponible en español.

Ir a español

Don't show this again

Christmas Gift Guide
Tech Industry

Commentary: Web services standards to converge

Separate sets of standards will eventually come together. Until then, companies that need to implement new secure Web services should make minimal architecture investments.

Commentary: Web services standards to converge
By Forrester Research
Special to CNET News.com
September 10, 2003, 1:00PM PT

By Randy Heffner, Analyst

Two sets of secure Web services standards are under development: one led by IBM and Microsoft, the other by the Liberty Alliance.

The two efforts are driven by different perspectives, with the result that they overlap in some ways and are complementary in others, both for Web services and for Internet single sign-on (I-SSO). The separate sets of standards will eventually converge, but until then, companies that have a need to implement new secure Web services should make minimal, tactical investments in their architecture.

IBM and Microsoft are working with a small set of hand-chosen partners to create a set of standards proposals sometimes known as the WS-Security stack. The first of these, WS-Security, was submitted to the Organization for the Advancement of Structured Information Standards (OASIS) for standardization, where it has evolved into WSS-SMS. Others are still under development, including WS-Trust, WS-Federation, WS-Policy, WS-SecurityPolicy and WS-SecureConversation (beyond security, IBM and Microsoft are also developing a number of other Web services standards that use a similar model).

The WS-Security stack is designed from the bottom up as a set of low-level primitives that are intended to support many different scenarios for the design and deployment of secure Web services and I-SSO. This bottom-up approach leaves a number of larger design and usage questions unanswered, so interoperability of the WS-Security stack will depend on follow-up work from the Web Services Interoperability Organization (WS-I).

The Liberty Alliance, as a membership-based open industry consortium, has a larger and broader community that develops standards proposals. Liberty's first specification focused on I-SSO, but its upcoming phase two specifications broaden the picture to include secure Web services (via Liberty's Identity Web Services Framework, ID-WSF). Liberty's approach is largely top-down, which tends to reduce the number of design and usage questions that are left open--but not to the point of eliminating interoperability issues. Remaining issues must be addressed by further development of the specification combined with ongoing interoperability testing among vendors of Liberty-enabled software.

To date, there has been little opportunity for the two camps to work directly together; and both have stated a preference to work out their differences in the context of a standards body. IBM and Microsoft have been dissatisfied with Liberty's architecture and its management of intellectual property rights. Liberty disdains any specifications not managed by a standards body, so it makes no reference to any of the WS-Security stack proposals except WSS-SMS.

As would be expected in this scenario, there are direct conflicts in the existing drafts. For example, the WS-Security stack only uses the security token format from the Security Assertion Markup Language (SAML), while Liberty is heavily based on SAML's interaction protocols. Also, a Liberty identity provider is, by default, ignorant of a user's identities across sites, while WS-Federation's pseudonym service knows a user's multiple identities.

While the two efforts conflict in some areas, there is opportunity for future alignment and reconciliation--especially since both sets of proposals are likely to be submitted to OASIS for standardization. There are notable ways in which it is possible and practical for IBM and Microsoft's bottom-up approach and Liberty's top-down approach to meet in the middle. For example:

• Liberty's SOAP Binding specifies message identification and correlation steps as a basis for protection against message replay attacks, and the WS-Security stack repeatedly refers to the need for such a mechanism but does not rigorously define one.

• WS-Policy and WS-SecurityPolicy specify a generalized mechanism for Web services to communicate and negotiate low-level interaction mechanisms, and Liberty could increase the flexibility and extensibility of its embedded policies by adopting them.

• Liberty's top-down specifications, by building in high-level design decisions, can bring needed focus to the building-block primitives of the WS-Security stack, which are somewhat difficult to connect.

• Liberty's Security Mechanisms and WS-SecureConversation define different but complementary aspects of security session context.

These opportunities are, of course, no guarantee that there will be meeting in the middle. However, they illustrate that the two initiatives are not diametrically opposed and that each can benefit from the other. For this reason, combined with the common WSS-SMS foundation between the two, we believe that, even if there is not an eventual reconciliation of the two, they will be close enough that security software products will be able to achieve integration, if not interoperability, between the two.

Much of the convergence is likely to come as Liberty adopts various building blocks from the WS-Security stack when they are placed in the hands of industry standards groups. For its part, Liberty's scenario focus is driving industry dialog that will tend to narrow the variety of scenarios, allowing the WS-Security stack to be simplified as it is standardized.

• It will take between 18 and 30 months for the final configuration of secure Web services standards to become clear. During this period of instability, it is best to make only tactical investments in secure Web services architecture. WSS-SMS is a safe bet, and new architectures should be based on it. On the other hand, absent a compelling reason to do otherwise, existing architectures not based on WSS-SMS should be left as they are.

As appropriately based on application requirements, make opportunistic use of concepts and mechanisms from both Liberty and the WS-Security stack. Most useful in this regard will be message correlation (from Liberty's SOAP Binding), token request/response (from WS-Trust), and security context handling (from WS-SecureConversation and Liberty's Security Mechanisms). Vendor toolkits may be useful for tactical implementations (for example, Microsoft's Web Services Enhancements), but be careful to use features in a minimal fashion, until the end architecture for secure Web services becomes clearer.

© 2003, Forrester Research, Inc. All rights reserved. Information is based on best available resources. Opinions reflect judgment at the time and are subject to change.