Overview: In October 2001, Microsoft announced the release of a WS-Security specification defining enhancements to SOAP messaging to provide three capabilities: credential exchange, message integrity, and message confidentiality. In April 2002, Microsoft, IBM, VeriSign announced the publication of a Web Services Security (WS-Security) specification and a roadmap document describing a proposed strategy for addressing security within a Web service environment.

In July 2002 the Web Services Security (WS-Security) specification was submitted to OASIS by IBM, Microsoft, and VeriSign for further development. Also in July 2002, an OASIS Web Services Security Technical Committee (WSS) was formed to continue work on the Web services security foundations published in the WS-Security specification within the context of the Web Services Security roadmap published in April, 2002: "Security in a Web Services World: A Proposed Architecture and Roadmap."

In April 2004 the OASIS WSS TC Chairs announced that five specifications produced by the technical committee had been approved as OASIS standards. This initial specification set included a core document Web Services Security: SOAP Message Security 1.0 (WS-Security 2004), the Web Services Security UsernameToken Profile 1.0, the Web Services Security X.509 Certificate Token Profile, and two relevant XML Schemas.

In February 2006, OASIS announced that its members had "approved WS-Security version 1.1 as an OASIS Standard. Developed through an open process by the OASIS Web Services Security (WSS) Technical Committee, WS-Security delivers a technical foundation for implementing security functions such as integrity and confidentiality in messages implementing higher-level Web services applications... The WSS specifications describe a mechanism for securing web services message exchanges using a variety of existing security technologies and methodolgies. The 2006-02 document set is the 1.1 revision of the original WS-Security 2004 OASIS standard. Several token profiles have been added. The 1.0 Errata has been factored in. Feedback from the public has been included and steps have been taken to enhance the readability and usability of the specification. An additional 1.1 Schema has been produced and a few XML Elements have been added to the language."

Contents

• Overview
• Web Services Security: Publication Milestones
• OASIS Web Services Security TC (WSS) Deliverables
• WS-Security 2001-2002 and Related Specifications: Principal References
• Web Services Security Specification: Articles, Papers, News

---

Web Services Security Specification: Articles, Papers, News

• [September 13, 2006] Guide to Secure Web Services. Draft Recommendation of the National Institute of Standards and Technology (NIST). By Anoop Singhal (NIST) and Theodore Winograd (Booz Allen Hamilton) Computer Security Division, Information Technology Laboratory, National Institute of Standards and Technology (NIST), U.S. Department of Commerce. Developed under the U.S. Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347. NIST Special Publication 800-95 (Draft). September 2006. 140 pages. Appendix C provides an overview of ebXML, a Web services protocol suite developed by the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT). Document sections: 1. Introduction; 2. Background to Web Services and Their Relationship to Security; 3. Web Service Security Functions and Related Technologies; 4. Human User's Entry Point into the SOA: Web Portals; 5. Secure Web Service-Enabling of Legacy Applications; 6. Secure Implementation Tools and Technologies. "The security challenges presented by the Web services approach are formidable and unavoidable. Many of the features that make Web services attractive, including greater accessibility of data, dynamic application-to-application connections, and relative autonomy (lack of human intervention) are at odds with traditional security models and controls... While many of the Web services challenges have been met with existing standards, there are a number of challenges that standards organizations are currently addressing -- particularly in the area of Web services discovery and reliability. The Web Services Interoperability (WS-I) organization acknowledges that there are many challenges that have yet to be addressed. Some examples of these challenges are: Repudiation of transactions; Secure issuance of credentials; Exploitation of covert channels; Compromised services; Spread of viruses and Trojan horses via SOAP messages; Denial of service attacks; Incorrect service implementations; Poor service designs. This [Guide to Secure Web Services] publication seeks to assist organizations in understanding the challenges in integrating information security practices into Service Oriented Architecture (SOA) design and development based on Web services. This publication also provides practical, real-world guidance on current and emerging standards applicable to Web services, as well as background information on the most common security threats to SOAs based on Web services. This document presents information that is largely independent of particular hardware platforms, operating systems, and applications. Supplementary security devices (i.e., perimeter security appliances) are considered outside the scope of this publication. Interfaces between Web services components and supplementary controls are noted as such throughout this document on a case-by-case basis..." [PDF source]

• [February 15, 2006] "Members Approve WS-Security v1.1 as OASIS Standard." OASIS Announcement February 15, 2006. "OASIS, the international e-business standards consortium, today announced that its members have approved WS-Security version 1.1 as an OASIS Standard, a status that signifies the highest level of ratification. Developed through an open process by the OASIS Web Services Security (WSS) Technical Committee, WS-Security delivers a technical foundation for implementing security functions such as integrity and confidentiality in messages implementing higher-level Web services applications... The specifications describe a mechanism for securing web services message exchanges using a variety of existing security technologies and methodolgies. The document set is the 1.1 revision of the original WS-Security 2004 OASIS standard. Several token profiles have been added. The 1.0 Errata has been factored in. Feedback from the public has been included and steps have been taken to enhance the readability and usability of the specification. An additional 1.1 Schema has been produced and a few XML Elements have been added to the language."

• [April 20, 2005] "Companies Demonstrate Interoperability of WS-Security OASIS Standard. BEA Systems, DataPower, IBM, Microsoft, Oracle, Reactivity, Panacea Software, RSA Security, Sarvega, Sun Microsystems, Systinet, TIBCO, and VeriSign Collaborate on WS-Security OASIS InterOp at Gartner Summit." - "Fourteen organizations joined together for the first time to demonstrate interoperability of the WS-Security OASIS Standard at the Gartner Application Integration and Web Services Summit in Los Angeles today. WS-Security, developed by the OASIS Web Services Security (WSS) TC, delivers a technical foundation for implementing security functions such as integrity and confidentiality in messages implementing higher-level Web services applications. Gartner analyst, Ray Wagner, describes WS-Security as 'the standard for the majority of Web services...committing to it now will allow enterprises to easily modify the security profile of deployed Web services in the future.' WS-Security allows a wide range of key security methods such as authentication and access control to be reliably, readily associated with SOAP messages. The OASIS InterOp at the Gartner Summit demonstrated the exchange of messages protected by WS-Security using the X.509 Token Profile. 'It is gratifying to see so many vendors supporting the WS-Security OASIS Standard with their interoperable implementations,' observed Hal Lockhart of BEA Systems, lead of the OASIS InterOp team. 'We came together with a common goal: to make it clear to all implementers-not just the larger enterprises that have already embraced the standard-that the time is right to adopt WS-Security.' Patrick Gannon, president and CEO of OASIS, agreed. 'WS-Security provides a key component for the broader security frameworks that users need. Many of the participants in today's InterOp are also deeply involved in advancing other OASIS Standards for security, such as the Security Assertion Markup Language (SAML) and the eXtensible Access Control Markup Language (XACML). The synergy between these efforts goes a long way towards meeting the marketplace's need for a cohesive fit between standards,' said Gannon, who also participated in Gartner's 'Power Panel: A Conversation on Standards' at the event..."

• [September 2004] "WS-Security Interoperability Using WSE 2.0 and Sun JWSDP 1.4." By Simon Guest (Program Manager, Architecture Strategy Team, Microsoft Corporation). "This article shows WS-Security Interoperability between Microsoft WSE 2.0 and Sun JWSDP 1.4. It covers techniques to send secure messages between the .NET Framework and J2SE using Microsoft WSE 2.0 and Sun JWSDP 1.4, both of which support the OASIS WSS 1.0 standard. The walkthroughs in this article will take you through all you need to know to configure the two environments for securely signing and encrypting SOAP requests and responses using X509 certificates. WS-Security is a specification to enable security for Web services; specifically through message integrity, message confidentiality, and single message authentication. The WS-Security specification was co-authored by Microsoft, IBM, and Verisign. On April 6 2004, OASIS released OASIS Web services Security 1.0 based on this specification. This standard includes recommendations for SOAP message security with profiles for using username and X509 tokens to enable security. Many vendors are providing implementations of WS-Security. Microsoft offer WS-Security support in WSE (Web Services Enhancements) 2.0, a download from MSDN that compliments the Web services support in the .NET Framework. Sun offer support for WS-Security in JWSDP (Java Web services Developer Pack) 1.4, which can be downloaded from their site. As a standard, WS-Security is still new. The capability to use WS-Security to perform vendor neutral, transport independent security for Web services is however powerful. The commitment of all vendors, with the OASIS specification proves that security for Web services is achievable today..."

