When a standard is deployed as openly as XML, businesses are bound to have security concerns.

The need to control content’s distribution and ensure its integrity keeps many companies from deploying XML without an extranet. Proposed standards will address security issues, and these standards are being further developed to allow for granular control over XML content. This article introduces and explains five proposed XML standards that deal with security issues.

XML encryption (Xenc)
Besides being able to use standard methods of encryption when transmitting XML documents, the W3C and IETF propose a standard for encrypting the XML data and tags within a document. This would let you encrypt portions of a document, with the idea that only sensitive information needs to be protected. Encrypting portions of a document with different keys would allow you to distribute the same XML document to various recipients, but the recipients would only be able to decrypt the parts relevant to them.

Once an XML document has been encrypted with this method, a tag denoting the beginning and end of the encrypted information appears in the document, defined by "<EncryptedData>" tags that refer to the encryption namespace at W3C. Actual tag names are replaced with the tags "<CipherData>" and "<CipherValue>"; the data itself is displayed as the resulting encrypted string.

This proposed standard provides a granular level of control that lets the XML data provider control visibility based on audience. Also, because the data itself is encrypted, but not the file, it can still be recognized by XML parsers and handled accordingly.

To get more information about Xenc, visit the W3C’s March 4, 2002 Candidate Recommendation document.

XML signatures (XML-SIG)
XML signatures are closely related to encryption. Similar in concept to security certificate signatures, XML signatures are used to ensure that the content within an XML document hasn’t changed. To help compensate for typographical variations from file systems and parsers, XML signatures depend heavily on a concept called "canonicalization." This allows the signature to function in the expected variety of environments that XML documents encounter.

When a signature is applied to content, canonicalization uses the data and tags in the XML file to create a unique signature, ignoring less critical information such as line breaks and tab spaces. When a document is received, the client system performs an "XML signature decryption transform," which distinguishes between content that was encrypted prior to signing and content encrypted after signing. Anything encrypted after signing is decrypted, and data integrity is verified by applying the same canonicalization method to the content, comparing the result to the signature included in the XML document.

When used in conjunction with XML encryption, an XML signature ensures that the data sent is the data received, without compromising the concept of a targeted audience. To learn more, refer to the W3C’s February 12, 2002 Recommendation for XML Signature Syntax and Processing.

XML key management specification (XKMS)
The XKMS protocol is a proposed standard maintained by the W3C. It defines a way to distribute and register the public keys used by the XML-SIG specification. XKMS is made up of two parts: the XML Key Registration Service Specification (X-KRSS) and the XML Key Information Service Specification (X-KISS). X-KRSS is used to register public keys, and X-KISS is used to resolve the keys provided in an XML signature.

Several vendors, such as VeriSign, are heavily involved in this protocol and have developed toolkits and other applications to facilitate implementation of this specification.

Definition of this specification is still fairly loose, and the latest working draft, released March 18, 2002, is limited to requirements at this time.

XACML is a specification from OASIS that was formed to consolidate the efforts of various interested parties, such as IBM and the University of Milan. It’s used in conjunction with SAML (explained below), and it provides a means for standardizing access control decisions for XML documents. XACML (also referred to as XACL) is used to define whether to permit requested access to a resource, whether it’s an entire document, multiple documents, or a partial document.

XACML receives a SAML request to determine if access should be granted to a resource based on rule sets, or policies, that are defined by the provider. As opposed to XML encryption, access control information is kept in a physically separate repository that is referenced when a request is made. XPointers and XPaths are defined within tags in the XML resource that inform the parser to check the XACML policies and where to find them.

Once the policy is evaluated and returns a true or false value to indicate whether or not access is granted, an SAML authorization decision assertion is returned, which is then processed accordingly.

You can access the OASIS XACML Committee page for meeting minutes, case studies, and the latest working draft, created March 10, 2002.

Security assertion markup language (SAML)
SAML, also managed by OASIS, is the counterpart to XACML that handles the actual exchange of authentication and authorization requests and responses. An SAML request is sent, via SOAP over HTTP, to a system with the appropriate means for processing the request.

An SAML request contains information such as authentication username and password, or other details about the individual making the request. This information is then delivered to an application designed to process it with the intended goal of using XACML to allow or deny access to an XML resource.

SAML uses an "assertion schema" maintained by OASIS. Three general kinds of assertion statements can be used: authentication, authorization decision, and attribute. These three statements are used at various times in an application to determine who the requestor is, what they are requesting, and whether or not their request has been granted.

The latest version of this specification was released on May 31, 2002. You can find it at the XML-Based Security Services TC (SSTC) page on the OASIS Web site.

XML security: An ongoing process
While none of these specifications has been fully realized and adopted, both the W3C and OASIS are working hard to provide security standards for XML. A few early solutions are already available, such as Phaos XML from Phaos Technology and alphaWorks from IBM. Demand for XML security increases as XML usage spreads. Conventional means for securing documents interfere with XML’s ease of use, but standards to address an alternative are fast becoming a reality.