A communiqué from IBM, Microsoft, and Verisign to the OASIS WSS TC describes the submission of a WS-Security Profile for XML-based Tokens specification designed to supplement the existing WS-Security input specification. The authors request consideration of the specification by the WSS-TC, as the document "further clarifies how XML Tokens are used with WS-Security." The document "describes a general framework to enable XML-based security tokens to be used with WS-Security. Two profiles that use this general framework are provided: one for the Security Assertion Markup Language (SAML) and another for the Extensible rights Markup Language (XrML). Since these formats are described in standalone specifications, not unlike X.509 and Kerberos, the document describes their usage with respect to the WS-Security specification. The specification does not endorse any particular XML security token standard; the description of SAML and XrML are provided to show the mechanisms by which the bindings should be performed. Additional XML token formats may be added to the specification in future revisions as needed." A Web Services Security Addendum was submitted to the WSS-TC previously.

Bibliographic information: WS-Security Profile for XML-based Tokens. Version 1.0. August 28, 2002. Edited by Chris Kaler (Microsoft). By Phillip Hallam-Baker (VeriSign), Maryann Hondo (IBM), Chris Kaler (Editor, Microsoft), Hiroshi Maruyama (IBM), Anthony Nadalin (IBM), Nataraj Nagaratnam (IBM), Hemma Prafullchandra (VeriSign), and John Shewchuk (Microsoft. 11 pages.

Extract:

Attaching Security Tokens: The WS-Security specification defines the <wsse:Security> header as a mechanism for conveying security information with and about a SOAP message. This header is, by design, extensible to support many types of security information. The specification defines the <wsse:BinarySecurityToken> element as a mechanism for attaching security tokens that are represented by binary octet streams and therefore do not naturally lend themselves to XML. For security tokens based on XML, the extensibility of the <wsse:Security> header allows for these security tokens to be directly inserted into the header.

Processing Rules: The WS-Security specification describes the processing rules for using and processing XML Signature and XML Encryption. These rules MUST be followed when using any type of security token including XML-based tokens. Note that this does NOT mean that XML-based tokens MUST be signed or encrypted -- only that if signature or encryption is used in conjunction with XML-based tokens, they MUST be used in a way that conforms to the processing rules defined by the WS-Security specification.

Security Considerations: "In order to provide relying parties with the confidence that they can trust XML-based tokens, the issuers of those tokens should sign those tokens using the mechanisms outlined in this document. Signing XML tokens allows parties relying on them to be confident that the tokens haven't been forged or altered. It is strongly recommended that <saml:Assertion> and <xrml:license> elements used in WSSecurity header fields be signed (using either the token-signing mechanisms defined in the SAML or XrML specifications or the header-element signing mechanisms defined in the WS-Security specification, or both mechanisms) It should be noted that references to unsigned or unsecured tokens represent potential security holes and make increase attack opportunities.