• "Web Services Security (WSS) Ratified as OASIS Standard. AmberPoint, BEA Systems, Betrusted, Commerce One, Computer Associates, Documentum, Entrust, Fujitsu, HP, Hitachi, IBM, Microsoft, Netegrity, Nokia, Novell, Oblix, OpenNetwork, Oracle, Reactivity, RSA Security, SAP, Sarvega, SeeBeyond Technology, Sun Microsystems, Verisign, and Others Develop Foundational Standard for Security." - "The OASIS international standards consortium today announced that its members have approved the Web Services Security (WSS) version 1.0 (WS-Security 2004) as an OASIS Standard, a status that signifies the highest level of ratification. WSS offers a trusted means for applying security to Web services by providing the necessary technical foundation for higher-level services. Gartner analyst, Ray Wagner, advised, 'Enterprises should adopt WSS formatting for all across-the-firewall Web service deployments, even in cases where no security needs have been identified. Gartner believes that WSS will be the standard for the majority of Web services, and committing to it now will allow enterprises to easily modify the security profile of deployed Web services in the future.' WSS builds upon existing security technologies such as XML Digital Signature, XML Encryption and X.509 Certificates to deliver an industry standard way of securing Web services message exchanges. Providing a framework within which authentication and authorization take place, WSS lets user apply existing security technology and infrastructure in a Web services environment. 'By enabling applications to share information regarding network access regardless of the underlying platform, Web Services Security paves the way for broader adoption of Web services,' said Chris Kaler of Microsoft, co-chair of the OASIS WSS Technical Committee. 'The OASIS WSS TC is pleased by the support and commitment of the Web services community leading to the ratification of Web Services Security as an industry standard.' WSS handles complex confidentiality and integrity for SOAP (Simple Object Access Protocol) messages, providing a general-purpose mechanism for associating security tokens with message content. Designed to be extensible, WSS supports multiple security token formats. 'A client might provide one format for proof of identity and another format to verify their business certification,' explained Kelvin Lawrence of IBM, co-chair of the OASIS WSS Technical Committee. 'Using WSS, a system can authenticate the identity of a person connecting to several networks at once or pass data between two applications securely.' 'The Web Services Security OASIS Standard represents a truly impressive collaboration from across the industry,' noted Patrick Gannon, president and CEO of OASIS. 'It is testament to the value of the open standards process where users and vendors, large and small, come together to advance a common good. WSS delivers a much-needed foundational technology that will enable Web services to be deployed with confidence'..." See details in the news story "OASIS Web Services Security Specification Approved as an OASIS Standard."

• [April 13, 2004] "Web Services Security Advances With Approval of Key Standard." By Ray Wagner (Gartner Research). Gartner Note, Number FT-22-6913. April 13, 2004. ['The formal approval of a widely accepted standard is a significant step forward for Web services security. Enterprises should adopt Web Services Security (WS-Security) now.'] "The OASIS decision is a critical, if unsurprising, event in the development of secure Web services implementations. The need for WS-Security is widely recognized, and no serious competition for the standard exists. WS-Security is one of the essential cornerstones — along with Secure Sockets Layer/Transport Layer Security (SSL/TLS), Security Assertion Markup Language (SAML) and perhaps XKMS (XML Key Management Specification) — of mutual authentication and data confidentiality for Web services. Further industry acceptance and development of SAML- and SSL-based Web services in the WS-Security format is likely, because the basic infrastructure is already in place. Most vendors of Web services, Web services security and identity management products now support, or plan to support, WS-Security and SAML. This level of industrywide agreement does not, however, exist for the many other, more ambitious standards (WS-*) that will be required for true Web services interoperability... Gartner believes that WS-Security will be the standard for the majority of Web services, and committing to it now will allow enterprises to easily modify the security profile of deployed Web services in the future. Security administrators should not, however, assume that WS-Security and SAML alone will ensure adequate Web services security. Web services deployments will still be at risk if old code bases are connected to Web services interface or new ones are written with security flaws or bad WSDL (Web Services Description Language) descriptions. Through 2007, the greatest threat to Web services security will likely be the use of commercial off-the-shelf Web services application interfaces without adequate security..." Article also in PDF format.

• [April 09, 2004] "A Developer's Roadmap to Using WS-Security." By Vance McCarthy. In Integration Developer News (April 09, 2004). "WS-Security, one of the core building blocks for interoperable web services security, was adopted this week by OASIS. The action means that devs and IT managers could start seeing XML-based security solutions start cropping up in all sorts of enterprise products, from IDEs, to firewalls and even front-end UI designs and back-end servers. It also means that Microsoft, Sun and IBM continue to find more reasons to cooperate, rather than bicker. To help devs and senior technicians understand what the adoption of WS-Security might mean to their business -- and career -- IDN takes as a look at how developers can best begin to leverage WS-Security technologies, as we conduct an in-depth conversation with Steven Van Roekel, Microsoft's Director of Web Services Technical Marketing, and a leading member of the WS-I's (Web Services Interoperability Organization's) push to implement tools and testing assistance for developer and ISV use of WS-Security. In our conversation, Van Roekel also shared details on how developers can implement WS-Security across multi-vendor (Java and .NET) platforms, the vision for 'next steps' for securing web services, and even how the WS-I's BSWG plans to produce a basic Security Profile, to help guide developers in building an interoperable security framework from various products and standards..."

• [April 08, 2004] "Security Specification for Web Services Finalized." By Gavin Clarke. In CBR Online (April 08, 2004). "A key security element of IBM Corp and Microsoft Corp's web services roadmap has received official standards blessing, paving the way for widespread industry adoption. Key documents in the WS-Security 1.0 core specification have been ratified along with two important token profiles, for usernames and X.509, by the Organization for the Advancement of Structured Information Standards (OASIS). Companies developing WS-Security through an OASIS technical committee included BEA Systems, Hewlett Packard, IBM, Microsoft, Oracle, SAP and Verisign. Vendors are now expected to implement WS-Security into their products, providing a common level of interoperability. WS-Security is fundamental to the WS-* specification roadmap that was co-authored by IBM and Microsoft. WS-Security serves as foundation specification for other elements in the companies' roadmap including WS-Secure Conversation, WS-Trust and WS-Security Policy that manage the transaction secured by WS-Security. WS-Security is also important in helping end-users come a step closer to realizing the full potential of web services, by providing a secure mechanism to take web services transactions beyond the firewall for secure day-to-day transactions with partners. Security has been lacking in web services to-date, hence projects have remained internal. WS-Security provides security infrastructure for applications such ordering, invoicing and payment. VeriSign principle scientist Phillip Hallam-Baker, who worked helped work on WS-Security, said. 'People have the ability to start taking their existing applications beyond the firewall and moving to the next stage of web services, using them in extranets for business with close partners.' WS-Security provides confidentially and integrity for web services transactions through the federated use of encryption and digital signatures. WS-Security differs from traditional approaches to encrypting and signing messages, because it accepts a message may be routed between multiple trading partners instead of communication being limited to point-to-point transaction between just two parties..."

• [December 26, 2003] "Web Services Security Kerberos Binding." By Giovanni Della-Libera (Microsoft), Brendan Dixon (Microsoft), Praerit Garg (Microsoft), Maryann Hondo (IBM), Chris Kaler (Microsoft), Hiroshi Maruyama (IBM), Anthony Nadalin (IBM), and Nataraj Nagaratnam (IBM). December 18, 2003. Copyright (c) 2003 IBM Corporation, Microsoft Corporation. 25 pages. ['This Web Services Security Kerberos Binding Specification is an initial public draft release and is provided for review and evaluation only.'] "This document describes how to use Web Services security specifications with Kerberos... Kerberos is an established authentication and security infrastructure in use in many environments today. Consequently, as applications integrate with and are developed for Web services, there is a need to leverage existing security infrastructure. This specification describes how to integrate Kerberos security environments with the Web service security architecture. Integration with Web services security requires the following aspects: (1) Requesting and issuing security tokens; (2) Attaching security token to messages; (3) Establishing a secure context; (4) Signing and encrypting the message using the security context. This specification describes two models of Web service usage and interoperability: GSS-API and Raw Kerberos... This specification builds on the WS-Security, WS-Trust, and WS-SecureConversation specifications to integrate Kerberos functionality... The security tokens used by both [GSS-API and Raw Kerberos] models are binary and not based on XML. Consequently, the <wsse:BinarySecurityToken> element from WS-Security is used to pass security tokens inside SOAP messages. The wsse:ValueType and wsse:EncodingType attributes describe the security token's type and encoding. Applications integrating Kerberos with WS-Security must include their tokens as instances of <wsse:BinarySecurityToken>. They should encode these in base64... GSS-API presents a common approach and feature set over a number of different and popular security protocols. It is frequently used when two Web services, both existing within Kerberos environments leveraging GSS-API, want to securely interoperate across the Internet... Alternatively instead of using GSS-API, interoperability can be achieved at the Kerberos level. That is, using raw Kerberos security tokens and cryptographic functions. The model is straightforward: tickets are obtained and the keys are extracted for use in signing and encrypting messages. Kerberos is an IETF standard third-party mediated protocol as described in RFC 1510... Conceptually, a Kerberos KDC implements what WS-Trust calls a Security Token Service: It generates security tokens (e.g., Kerberos TGT) in exchange for other tokens..." [cache]

• [July 12, 2003] "Burton Group Speakers Debate Web Services. Security Remains a Concern." By Paul Krill. In InfoWorld (July 11, 2003). "Speakers at the Burton Group Catalyst Conference 2003 debated the pros and cons of Web services-based application integration, illustrating the diversity of opinions still surrounding the technology... 'The reason that Web services will succeed is because we have total industry buy-in,' [Ann] Manes said. She also touted the Web Services Interoperability Organization's Basic Profile, saying it will provide for basic interoperability across any language or platform. Issues remain, however, such as scalability and performance, said Manes. She also stressed that users of Web services need to fit their systems with Web services management tools. But Web services will become part of the IT fabric, Manes said. 'Five years from now, you won't even think about Web services because it will become just part of your fabric,' in the same manner that enterprises use sockets, Manes said. The issue of security, long a concern with Web services, is being addressed via the WS-Security specification, she said. 'WS-Security is very close to being finished and it's a very strong specification,' Manes said. WS-Security is under the jurisdiction of the Organization for the Advancement of Structured Information Standards (OASIS). A Web services user speaking at the conference, however, expressed concerns with the current level of security in Web services. 'It's a miserable story and I think it's a reason why we don't do a whole lot outside our firewalls,' said David Cohen, a vice president of the technology architecture group at Merrill Lynch. 'To me, Web services is just a communications system,' Cohen said. 'It's just at a higher level of the network stack.' Merrill Lynch, however, is a 'huge champion of XML,' said Cohen. BEA Systems' Scott Dietzen, also CTO, stressed that Web technology providers need to get on the WS-Security bandwagon..."

• [June 25, 2003] "Systinet Announces WASP Server for Java, 4.6 With Full Support For WS-Security. WASP Provides Industry's Best Web Services Security, Performance and Interoperability." - "Systinet, "leading independent provider of Web services infrastructure software, today announced the general release of WASP Server for Java, 4.6, the award-winning Web services infrastructure platform that fully supports the latest standards, including OASIS Web Services Security (WS-S) and offers the industry's best performance and interoperability. The 4.6 release has new and unique functionality that makes it much easier to create and run Web services applications, including enhanced support for asynchronous Web services, full support for SOAP 1.2, and the industry's most comprehensive support for Java Web services APIs, including JAX-RPC, JAXM and SAAJ. WASP Server for Java is a complete solution for creating, running and managing sophisticated Web services applications and is available for free download from Systinet's Website... In addition to the many security capabilities already in WASP Server for Java, version 4.6 now includes WS-S message-level security. WASP supports both the OASIS WS-S standard currently in final draft, and the earlier Microsoft-IBM WS-Security specifications. This support ensures that WASP is compatible with all WS-Security implementations. WASP Server for Java, 4.6 also offers unique security and alerting features. For example, users will be alerted if a message cannot be decrypted or if an authentication event failed... WASP Server for Java offers unique asynchronous web services support: Simple Web services are invoked synchronously -- when a client sends a message to a server, it halts until a response is received. This method becomes unworkable, especially for complex computations or for multi-part tasks. Since it is much more efficient to asynchronously invoke services, WASP 4.6 supports an easy-to-use, event-based way of calling Web services asynchronously. The mechanism eliminates the need for developers to write client code for polling the service. Also, WASP Server for Java features transport-level asynchronous messaging, which relies on using different transport channels for the request and response messages, such as an HTTP request, an e-mail response, or even an email request and an e-mail response... WASP makes is easy to build Web services using popular IDEs and has expanded support to include IntelliJ IDEA, a popular Java development environment. WASP already supports Borland JBuilder, Eclipse, IBM WebSphere Studio Application Developer, Sun ONE Studio and NetBeans. Systinet's WASP suite of products is a complete solution for building, deploying, securing and managing Web services. Systinet WASP Server for Java and WASP Server for C++ are industrial-strength Web services runtime environments that fully support industry standards, including SOAP 1.1, SOAP 1.2 and WSDL 1.1. WASP UDDI is a V2 complaint registry with advanced V3 functionality. WASP UDDI is a full-featured UDDI registry that allows businesses to standardize the way businesses organize, catalog, discover and reuse Web services across the company..."

• [April 11, 2003] "Web Services Security: Non-Repudiation." Edited by Eric L. Gravengaard (Reactivity, Inc). Contributors: Grant Goodale, Michael Hanson, Brian Roddy, and Dan Walkowski (Reactivity). Submitted to the OASIS Web Services Security TC. Document identifier: 'web-services-non-repudiation-05'. 11-April-2003. 19 pages. Posted to the WSS Mailing List 11-April-2003 by Eric Gravengaard (Reactivity, Inc). The Web Services Security: SOAP Message Security specification defines the usage of XML Digital Signatures within a SOAP header element to prove the integrity of a SOAP message. While this is useful in the context of non-repudiation to the receiver, it does nothing to guarantee to the sender that the message was delivered properly and without modification. Similarly, when the SOAP requestor receives the SOAP response message there is no way of proving that the SOAP response was generated after receiving and processing the SOAP request. This specification extends the use of XML Digital Signature in the context of WSS: SOAP Message Security to allow senders of SOAP messages to request message disposition notifications that may optionally be signed to prove that the receiver received the SOAP message without modification. The specification also defines a method for embedding SOAP message dispositions in a SOAP message header. This specification constitutes a protocol for voluntary non-repudiation of receipt that when used systematically provides cryptographic proof of both parties participation in a transaction. This specification does not define any mechanism to prove receipt of a message by a non-conformant implementation. Editor's comment: "Reactivity would like to submit this document to the TC for consideration and inclusion in the Web Services Security: SOAP Message Security specification. The Web Services Security: Non-Repudiation proposal (WSNR) defines a standard mechanism for voluntary non-repudiation of receipt. The goal of this proposal is to enable the exchange of SOAP messages in an environment where the SOAP Message sender has cryptographic proof that the SOAP Message responder received the request unaltered. This proposal makes use of the XML Signature specification to provide cryptographic proof of integrity and the WSS:SOAP Message Security Core to allow the transport of both receipt requests and receipts within a <Security> header. This submission is made under the OASIS rules regarding intellectual property rights. Reactivity intends the contents of this document to be available for license royalty free..." [source]

• [February 21, 2003] "WS-Security: New Technologies Help You Make Your Web Services More Secure." By David Chappell. In Microsoft MSDN Magazine (April 2003). ['Without good security, Web Services will never reach their potential. WS-Security and its associated technologies, the focus of this article, represent the future of security for Web Services. Provided here is an overview of these emerging security standards that explains what they do, how they work, and how they get along together. Topics discussed include integrity and confidentiality and how these are provided by public key cryptography, WS-Security, and more. Some of the key components of WS-Security, such as the wsu namespace, are also covered.'] "Web Services without effective security aren't very useful. Yet the original creators of SOAP chose to put off defining how this problem should be solved. This was a defensible decision, since getting Web Services off the ground meant keeping them simple -- and providing security is seldom simple. The problem, however, can't be put off forever so Microsoft and IBM, among others, are working together to address this issue. Their efforts have resulted in a group of specs for providing Web Services security, the most important of which is WS-Security. With this article I'll provide a big-picture view of how these technologies work. From one perspective, the task facing the creators of Web Services security looks simple. After all, effective mechanisms already exist for distributed security, including Kerberos, public key technologies, and others, so the task these creators faced wasn't inventing new security mechanisms. Instead, their goal was to define ways to use what already existed in a Web Services world, a world built on XML and SOAP... The fundamental technology for adding security to SOAP is defined by WS-Security. Its ambitious goal is to provide end-to-end message-level security for SOAP messages, and yet the WS-Security spec isn't especially hefty, weighing in at just over 20 pages. This is because WS-Security defines very little new technology but instead defines a way to use existing security technology with SOAP... Effective security for Web Services is essential. Given that most of what's needed is already in place (and the problem is simply a matter of mapping this existing security technology to XML and SOAP), you might think that WS-Security and its associated specs would be very simple (and this article would be very short). Yet accommodating the diverse security mechanisms in use today, along with allowing for those that will appear tomorrow, requires a nontrivial set of technology. Once this technology is in place, the world of secure and interoperable Web Services that we'd all like to see can become a reality. I don't know about you, but I can't wait for this day to arrive..."

• [January 14, 2003] Royalty-Free License Terms in Microsoft's Web Services Security IPR Disclosure. In part: "... If an OASIS Standard incorporating this Contribution is adopted by OASIS pursuant to the WS-Security Technical Committee Charter at the time the Contribution was submitted, Microsoft will grant, for the limited purposes of implementing and complying with the required portions of the resulting OASIS Standard, a ROYALTY-FREE, worldwide, non-sublicenseable, non-transferable, license to any such Necessary Claims to implement the Contribution under reasonable and non-discriminatory terms and conditions, provided a reciprocal patent license is granted to Microsoft and other implementers of the OASIS Standard..."

• [December 16, 2002] "Microsoft Delivers Latest Developer Tools for Building Advanced, More Secure Web Services. Web Services Enhancements 1.0 Available for Visual Studio .NET. Developers, With Support From Companies Such as F5 Networks, WestGlobal and WRQ." - "Highlighting industry demand for the latest Web services capabilities, Microsoft Corp. today announced key companies, including F5 Networks, WestGlobal and WRQ Inc., that are taking advantage of Web Services Enhancements 1.0 (WSE) for Microsoft .NET, which gives Visual Studio .NET developers support for the latest Web services specifications, such as WS-Security, WS-Routing and WS-Attachments. The news coincides with Microsoft's announcement of the release to Web (RTW) of WSE 1.0, following the technical preview delivered in August 2002. Available via download, WSE works with Visual Studio .NET and the .NET Framework so developers can quickly add a few lines of code to their Web services applications to keep pace with the latest industry advancements. In addition to its ability to quickly build new Web services solutions, WSE has been embraced by customers and industry partners as an important tool for connecting to existing systems... Since the introduction of the technical preview in August 2002, WSE has gone through rigorous testing and customer review to reach the milestone of RTW of WSE 1.0. WSE is built on existing XML Web Services standards such as XML and SOAP, while providing the following advanced capabilities: Security. It can help secure XML Web services across platforms and trust domains, including digital signing and encryption of SOAP messages that are compliant with the WS-Security specification, jointly introduced by Microsoft, IBM Corp. and VeriSign Inc. in April 2002 and submitted to OASIS in June 2002. Routing. It can route an XML Web service through intermediaries using the WS-Routing specification, which describes how to place message addresses in the SOAP message header and enables SOAP messages to travel serially to multiple destinations along a message path. The route a SOAP message takes to an XML Web service can be transparently delegated among Web servers. Attachments. Communication between XML Web services can contain attachments that are not serialized into XML. The WSDK provides the ability to add attachments to SOAP messages following the WS-Attachments specification. WS-Attachments was jointly submitted to the IETF by Microsoft and IBM. Extensible framework. WSE is an extensible pipeline for SOAP message processing. Developers can extend the built-in functionality of the system to customize its encryption and signing capabilities to support proprietary security infrastructures. Custom logic also can be incorporated into the pipeline to provide additional functionality such as auditing, logging, or store and forward..." See: (1) the main page Web Services Enhancements for Microsoft .NET; (2) Programming with Web Services Enhancements 1.0 for Microsoft .NET"; (3) "WS-Security Authentication and Digital Signatures with Web Services Enhancements," by Matt Powell; (4) Inside the Web Services Enhancements Pipeline.

• [December 16, 2002] "Microsoft Highlights Security in Web Services Development Pack." By Paul Krill. In InfoWorld (December 16, 2002). "Microsoft on Monday [2002-12-16] is officially unveiling the general release of Web Services Enhancements 1.0 (WSE) for Microsoft .Net, focusing on security and support of proposed standards. The free product, which had been available in an unsupported technical preview format since August, is a plug-in to Microsoft's Visual Studio .Net. It is built on existing Web services standards such as XML, SOAP (simple Object Access Protocol) and WSDL (Web Services Description Language). New in the general release is an API for log-in, session handling and audit trails, but Microsoft officials are focusing particularly on support for the proposed WS-Security standard now under consideration by OASIS (Organization for the Advancement of Structured Information Standards). WS-Security was first published by Microsoft, IBM and Verisign in April. Through use of WS-Security, developers can build more secure Web services, Microsoft officials stressed. "It secures the actual message and payload," said Rebecca Dias, product manager for Web services marketing at Microsoft, in Redmond, Wash. Security is maintained when messages are passed to multiple points, she said. "What we're doing is allowing you to sign that part of data that's flowing over the Internet," Dias said. Other features included as part of WS-Security support include backing for x.509 digital certificates and Kerberos, to encrypt messages... Microsoft also is featuring support for the Microsoft-proposed WS-Routing specification. This enables messages to be sent through intermediaries and across different transports, to leverage load balancing as well as geographic balancing, to enable a local server to process Web services. Also featured is support for the WS-Attachments proposal now sitting before the IETF (Internet Engineering Task Force). This support together with backing of DIME (Direct Internet Message Encapsulation) enables binary files to be sent via SOAP-based transports..." See also the announcement "Microsoft Delivers Latest Developer Tools for Building Advanced, More Secure Web Services. Web Services Enhancements 1.0 Available for Visual Studio .NET. Developers, With Support From Companies Such as F5 Networks, WestGlobal and WRQ."

• [December 11, 2002] "WS-Security Authentication and Digital Signatures with Web Services Enhancements." By Matt Powell (Microsoft Corporation). Microsoft MSDN Library. December 2002. ['Part of the documentation for Web Services Enhancements 1.0 for Microsoft .NET. Web Services Enhancements 1.0 for Microsoft .NET (WSE) provides advanced Web services functionality for Microsoft Visual Studio .NET and Microsoft .NET Framework developers to support the latest Web services capabilities. Enterprise ready applications can be developed quickly with the support of security features such as digital signature and encryption, message routing capabilities, and the ability to include message attachments that are not serialized into XML.'] "With the advent of the Web Services Enhancements 1.0 for Microsoft .NET (WSE), Microsoft has provided its first toolset for implementing security within a SOAP message. No longer are Web services tied strictly to using the security capabilities of the underlying transport. Now a SOAP message on its own can be authenticated, its integrity verified, and can even be encrypted all within the SOAP envelope using the mechanisms defined by the WS-Security specification. In this article, we will be looking at how you can use WSE to take advantage of WS-Security for authenticating and signing data for your Web services. Simply sending X.509 certificates with a request is actually not much of a way to authenticate anything. The certificates are considered public knowledge so anyone could include anyone else's certificate with their request. The mechanism for using certificates for authentication is based off the idea we mentioned earlier in regards to signing some entity with the private key that corresponds to the public key in the certificate... WSE supports creating digital signatures in a very straightforward manner... The WSE SOAP extension will validate the syntax of a digital signature, but simply knowing that a valid signature exists in a message is not enough to know that the message came from a particular individual. WS-Security and the XML Digital Signature specification, (Extensible Markup Language) XML-Signature Syntax and Processing, are very flexible in the way that they allow signatures to be included within XML... This article illustrates how Web Services Enhancements for Microsoft .NET offers you a glimpse into the capabilities of the WS-Security specification by looking at how you can use WSE to do UsernameToken authentication and by using X.509 authentication to digitally sign portions of the SOAP message. WSE lets you inspect and verify the kind of WS-Security support that is included with a SOAP message. There are a number of other WS-Security capabilities WSE provides that are not discussed here, such as using various forms of encryption..."

• [December 10, 2002] "VeriSign Offers Open Source WS-Security Implementation and Integration Toolkit to Help Developers Integrate Security Into Web Services. Effort Continues VeriSign's Commitment to Driving Trusted Web Services With Royalty-Free Implementation." - "Furthering its commitment to trusted Web services, VeriSign, Inc., the leading provider of digital trust services, announced today the royalty free availability of technology that will allow companies to integrate digital signatures and encryption into Web services. Based on the recently announced WS-Security specification and Addendum, which was co-written by IBM, Microsoft and VeriSign, this implementation provides enterprises, software developers and systems integrators with code they can use to achieve higher levels of trust and security when designing Web services applications and services. Offering this code as open source is intended to accelerate widespread adoption of Web services by making them even easier to secure. In addition, VeriSign announced that it has made available a version of its VeriSign Trust Service Integration Kit (TSIK) with security features for Web services, such as XML Signature, XML Encryption, and XML Key Management Services (XKMS). VeriSign TSIK is a Java-based developer toolkit for integrating security capabilities into Web services. 'Companies simply will not implement Web services until the industry adequately addresses the issues of trust and security,' said Dr. Phillip Hallam-Baker, VeriSign's Principal Scientist and Web Services Security Architect. 'We are helping to address those critical issues by taking a leadership role in providing customers and developers with some extremely useful code that they can implement in their Web services applications today to alleviate those concerns'... VeriSign will provide an open source implementation of WS-Security through its open source libraries, providing resources for building interoperable, trusted Web services using the proposed WS-Security standard. The VeriSign libraries can be deployed to provide protocol support for both client and server applications. In a typical situation, a Web service will rely on these libraries to add secure messaging to whatever business logic the Web service supports. The Trust Service Integration Kit includes three basic components: the messaging framework, the trust layer and XML resources. (1) The messaging framework brings together various VeriSign Application Programming Interfaces (APIs) to provide a robust environment for developing secure, trusted, interoperable Web services. The Java libraries enable developers to create Java objects for sending and receiving XML messages in conjunction with a customer Web service API. (2) The trust layer provides APIs for security XML messages using public key infrastructure (PKI), and includes implementations of two key specifications, W3C XML Digital Signature and XML Encryption. These implementations emphasize ease-of-use over feature coverage... The Trust Verifier provides several mechanisms, including real-time XML Key Management Specification (XKMS) lookups, for establishing whether a public key or certificate chain is trusted. (3) The API also includes low-level resources for directly manipulating XML, building data types, navigating through document structures, validating the format of schemas and interfacing with parsers..."

• [November 22, 2002] "The 19th Annual Awards for Technical Excellence. 'Protocols' Winners: SAML and WS-Security." By the Editors of PC Magazine. In PC Magazine (November 19, 2002). "Securing Web services is no easy task. The same virtues that make Web services so promising for e-business -- they're platform-independent, text-based, and self-describing -- create major security concerns, giving pause to businesses considering a move to the hot new interoperability technology. Two standards are emerging to secure Web services: Security Assertion Markup Language (SAML) and WS-Security, both proposals submitted to the Organization for the Advancement of Structured Information Standards (OASIS). To protect confidentiality, WS-Security relies on XML Encryption, while SAML uses the slower HTTPS. WS-Security protects individual transactions, and the substantial infrastructure required by SAML pays off with single sign-on capability. The Liberty Alliance's authentication solution -- Liberty 1.0 -- builds on SAML, while Microsoft's competing technology, .NET Passport, uses WS-Security. No matter whether these two standards converge or remain separate, the success of Web services in e-business could depend on them..."

• [October 26, 2002] "Liberty, WS-Security Uniting Over SAML Standards." By Vance McCarthy. From Integration Developer News. October 21, 2002. Case Study. "Last month, the Liberty Alliance Project elected a new president Michael Barrett, vice president for Internet strategy at American Express. Since coming to office, Barrett has left little doubt that he will push those vendors sparring over identity and security standards -- notably Sun, IBM and Microsoft -- to reach an agreement on interoperability. So far, the 'peace talks' between Liberty and Microsoft Passport seem to be going well, thanks in large part to all-party discussions on security taking place under the OASIS (Organization for the Advancement of Structured Information Standards) umbrella, and some XML-based security brokering technology being specified inside OASIS called SAML (Security Assertion Markup Language). 'It's pretty obvious that we'll use SAML as a glue between different identity approaches [such as Liberty and Passport], the SAML technical committee co-chair for OASIS Jeff Hodges told Integration Developer News. 'And while SAML is not an authentication technology in and of itself, SAML can be used as a tool to glue together disparate authentication domains.' For its part, Liberty is built on SAML, but does not define any authentication mechanisms. SAML is a framework and one needs to profile it to put into context to make use of it. Further, the Java Community Process (JCP) has a proposal to natively support SAML (JSR 155) for use in J2EE... Of good news to developers worried about interoperability issues, SAML is also being endorsed by Microsoft execs. 'Members of the OASIS security committee wants to see all our work reconciled, and we want to see SAML token support in WS-Security.' Adam Sohn, a product manager for Microsoft .NET platform strategy group told IDN in an interview this summer. Sohn added that WS-Security's decision to support SAML (and Liberty) will not prompt WS-Security to 'downplay' plan to support a variety of security mechanisms already at work within the enterprise, including PKI, Kerberos and even SSL. WS-Security will look at Liberty and SAML as just another credential type, and we expect to have support in WS-Security this year' Sohn added... 'There are a lot of touching points across Liberty, SAML and WS-Security, and it's hard to look at a crystal ball to see exactly what will happen. But we are starting to see some convergences and rapprochement between all these groups, ' Slava Kavsan, Chief Technologist at RSA Security, and chairman of the Liberty Alliance's Trust and Security Group told IDN. Notably, RSA has been a key figure in pushing compatibility among Sun, Microsoft and IBM approaches. 'There is good news. First, WS-Security will mention SAML is its next draft.' Kavsan looks at the interoperability issues on identity as similar to other compatibility questions that exist on a number of web services fronts between IBM, Microsoft and Sun. 'We're still in a basic architectural world of the Microsoft client needing to talk to a Java or Sun server,' he said. 'Even though Liberty is working on its own browser-based client spec, Liberty needs to and intends to support Microsoft's client base'..."

• [October 22, 2002] "Understanding WS-Security." By Scott Seely (Microsoft Corporation). From MSDN Library. October 2002. ['This article looks at how to use WS-Security to embed security within the SOAP message itself, exploring the concerns WS-Security addresses: authentication, signatures, and encryption. This article assumes that you are already familiar with XML Canonicalization, XML Signature, and XML Encryption.'] "... the bigger problems involve sending the message along a path more complicated than request/response or over a transport that does not involve HTTP. The identity, integrity, and security of the message and the caller need to be preserved over multiple hops. More than one encryption key may be used along the route. Trust domains will be crossed. HTTP and its security mechanisms only address point-to-point security. More complex solutions need end-to-end security baked in. WS-Security addresses how to maintain a secure context over a multi-point message path. WS-Security addresses security by leveraging existing standards and specifications. This avoids the necessity to define a complete security solution within WS-Security. The industry has solved many of these problems. Kerberos and X.509 address authentication. X.509 also uses existing PKI for key management. XML Encryption and XML Signature describe ways of encrypting and signing the contents of XML messages. XML Canonicalization describes ways of making the XML ready to be signed and encrypted. What WS-Security adds to existing specifications is a framework to embed these mechanisms into a SOAP message. This is done in a transport-neutral fashion. WS-Security defines a SOAP Header element to carry security-related data. If XML Signature is used, this header can contain the information defined by XML Signature that conveys how the message was signed, the key that was used, and the resulting signature value. Likewise, if an element within the message is encrypted, the encryption information such as that conveyed by XML Encryption can be contained within the WS-Security header. WS-Security does not specify the format of the signature or encryption. Instead, it specifies how one would embed the security information laid out by other specifications within a SOAP message. WS-Security is primarily a specification for an XML-based security metadata container... WS-Security allows for a SOAP message to identify the caller, sign the message, and encrypt message contents. Whenever possible, existing specifications are reused to reduce the amount of invention required to securely deliver a SOAP message. Because all of the information is delivered within the message itself, the message becomes transport neutral. The message would be secure if it was delivered by HTTP, e-mail, or on CD-ROM..."

• [September 21, 2002]   Discussion Forum for Web Services Security Quality of Protection.    An OASIS discussion list has been created on the topic Web Services Security Quality of Protection. Subscribers to the 'WSSQoP-Discuss' list will discuss the possible creation of an OASIS Technical Committee. Sponsors of the proposal include representatives from CommerceOne, Cisco, Entrust, IBM, RSA Security, SAP, Sun Microsystems, and VeriSign; the discussion leader is Tim Moses (Entrust). The stated purpose of the TC under discussion would be "to identify candidate solutions for communicating the required security tokens and quality of protection for a Web service, taking advantage of the common service definition tools, such as WSDL. The solutions are intended to allow a service consumer to determine (1) how to produce a SOAP message including security tokens and protection mechanisms, in accordance with WSS, that is acceptable to both the provider and consumer, and (2) whether the consumer is capable of performing the required security processing on the response from a Web service. Components of security policy include at least the set of acceptable types of security token, the set of acceptable cryptographic algorithms, (optionally) what key to use for encryption, and the payload nodes to be protected. The topic is potentially open-ended, leading to solutions for trust policy, authorization policy, personal privacy policy, etc. While recognizing this, it is the intention to limit the identified solutions to those that address the QoP of the initial mechanisms of WSS. This is analogous to the 'cipher suites' and "supported algorithms" mechanisms of TLS and S/MIME, respectively. In addition, the group will identify candidate process models for producing a WSDL instance from a security policy definition, and producing a language-specific API from a WSDL instance..." [Full context]

• [September 19, 2002] "Federated Identity Face-Off." Interview by Stuart J. Johnston and Dan Ruby. In XML Magazine (October/November 2002). ['In a virtual debate, IBM's Bob Sutor and Sun's Simon Phipps pull no punches on competing federated identity management strategies.' See also the reference list for Federated Identity Resources] Excerpts: Now that WS-Security is in OASIS and has gained Sun's support, how do you see it evolving? [Phipps:] "We're very happy to have WS-Security brought into OASIS so that it can make a contribution to the ongoing security discussion. Microsoft and IBM have done an about-face and have introduced it as a royalty-free specification into OASIS, and we felt that that needed to be encouraged and embraced. So what we've been embracing, fundamentally, is the contribution more than the proposal. There are a couple of principles that we are committed to. One of them is working with open communities to evolve new marketplaces that are level playing fields. Sun is committed to doing that through OASIS, and the fact that the SAML work was already going on at OASIS means that we're deeply committed to SAML." [Sutor]: Now that it is in a standards body, we would expect WS-Security to morph -- you never know how much. We would certainly expect inputs from other people. Look at how we brought SOAP 1.1 to the W3C two years ago, and fairly soon now we expect a SOAP 1.2 to come out, and it's not exactly the same. A lot of what they're doing with SOAP 1.2 has to do with how you bind it to underlying transports. That wasn't fully expressed in SOAP 1.1. But this was an open effort and whatever the industry decided SOAP 1.2 needed, that was done..." Where are there points of overlap or competition between WS-Security and Liberty Alliance? [Sutor]: "Liberty is not a Web services spec. WS-Security defines a set of SOAP extensions, using SOAP just as it is designed. For example, it provides a convention for how to put a SAML assertion in a SOAP header, which will support Liberty as it defines its protocols, conventions, and workflow. From a Web-services perspective, WS-Security is the more fundamental spec..." [Phipps:] "Liberty is a movement by the users of network identity to specify what they need for vendors to provide for them. On the other hand, the ideas in WS-Security up until now were those developed in-house by a monopolist, and only then crossed the border into being a contribution to an open discussion. Liberty's proposed mechanism is comparable with the whole WS-Security road map that has been articulated. WS-Security is just a small piece of an architecture. It says nothing about how to federate..."

• [September 18, 2002] "IBM Supports WS-Security Spec in Products." By Richard Karpinski. In InternetWeek (September 18, 2002). "IBM on Wednesday detailed plans to begin supporting the recently announced WS-Security specification -- which it helped co-author -- in products including its WebSphere application server and Tivoli management platform. WS-Security provides a framework for securing Web services, from how to apply encryption and authentication technologies to how to ensure the integrity of Web services messages. The spec defines a series of SOAP extensions that add security features to the Web services protocol stack. IBM's move represents one of the first implementations of this important new spec, which just recently was placed on a standards track at the OASIS group... Security concerns are often cited as one of the biggest barriers to Web services adoption. The core Web services protocols, such as SOAP, do not have built-in security mechanisms, so enterprises need a way to secure SOAP messages they'll be sending over open networks like the Internet. Only until security issues are settled will Web services move beyond corporate firewalls. IBM said version 5 of its WebSphere application server will support WS-Security in the fourth quarter; Tivoli Access Manager will add support early next year. In addition to basic Web services security, IBM will add features to enable federated identity management capabilities to its software products, which will make it possible for users to more flexibly consume Web services..."

• [August 26, 2002]   Microsoft Announces Web Services Development Kit Technology Preview.    Microsoft has announced a technical preview for the Microsoft Web Services Development Kit (WSDK), which "provides the tools developers need to build advanced Web services applications using the latest Web services specifications, such as WS-Security, WS-Routing and WS-Attachments. The WSDK is a new Microsoft .NET class library for building Web services using the latest Web services protocols, including WS-Security, WS-Routing, DIME and WS-Attachments. The WSDK offers a low-level API that allows you to apply these protocols directly to individual SOAP messages being sent using HTTP. The library also integrates with the higher-level Microsoft ASP.NET Web service APIs (ASMX) included in the Microsoft .NET Framework. The design of the WSDK reflects the principles of the basic message-level protocols themselves, as outlined in the document 'Understanding GXA': Decentralization and federation; Modularity; XML-based data model; Transport neutrality; Application-domain neutrality... The WSDK incorporates Microsoft's recent work with industry customers and partners to develop Web services specifications beyond XML and SOAP, such as WS-Security, that address the core challenges of Web services in a way that is broadly interoperable across heterogeneous systems. The core features included in the technology preview of the Microsoft WSDK include (1) the ability to help secure XML Web services across platforms and trust domains, including digital signing and encryption of SOAP messages that are compliant with the WS-Security specification; (2) the ability to route an XML Web service through intermediaries using the WS-Routing specification; (3) communication between XML Web services can contain attachments that are not serialized into XML." [Full context]

• [July 23, 2002] "OASIS Forms WS-Security Committee." By Brian Fonseca. In InfoWorld (July 23, 2002). "Microsoft and IBM moved one step closer to turning their security specification into a standard on Tuesday. Clearing a significant hurdle for the WS-Security standard to gain recognition as a trusted means for applying security to Web services, standards body OASIS (Organization for the Advancement of Structure Information Standards) formed a technical committee to give vendors a crack at the immature specification. First published in April as part of a working partnership between Microsoft, IBM, and VeriSign, the WS-Security specification defines a standard set of SOAP extensions, or message headers, which can be used to set and unify multiple security models, mechanisms, and technology -- such as encryption and digital signatures for instance -- onto Web services applications which traverse the Internet. Aside from an initial WS-Security road map, the trio also proposed specifications yet to come that address a variety of other security, policy, messaging, and trust issues associated with Web services security. They include WS-Policy, WS-Trust, WS-Privacy, WS-Secure Conversation, WS-Federation, and WS-Authorization..."

• [July 10, 2002] "WS-Next: Plotting A Web Services Security Road Map." By Richard Karpinski. In InternetWeek (July 08, 2002). "When IBM, Microsoft, and VeriSign announced last week they planned to move their would-be WS-Security standard to the OASIS group, most of the attention went to the political gamesmanship. The trio had managed to convince Sun Microsystems to join the effort, avoiding a prolonged battle over how to add baseline security -- things like encryption and digital signature support -- to Web services... Most simply, WS-Security defines a set of Simple Object Access Protocol (SOAP) headers that can be used to implement security measures for Web services. The base WS-Security specification describes how to add encryption and digital signatures to Web services (in each case supporting a W3C working group effort, XML-Encryption and XML-Signatures, respectively.) WS-Security also defines a general mechanism for passing around arbitrary security tokens, though it doesn't define how those tokens work... The overall idea with WS-Security is to build a security stack in much the same way the industry built a basic Web services protocol stack with XML Schemas, SOAP, WSDL, and so forth. The concept of simplifying and consolidating Web services security efforts is also a key driver behind WS-Security... WS-Security and SAML: SAML defines a standard, XML-based approach for passing security tokens defining authentication and authorization rights. SAML is almost two years old now, which means it pre-dates the recent wave of interest in Web services. Originally, SAML was more about distributed authentication and single sign-on. But those concepts are also integral to Web services, and with both SAML and WS-Security now housed at OASIS, backers of the two specs are eyeing each other warily. According to Netegrity's Chanliau, the two security approaches will work together and ultimately give enterprises some important choices about how to secure Web services. For starters, SAML has quickly adopted WS-Security as the appropriate method for "binding" SAML assertions into SOAP messages. Version 1.0 of SAML is coming up to a vote this month; it is expected to be approved as standard by fall. SAML 1.0 won't include a SAML-over-SOAP definition today -- concentrating on http instead -- but Chanliau expects future versions of the SAML spec to adopt WS-Security..."

• [July 02, 2002] "WS-Security Takes Good Step Toward Being Web Service Standard." By Ray Wagner. Gartner Note Note Number: FT-17-3085. 02-July-2002. ['The Organization for the Advancement of Structured Information Standards (OASIS) will oversee the Web Services Security (WS-Security) specification and won't charge royalties. A good step toward standards, but challenges remain.'] "On 27-June-2002, IBM, Microsoft and VeriSign announced they will submit the latest version of the WS-Security specification to OASIS for development. WS-Security allows systems to interoperate in a platform- and language-neutral manner. Baltimore Technologies, BEA Systems, Cisco Systems, Documentum, Entrust, Intel, IONA Technologies, Netegrity, Novell, Oblix, OpenNetwork, RSA Security, SAP, Sun Microsystems and Systinet have all said they will participate in the OASIS development effort. Gartner believes this is a strong step toward making WS-Security an industry standard. The IBM/Microsoft/VeriSign alliance will make WS-Security royalty-free, a step that boosts its chances of becoming a standard. The participation of competitors and industry heavyweights such as BEA, Cisco and Sun also indicates an understanding of, and support for, standardized security mechanisms within Web services. Gartner urges all participants to continue cooperation on such standards. Gartner cautions enterprises, however, that Web services have important security issues that remain unresolved. Proposed Web service security mechanisms highly depend on the distribution of digital certificates and on the underlying trust that supports their use. Credentials will be available from many different sources, including enterprises' own products, and "meta-trust" issues remain. The lack of any guaranteed level of trust between enterprise Web service deployments will represent a major stumbling block to widespread deployment beyond the enterprise. This issue has slowed the acceptance of public key infrastructure for years and must be resolved for Web services to become ubiquitous beyond enterprise boundaries..."

• [June 27, 2002] "Sun Switches Gears On Encryption." By Wylie Wong. In CNET News.com (June 27, 2002). "Microsoft, IBM and VeriSign have submitted a security specification for Web services to an industry standards body, a move that has won the backing of an unlikely supporter: Sun Microsystems. WS-Security is a 2-month-old technology that encrypts information and ensures that data passed between companies remains confidential. Its three creators -- Microsoft, IBM and VeriSign -- said Thursday they have submitted the specification to a standards body called the Organization for the Advancement of Structured Information Standards (OASIS). Sun had been devising its own rival Web services security specification, but the royalty-free licensing of WS-Security specifications allayed Sun's concerns, a source familiar with the negotiations said. Sun will now focus all its development work on WS-Security and work with its rivals to improve the specification through the OASIS group, said Bill Smith, Sun's director of Liberty Alliance technology. 'They're taking WS-Security into a recognized, open industry organization, and Web infrastructure on a royalty-free basis is an important thing as well,' Smith said. 'You should expect Sun to actively participate in this forum. We will bring whatever we have that can help fill out WS-Security. This is where (the security work) is being done.' Sun's support of WS-Security alleviates concerns about a possible standards war over Web services security. Proponents of Web services have feared that industry squabbling could derail the much-hyped movement. Every software maker has touted Web services as the future of software because such services allow companies to interact and conduct business via the Internet. But Web services won't work unless the entire tech industry coalesces around a single set of standards. Analysts have said lack of security is the biggest obstacle to the adoption of Web services--and that WS-Security took a big step in addressing the issue. Besides WS-Security, IBM, Microsoft and VeriSign plan to build five more security specifications in the next year and a half to provide additional security measures that businesses may need for Web services. Although Smith declined comment on it, sources said Sun had been quietly working on its own security specification that was royalty free. Over the past several months, Sun executives had expressed concern that IBM and Microsoft might charge 'tolls' to developers -- in the form of royalties on patents -- for using two existing Web services specifications: the Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL). Neither Microsoft nor IBM has formally stated a desire to charge royalties on the standards, which are in part based on patents held by them..."

• [June 27, 2002] "WS-Security Specification Sent to OASIS." By Darryl K. Taft. In eWEEK (June 27, 2002). ['IBM, Microsoft and VeriSign announce they will push their Web services security standard through OASIS.'] "Moving ahead on promises made when they formed the initiative in April, IBM, Microsoft Corp. and VeriSign Inc. Thursday announced that they will submit the latest version of the Web Services Security (WS-Security) specification to the Organization for the Advancement of Structured Information Standards for ongoing development. The WS-Security specification is a leading Web services standards effort to support, integrate and unify multiple security models, mechanisms and technologies, allowing a variety of systems to interoperate in a platform- and language-neutral manner, the companies said. Eric Newcomer, chief technology officer of Iona Technologies Inc., in Waltham, Mass., and a founding member of the working group that will handle the WS-Security standards effort within OASIS, said from his perspective IBM and Microsoft grew 'impatient' with the efforts of the Worldwide Web Consortium (W3C) to deliver a standard around security and Web services... In addition to Iona, many OASIS member companies pledged support for WS-Security, including Baltimore Technologies plc., BEA Systems Inc., Documentum Inc., Entrust Inc., Netegrity Inc., Novell Inc., Oblix Inc., RSA Security Inc., SAP AG, Sun Microsystems Inc., Systinet Corp., Vodafone Group plc. and webMethods Inc... The WS-Security specification, which provides the foundation for that road map, defines a standard set of Simple Object Access Protocol (SOAP) extensions, or message headers, which can be used to implement integrity and confidentiality in Web services applications. Web services are applications that can be accessed through XML and SOAP-based protocols, making them platform- and language-independent. WS-Security provides a foundation layer for secure Web services, laying the groundwork for higher-level facilities such as federation, policy and trust."

• [April 12, 2002] IBM Web Services Toolkit Supports the WS-Security Specification. IBM alphaWorks Labs has released a new version of its Web Services Toolkit with support for the Web Services Security Specification (WS-Security) announced on 2002-04-11. Specifically, the v3.1 IBM WSTK additions "provide an implementation of SOAP Security Token and Digital Signature components of the WS-Security specification. The SOAP Security Token which indicates the message sender's properties (name, identity, credentials, and capabilities ) is passed with SOAP messages; this helps identify the message sender to the Web service provider. This modular technology is useful to Web service providers when they need to support users with different authentication mechanisms. It also enables Web services providers to incorporate additional security features to their Web services applications over time. Version 3.1 also features a Buyer-Seller demo, Business Explorer for Web Services, Web Services Management, WSDL Explorer, new utility services, WSIL4J, and support for the use of UDDI v2 registries. The Buyer-Seller demo uses various aspects of Web Services components such as WSDL, WS-Inspection, UDDI, AXIS, etc. in a standards-based J2EE runtime environment."

• [April 11, 2002] "Spec Secures Web Services Applications." By Peter Galli and Darryl Taft. In eWEEK (April 11, 2002). "Microsoft Corp., IBM and VeriSign Inc. have joined forces to develop and publish a new security specification for Web services that will form the foundation of their proposed Web services security architecture. The specification, which the parties say is the first such spec to be launched, will be known as WS-Security and is designed to help organizations build secure and broadly interoperable Web services applications. 'The spec is designed to enable message-level, SOAP-level security, specifically encryption, authentication and identity around those messages. What this will really enable is for Web services to communicate in a trusted manner, especially in a scenario where you have multiple actors in a Web service, where it will provide end-to-end security between all of those parties,' [said] Marcie Verdin, director of enterprise services at VeriSign... Bob Sutor, the director for eBusiness strategy at IBM, said the plan is to submit the specification to standards groups, but he declined to say which these would be. 'This is very broad, and no one standards organization is going to be able to do it. The W3C [World Wide Web Consortium] may be involved; we'll just have to wait and see'... 'This is the foundational specification for Web services security, in the same way that two years ago SOAP was a foundational specification', he added. Steven VanRoekel, the director of Web services marketing at Microsoft, said the specification is based on work that had already been done in the W3C around XML encryption and digital signatures. When asked about not including other industry players in the development of the specification, Sutor said, 'We have published several specifications together in the past like SOAP and WSDL [Web Services Description Language]. We put them out there and let the industry and partners comment on them. We plan to do the same with this and will only submit the spec to the standards bodies in a few months after we have received industry input.'... customers have been saying that while the technology is new and innovative, they are not going to use it for anything mission-critical across the Internet until they can be comfortable that their information is secure and stays confidential... IBM and Microsoft have also developed and are publishing a Web services security road map, titled 'Security in a Web Services World.' The document defines additional and related Web services security capabilities within the framework established by the WS-Security specification that Microsoft and IBM plan to develop ... The additional proposed specifications deal with security policies, trust relationships, privacy practices, the management and authentication of message exchanges between parties, trust in heterogeneous federated environments, and the management of authorization data and policies..."

• [April 11, 2002] "Microsoft, IBM, Verisign Team on Web Services." By Joris Evers. In InfoWorld (April 11, 2002). " Microsoft, IBM, and Verisign have devised a way to add integrity- and confidentiality-checking capabilities to upcoming Web services applications, a first step in a broader joint effort to secure Web services, the companies said Thursday. The jointly developed specification, dubbed WS-Security, defines a set of SOAP (Simple Object Access Protocol) extensions and describes how to exchange secure and signed messages in a Web services environment, providing a foundation for Web services security... In addition to the WS-Security specification, Microsoft and IBM said they plan to develop a range of security specifications for Web services together with key customers, partners, and standards organizations such as the W3C (World Wide Web Consortium) and the IETF (Internet Engineering Task Force). Six of the other proposed specifications are WS-Policy, WS-Trust, WS-Privacy, WS-Secure Conversation, WS-Federation, and WS-Authorization. These proposed specifications can be grouped in two categories, with the first three dealing with defining security policies, establishing trust relationships, and implementing privacy policies, and the last three handling the sending and receiving of messages sent between Web services..."

• [April 11, 2002] "Tech Giants Partner On Security Specs." By Wylie Wong. In CNET News.com (April 10, 2002). "Microsoft, IBM and VeriSign have teamed to create security specifications for Web services, a move analysts say will help drive adoption of the hyped but still emerging technology... they will release a new specification, called WS-Security, which will encrypt information and ensure that the data being passed between companies remain confidential. The companies, which are announcing the new security initiative at Microsoft's Tech Ed developer conference, also plan to build five more security specifications in the next 12 to 18 months that will provide additional security measures that businesses may need for Web services... WS-Security merges two different security specifications that Microsoft and IBM had worked on separately with help from VeriSign, said executives from the three companies. Microsoft released a security specification, also called WS-Security, in October, but the software giant built the original without collaborating with the other companies. The new version of WS-Security, which combines the work of IBM, Microsoft and VeriSign, is used as part of a SOAP message. It outlines how to use existing World Wide Web Consortium specifications called XML Signature and XML Encryption. "It ensures the message you received is the one that was sent and was not tampered with along the way," said Bob Sutor, IBM's director of e-business standards strategy. "You want to know that the message is from me and not someone spoofing my identity and counterfeiting messages to you." The three companies plan to eventually submit WS-Security to an industry standards body, but have not yet decided on the timing or the body that they will work with..."