By: Frederick Hirsch

November 28th, 2002

Reader Rating: 9.5

Executive Summary

Meeting security requirements for privacy, confidentiality and integrity is essential in order to move business online. With the growing acceptance of XML technologies for documents and protocols, it is logical that security should be integrated with XML solutions. The XML Security standards define XML vocabularies and processing rules in order to meet security requirements. These standards use legacy cryptographic and security technologies, as well as emerging XML technologies, to provide a flexible, extensible and practical solution toward meeting security requirements.

The XML Security standards include XML Digital Signature for integrity and signing solutions, XML Encryption for confidentiality, XML Key Management (XKMS) for public key registration, location and validation, Security Assertion Markup Language (SAML) for conveying authentication, authorization and attribute assertions, XML Access Control Markup Language (XACML) for defining access control rules, and Platform for Privacy Preferences (P3P) for defining privacy policies and preferences. Major use cases include securing Web Services (WS-Security) and Digital Rights Management (eXtensible Rights Markup Language 2.0 - XrML).

Introduction

Security has always been vitally important in the business world to ensure the integrity of content and transactions, to maintain privacy and confidentiality, and to make sure information is used appropriately. However, in today's web-based business environment, the means for providing that security have changed. Using physical security no longer works as well as it did in the past when all the computing resources were locked in a central computing room with all jobs submitted locally.

Efforts to create a single pervasive security infrastructure do not scale effectively to the Internet, due to the heterogeneous nature of hardware and software systems and to conflicting administrative, application and security requirements. There is too much to administer, too many applications, too many variations, and too rapid a pace of technology change to design a single infrastructure to meet all requirements effectively. Extensible standards are required that can adapt to changing requirements, that can incorporate new technologies while continuing to work with legacy technologies, and that can be deployed modularly as needed without requiring use of unnecessary portions. These standards should work well together, not replicate functionality, and should fit with new technologies to enable open distributed systems, application integration and content management.

An essential requirement of new security standards is that they work naturally with content created using eXtensible Markup Language (XML). XML is being adopted widely for a growing variety of applications and types of content. It is also forming the basis for distributed system protocols to integrate applications across the Internet, such as Web Services protocols. XML languages are text based and designed to be extended and combined. It should be natural to provide integrity, confidentiality and other security benefits to entire XML documents or portions of these documents in a way that does not prevent further processing by standard XML tools [ XMLRef ]. XML Security therefore must be integrated with XML in such a way as to maintain the advantages and capabilities of XML while adding necessary security capabilities. This is especially important in XML-based protocols, such as XML Protocol (XMLProt [1], Simple Object Access Protocol, SOAP [2]), that are explicitly designed to allow intermediary processing and modification of messages.

Older security technologies provide a set of core security algorithms and technologies that can be used in XML Security, but the actual formats used to implement security requirements are inappropriate for most XML Security applications. One reason is that these standards use binary formats that require specialized software for interpretation and use, even for extracting portions of the security information. A second reason is that these standards are not designed for use with XML and do not support common XML technical approaches for managing content, such as specifying content with uniform resource identifier strings (URIs) or using other XML standard definitions for locating portions of XML content (like XPath [ XPath [3] ]). In addition, some existing security technologies assume that security-specific software will be integrated with applications to enable security. In practice, this is not always the case due to the details of custom integration.

XML Security addresses these issues by defining a common framework and processing rules that can be shared across applications using common tools, avoiding the need for extensive customization of applications to add security. XML Security reuses the concepts, algorithms and core technologies of legacy security systems while introducing changes necessary to support extensible integration with XML. This allows interoperability with a wide range of existing infrastructures and across deployments.

XML Security reduces barriers to adoption by defining the minimum modular mechanisms to obtain powerful results. By employing existing technologies and enabling use of XML paradigms and tools, XML Security minimizes the need to modify applications to meet security requirements.

This document summarizes the key XML Security technologies and provides an overview of how they fit together and with XML. It should serve as a roadmap and basis for further exploration of the related specifications. Most of the specifications are early in the definition process and are currently undergoing rapid change, so the interested reader is encouraged to turn to the specifications himself to learn the latest details.

This article assumes a basic understanding of XML and security concepts, but in order to provide a starting point, it presents a very brief introduction to those two subjects. This is followed by an overview of the following core XML Security standards:

• Integrity and signatures - XML Digital Signature
• Confidentiality - XML Encryption
• Key Management - XML Key Management Specification (XKMS)
• Authentication and Authorization Assertions - Security Assertion Markup Language (SAML)
• Authorization Rules - XML Access Control Markup Language (XACML)

as well as major XML Security applications:

• Web Services Security - Roadmap and WS-Security
• Privacy - Platform for Privacy Preferences (P3P)
• Digital Rights Management - eXtensible Rights Markup Language 2.0 (XrML)

XML

The XML specification [ XML [4] ] defines a syntax and rules for using tags to structure information. Anyone can define a vocabulary of element tags and attributes to structure information of interest. By following the rules defined in the XML specification, they may create "well-formed" XML, XML that may be processed by common XML tools. They may also explicitly define the structure of the documents they have defined, by creating an XML Schema or Document Type Definition (DTD). This allows documents to be validated.

XML languages created by different people may be combined. If you define a language for expressing addresses, for example, and I define one for purchase orders, I may reuse your address language within my purchase order language. To associate elements with the appropriate schemas and to avoid conflicting elements, XML namespaces may be used. XML namespaces associate tags with unique identifiers (URIs) and may be used to avoid ambiguity [ Namespaces [5] ]. A well-formed XML document may be processed using general XML-aware tools, including parsers that understand the general rules of XML syntax and processing. An advantage is that use of these tools does not depend on the specific vocabulary defined in a particular document. This means that once general tools have been created they may be used for many applications of XML. This allows reuse of tools and training, another advantage of XML.

Many XML languages have already been defined, including XHTML [6] for creating web pages, DocBook [7] for creating technical documentation, RSS [8] for content distribution (syndication), RDF [9] for representing information, MathML [10] for mathematics markup, BRML [11] for business reports, and many others.

The following example shows a language for managing office medical records, including XML elements like <PatientRecord>, <Name> and <Diagnosis>. It also shows the use of an XML Namespace associated with a lab, to allow a <lab:Diagnosis> element that does not conflict with the office <Diagnosis> element.

<PatientRecord  
 xmlns="http://www.medical.org/"  
 xmlns:lab="http://www.lab.org/">  
    <Name>John Doe</Name>  
    <Account>123456</Account>  
    <Visit date="10pm March 10, 2002">  
         <Diagnosis>Broken second metacarpal</Diagnosis>  
         <lab:Diagnosis>  
           <lab:Xray>encoded xray image</lab:Xray>  
         </lab:Diagnosis>  
    </Visit>  
</PatientRecord>
Example 1 - Sample XML Document With XML Namespaces

Security

Security is vital to online business. Technologies designed to meet security requirements have evolved, but the requirements have remained relatively constant. These requirements include Authentication, Authorization, Integrity, Signature, Confidentiality, Privacy and Digital Rights Management and are briefly summarized below:

Authentication - Who is it?

Determine the identity or role of a party attempting to perform some action such as accessing a resource or participating in a transaction. A role may be appropriate to many parties, for example "Human Resources Person".

Authorization - What can they do?

Determine whether some party is allowed to perform a requested action, such as viewing a web page, changing a password, or committing an organization to a 10 million dollar transaction.

Integrity - Ensure that information is intact

Ensure that information is not changed, either due to malicious intent or by accident. This may be information transmitted over a network, such as from a web browser to a web server, information stored in a database or file system, or information passed in a web services message and processed by intermediaries, to give a few examples.

Signature - Create and verify electronic signatures analogous to handwritten signatures

Produce or verify an electronic signature intended to be the equivalent of a handwritten signature. Such a signature may be used for different purposes such as approval, confirmation of receipt, acceptance or agreement.

Confidentiality - Make content unreadable by unauthorized parties

Ensure that content may only be viewed by legitimate parties, even if other access control mechanisms are bypassed. Confidentiality is generally associated with encryption technologies, although other approaches such as steganography (information hiding) might serve a similar purpose.

Privacy - Limit access and use of individually identifiable information

Personally identifiable information is required by individuals and companies in order to perform services for the individual. An example is a Doctor's office that requires medical records to track a patient's health. Privacy relates to control over what is done with this information and whether it is redistributed to others without the individual's knowledge or consent. Privacy may be managed by a combination of technical and legal means. Confidentiality technology may be used to protect privacy, but cannot prevent inappropriate sharing of information.

Digital Rights Management - Limit use and sharing of content according to license agreements

Ensure that content is used according to license agreements. Generally access rules are incorporated with the content, and enforcement controls are integrated with the clients needed to use the content.

Traditionally, security technologies have required applications to be security or Public Key Infrastructure (PKI) "enabled". This often involves integrating specialized security code with the application in order to meet security requirements. This created a slow, cumbersome and inflexible customization process. An alternative is to create generic XML tools and generic XML Security and then allow them to be used with a variety of XML applications. This allows generic XML Security filters to be applied to arbitrary content without requiring extensive customization for each application, reducing costs and delay.

XML Security

XML Security standards provide a set of technical standards to meet security requirements. These standards are designed to conform to common XML paradigms. The XML Security standards leverage existing XML standards and also enhance XML standards as follows:

1. The XML Security standards define XML vocabularies for representing security information, using XML technologies, such as XML Schema, for definition. An example is the <KeyInfo> element defined in the XML Digital Signature recommendation for carrying signing or encryption key information. This definition is used in a number of the specifications. The specifications define a shared meaning for the XML vocabularies.
2. The XML Security standards use other existing XML standards where possible to leverage current XML efforts. For example, XML Digital Signature allows XPath expressions to extract portions of XML for processing (Defined in [ XMLDigSig [12] ] and extended in [ XPathFilter [13] ]).
3. The XML Security standards are designed to offer the flexibility and extensibility aspects of XML. They allow security to be applied to XML documents, to XML elements and element content, as well as to arbitrary binary documents. They support extending the XML vocabularies through the use of XML namespaces and extensible XML Schema definitions.
4. XML Security technologies may be applied to end-end security, which is especially important when XML messages are routed through a number of processing intermediaries. Persistent security is associated with the content, rather than with a transport pipe. The security remains with the content. XML Security technologies may be used in conjunction with transport security technologies, such as SSL/TLS, as well.
5. XML Security technologies reuse existing cryptographic and security technologies whenever possible, without reinventing the wheel. For example, X.509 V3 certificates [ X509Cert [14] ] are used without redefinition when needed - they are simply encoded in a text format. Existing algorithms, such as the SHA1 digest algorithm, are also brought into the XML Security standards world by associating unique URI identifiers with them and defining how they may be used in the XML Security processing models.

The following sections present an overview of the core XML Security standards that are designed to provide XML-compatible technology to meet security requirements. This is followed by some important XML security standards for applying this technology to areas like Web Services and Digital Rights Management.

Core XML Security Standards

The core XML Security standards are:

1. XML Digital Signature for integrity and signatures,


2. XML Encryption for confidentiality,


3. XML Key Management (XKMS) for key management,


4. Security Assertion Markup Language (SAML) for making authentication and authorization assertions, and


5. XML Access Control Markup Language (XACML) for stating authorization rules.

The XML Digital Signature recommendation is particularly important; since, as the first XML Security recommendation, it established an approach as well as some vocabulary shared by the other standards. (The <KeyInfo> element defined in the XML Digital Signature recommendation is an element used by other standards, for example.) Signature functionality is also critical for content integrity, so XML Digital Signatures are also incorporated in the other security standards.

Each standard defines the XML vocabulary necessary for describing the security information required for that aspect of security, as well as the processing rules necessary to understand how to apply the standard.

Integrity & Signatures: XML Digital Signature (XML DigSig)

Purpose and Benefits

Digital signatures are useful for two purposes:

1. To provide persistent content integrity, and


2. To create and verify portable electronic signatures

Persistent integrity enables the user of content to detect unexpected changes to the content, whether malicious or accidental. Unlike a simple checksum, a digital signature associates a digest of the content with the signer of the content using a cryptographic technique. A digest is a digital "fingerprint", a short fixed-length value that is unique to the content and impractical to determine without the content. Using a cryptographic technique with the digest makes it hard for anyone other than the original signer to change the content without detection. Persistent integrity offers the benefit that content is not only protected in transit, but also when stored and processed.

Electronic signatures offer the digital equivalent of handwritten signatures and may be used for a variety of purposes such as content approval, receipt confirmation, and contract agreement. Using digital signatures makes it possible to move business workflows online, without requiring manual approval steps. This can reduce the delays, costs and inconveniences caused by geographic separation and time zone differences. Digital signatures use cryptographic techniques to construct signatures that are stronger and more portable than other techniques for creating "electronic signatures".

Features

The XML Digital signature recommendation defines mechanisms to support the full range of digital signature creation and verification, including the ability to sign and verify:

1. Entire XML documents as well as element and element content portions of XML documents,


2. Arbitrary documents, including binary documents,


3. Compound documents including multiple documents and/or XML elements and element contents,


4. Properties to be included with a signature,


5. Counter-signatures (signatures that include other signatures)

In addition, the XML Signature recommendation supports the application of multiple XML Signatures to an XML document or to different sections of a document, supporting a variety of use cases. The XML Digital Signature specification and related specifications (XML Canonicalization [15]) also define techniques so that signature verification can be robust even with variations allowed in XML, such as whitespace. The reason for the concern is that cryptographic algorithms are concerned with exact text, yet XML allows some flexibility. Canonicalization is used to reduce variations so that all XML Security applications can interoperate.

An XML <Signature> element may be handled in different ways, based on the desired application. It may be placed in a document apart from what is signed. This is known as a "detached" signature, and is used when signing non-XML content. When XML content is signed, the <Signature> element may be added to the XML. This is convenient, since signatures may then be bundled within the content and remain embedded with it, making it easy to keep track of them. When placed in an XML document, the <Signature> element may be added to the document being signed under the document element (an "enveloped" signature). In some cases, it is useful to place the content being signed within the <Signature> element, an example being a signature property (an "enveloping" signature).

If a signature is added to the <PatientRecord> as an enveloped signature, for example, the <Signature> element would be a child of the <PatientRecord> as follows:

<PatientRecord xmlns="http://www.medical.org/">  
   <Name>John Doe</Name>  
   <Account> 123456 </Account>  
   <Visit date="10pm March 10, 2002">  
       <Diagnosis> Broken second metacarpal </Diagnosis>  
   </Visit>  
   <Signature xmlns='http://www.w3.org/2000/09/xmldsig#'>  
       ...    
   </Signature>  
</PatientRecord>
Example 2 - Enveloped Signature

When a signature is added to a document as part of the document, it changes the document. To verify the signature, it is necessary to compare the original document without the signature. The XML Digital Signature recommendation defines a mechanism for removing the <Signature> as part of the verification process.

Another possibility is to create a new XML document with a <Signature> document element and to place the signed element as a child of the <Signature> element. This is usually reserved for information associated with a signature, such as the purpose of the signature, for example:

<Signature xmlns='http://www.w3.org/2000/09/xmldsig#'>  
   <SignedInfo> ... </SignedInfo>  
   <SignatureValue> ... </SignatureValue>  
   <Object>  
       <SignatureProperties>  
           <p:Purpose xmlns:p="http://www.myexample.com/schemas">  
             Approval  
           </p:Purpose>  
       </SignatureProperties>  
   </Object>  
</Signature>
Example 3 - Enveloping Signature

Key Concepts

The following concepts are central to understanding XML digital signatures:

1. A signature is only valid if the signed content has not changed. This content is represented using a short, fixed-length digest, designed to change if the content changes. Thus a signature will only be valid if a digest used to create a signature is the same as a digest used to verify it later. A verifier can create a digest to see if it is the same.
2. An XML <Signature> element is an XML structure that contains a cryptographic signature value in a <SignatureValue> element as well as an XML structure that has been signed, the <SignedInfo> structure. This means that the contents of the <SignedInfo> structure should not change for the signature to be valid.
3. The signer creates a <Reference> for each item to be included in a signature. Each <Reference> includes a digest of the item and a unique identifier (URI) for the item. It also identifies how to recreate the digest, specifying the algorithm and other necessary information. Each Reference is part of the <SignedInfo> structure.
4. To verify a signature, a recipient must validate each <Reference> by independently generating the same digest for the item. The verifier may use the URI to aid locating the item, and the algorithm information to know how to generate the digest. If the item has not changed, the digest should be the same.
5. A reference may refer to anything using a URI, including non-XML content such as image and text files. It is not required to obtain the item using the URI, but it is often useful. A special form of URI may be used to refer to XML elements within the same document as the signature, allowing signatures to be transferred along with XML content to be signed.
6. A <Reference> may specify one or more transforms to be applied to an item before creating the digest. One use is to sign parts of an XML document that are known not to change - such as boilerplate for example. This may be done by defining transform to extract the portion of the document to be signed, using standard XML XPath expressions for example.
7. Digest algorithms require content to be exactly the same to produce the same digest. Even a minor change that does not change the meaning, such as adding an extra space, will invalidate the digest. XML, on the other hand, allows some variation in the syntax of the XML text without changing the document. In other words, two XML documents may be considered the same even if they do not have the exact same text. For example, one XML document may use single quotes for an attribute and another double quotes. These are the same to an XML parser, but very different to a digest algorithm. There is an entire list of such potential issues for digests. To get around this problem, a Canonicalization transform may be used, one that converts any XML document to a form using a single set of rules, such as always using a certain type of quote for attributes.

Examples

Once created, an XML Digital Signature may be stored separately from the signed content (a detached signature) or embedded within the XML content that was signed (enveloped signature). In fact, signed content may also be placed within a signature itself (enveloping signature). To continue with the earlier PatientRecord example, suppose that the entire PatientRecord is to be signed by the Doctors office, and the signature is to be maintained as part of the PatientRecord. This would produce the following result, showing the layout of an XML Signature:

<PatientRecord xmlns="http://www.medical.org/">    
 <Name>John Doe</Name>    
 <account id="acct">123456</Account>    
 <Visit date="10pm March 10, 2002">    
   <Diagnosis>Broken second metacarpal</Diagnosis>    
   <lab:Diagnosis>    
     <lab:Xray>xhzhez</lab:Xray>    
   </lab:Diagnosis>    
 </Visit>    
 <Signature xmlns='http://www.w3.org/2000/09/xmldsig#'>    
       
   <!-- the SignedInfo element and all it contains    
        is what is signed -->    
   <SignedInfo>    
         
     <!-- Canonicalization is used to ensure    
          that XML is handled consistently    
          by different XML processors    
          in light of white space and other    
          variations. -->    
     <CanonicalizationMethod algorithm="URI for algorithm" />    
         
     <!-- the SignatureMethod is protected    
          by the signature, avoiding substitution    
          attacks and defines how the signature    
          is created  -->    
     <SignatureMethod    
Algorithm="http://www.w3.org/2000/07/xmldsig#rsa-sha1" />    
         
     <!-- each item to be signed, XML document,    
          portion of XML document or arbitrary    
          content is represented using a    
          Reference. Each Reference contains    
          a digest of the item, a URI to    
          refer to the item, and possibly    
          transforms to apply to the item    
          before creating the digest  -->    
     <Reference URI="">    
       <Transforms    
Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710" />    
       <DigestMethod    
Algorithm="http://www.w3.org/2000/07/xmldsig#sha1" />    
       <DigestValue>    
         Short, fixed-length "fingerprint" of referenced item    
       </DigestValue>    
     </Reference>    
   </SignedInfo>    
   <SignatureValue>    
     encoded output of signature algorithm    
   </SignatureValue>    
       
   <!-- Optional KeyInfo used to convey key    
        information needed to verify    
        signature -->    
   <KeyInfo>    
     <KeyName>Sally Smith's Integrity Key</KeyName>    
   </KeyInfo>    
       
   <!-- optional Object to allow additional    
        information to be associated with    
        signature, such as meta information    
        for example (time and purpose of    
        signing) -->    
   <Object>    
     <SignatureProperties>    
       <p:Purpose xmlns:p="http://www.myexample.com/schemas">    
         Integrity    
       </p:Purpose>    
     </SignatureProperties>    
   </Object>    
 </Signature>    
</PatientRecord>
Example 4 - Detailed XML Signature Example

Note that there is a single reference with URI "", meaning "this document". If only the <Account> element were to be signed, it could be referenced using the id attribute value, as follows: <Reference URI="#acct">. If there was no id attribute (perhaps signing wasn't anticipated), an XPath expression could be used, producing the following <Reference>:

<Reference URI="">    
   <Transforms>    
       <Transform    
Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">    
           <XPath>    
               /PatientRecord/account    
           </XPath>    
       </Transform>    
       <Transform    
Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710" />    
   </Transforms>    
   <DigestMethod    
Algorithm="http://www.w3.org/2000/07/xmldsig#sha1" />    
   <DigestValue> kjsdf </DigestValue>    
</Reference>
Example 5 - Reference Transform Using XPath

Confidentiality: XML Encryption (XML Enc)

Purpose and Benefits

The XML Encryption recommendation defines an XML vocabulary and processing rules enabling confidentiality to be applied to a variety of content. XML Encryption serves the purpose of maintaining the confidentiality of information, both while in transit as well as when stored. Other technologies for confidentiality such as secure sockets layer (SSL)/transport layer security (TLS) or virtual private networks (VPNs) only provide confidentiality while the information is in transit, not while it is stored at a server.

The owner of content may encrypt it to make it confidential. This will make the content unintelligible until it is decrypted. Encryption is generally performed using symmetric key encryption, since this is an efficient technique even for large documents. Symmetric key encryption uses the same key for both encryption and decryption. To send confidential information to a receiver, the sender must also share the symmetric key with the recipient but not anyone else. This can be difficult without person to person contact.

To avoid this problem and make it easier to share confidential content with a number of people, asymmetric or public-key cryptography was designed. Public key cryptography uses a matched pair of keys, one for encryption and one for decryption. This allows the sender to encrypt using the recipient's public key, a key that can be shared widely. Decryption requires use of the recipient's private key, known only to them. This helps address the difficulty of establishing confidential communication. Because public key cryptography is less efficient than symmetric cryptography, they are typically used together. The symmetric key is used to encrypt the content, and then the symmetric key is encrypted using public key cryptography. Both the encrypted content and encrypted symmetric key are then sent to the recipient.

To summarize, the sender may send content confidentially using the following steps:

1. Encrypt the content using a symmetric key


2. Encrypt the symmetric key using the recipient's public key


3. Package the encrypted content, encrypted key and necessary algorithm information together


4. Send the package to the recipient

The recipient may obtain the original content using the following steps:

1. Unpack the package to obtain the algorithm information, the encrypted symmetric key and the encrypted content


2. Decrypt the symmetric key with their private key


3. Decrypt the content with the symmetric key

Features

The XML Encryption recommendation defines the framework and processing rules for XML encryption and decryption. It defines an XML vocabulary for packaging all the information needed to process encrypted content, such as encryption algorithm and parameters, information about keys, and encrypted content. The XML Encryption recommendation supports the following features:

1. XML and non-XML content may be encrypted, giving broad applicability to the recommendation.
2. Confidentiality may be applied at a fine level of granularity to XML content. It may be applied to XML elements and XML element content as well as entire XML documents. This is valuable for securing portions of XML Protocol messages to be routed through intermediary processors.
3. XML Encryption produces well-formed XML from well-formed XML. This allows portions of XML content to be encrypted yet subsequently processed by XML tools.
4. XML Encryption is compatible with and may be used in conjunction with XML Digital Signatures.
5. XML Encryption allows for encryption of a symmetric key that may be packaged with encrypted content.
6. XML Encryption supports a variety of encryption algorithms and techniques.

Key Concepts

1. When an XML element or element content is encrypted, it is replaced by an <EncryptedData> element.
2. When non-XML content is encrypted, the result is a new XML document containing an <EncryptedData> element.
3. An <EncryptedData> element may include a Type attribute to assist the recipient in decrypting it. This Type may indicate that an XML element or element content was encrypted, or give the type of other information, such as images for example. This is done using an existing standard for mail attachments, known as MIME types.
4. The <EncryptedData> element defines the algorithm used for encryption, provides the encrypted content, and may include information necessary to determine the key needed for decryption.
5. The symmetric key used to encrypt content may be conveyed in an <EncryptedKey> element.
6. XML Encryption supports the selection of appropriate encryption algorithms and defines XML identifiers for common cases and may be extended for others.
7. Definitions for identifying key information are based on XML Digital Signature definitions and extended.
8. User-defined properties may be associated with an encrypted element, such as a timestamp or log reference.
9. The actual cipher text, the result of encryption, is specified using a <CipherData> element. This may contain the actual encrypted data within a <CipherValue> element, or a URI reference to encrypted data that is stored elsewhere (<CipherReference>). A reference is useful when the encrypted data is large and not needed by most parties, such as processing intermediaries.

An important issue in XML Security is the interaction of XML Digital Signatures and XML Encryption. Suppose you receive a document with an XML Signature and an <EncryptedData> element as in the following:

<PatientRecord    
 xmlns="http://www.medical.org/"    
 xmlns:lab="http://www.lab.org/">    
   <Name> John Doe </Name>    
   <Account> 123456 </Account>    
   <EncryptedData Type='element'>    
       ...      
   </EncryptedData>    
   <Signature>    
       <SignedInfo>    
           <Reference URI="">    
               ...    
           </Reference>    
       </SignedInfo>    
   </Signature>    
</PatientRecord>
Example 6 - Encrypted and Signed Document

In this case, the signature indicates that it applies to the entire <PatientRecord> document, since the <Reference> URI is "". This raises the question: did the signature or the encryption come first? This is important to know, since a signature can only be verified as correct if the content has not changed. If a portion of the document was encrypted after signing, the signature will not verify unless the encrypted portion is decrypted first. Knowing the order of encryption and decryption is essential in order to know how to verify the signature. The XML Encryption Transform recommendation [ XMLDecTrans [16] ] defines a solution. When signing, the signer must identify which <EncryptedData> elements are present as part of the signature. This allows a signature verifier to explicitly know which <EncryptedData> elements must be decrypted before verifying a signature.

There are additional security issues raised by XML Encryption, particularly those of "known plaintext attacks". If it is known that particular text was encrypted, such as an element (such as <Visit>, for example) it can make it easier to break the encryption. Because XML is verbose, and the names of elements may be known from the schema definition of the XML vocabulary, it is more likely that plaintext attacks are possible. As a result, additional care must be taken in choosing the encryption algorithms and their parameters to prevent use of this information from removing confidentiality.

Examples

Use of both <EncryptedData> and <EncryptedKey> elements may be summarized using the previous example where the account information is encrypted for confidentiality. Additional information on the EncryptedData and EncryptedKey portions of this example are explained in the XML Encryption candidate recommendation [ XML Enc [17] ]:

<PatientRecord    
 xmlns="http://www.medical.org/"    
 xmlns:lab="http://www.lab.org/tests">    
 <Name>John Doe</Name>      
 <EncryptedData    
Type='http://www.w3.org/2001/04/xmlenc#Element'    
xmlns='http://www.w3.org/2001/04/xmlenc#'>    
   <EncryptionMethod    
Algorithm='http://www.w3.org/2001/04/xmlenc#3des-cbc'/>      
   <ds:KeyInfo    
xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>      
     <EncryptedKey Id='EK'    
xmlns='http://www.w3.org/2001/04/xmlenc#'>    
       <EncryptionMethod    
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />      
       <ds:KeyInfo    
xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>      
         <ds:KeyName>    
           Dr Kutter's public key pair    
         </ds:KeyName>    
       </ds:KeyInfo>      
           
       <CipherData>    
         <CipherValue>xyzabc</CipherValue>    
       </CipherData>      
           
       <CarriedKeyName>    
         Dr Kutter's symmetric key    
       </CarriedKeyName>    
     </EncryptedKey>      
         
     <ds:KeyName>    
       Dr Kutter's symmetric key    
     </ds:KeyName>    
   </ds:KeyInfo>      
       
   <CipherData>    
     <CipherValue>a17xj2z</CipherValue>    
   </CipherData>    
 </EncryptedData>      
     
 <Visit date="10pm March 10, 2002">    
   <Diagnosis>    
     Broken second metacarpal    
   </Diagnosis>    
       
   <lab:Diagnosis>    
     <lab:Xray>xhzhez</lab:Xray>    
   </lab:Diagnosis>    
 </Visit>      
     
 <Signature xmlns='http://www.w3.org/2000/09/xmldsig#'>      
   <SignedInfo>      
     <SignatureMethod    
Algorithm="http://www.w3.org/2000/07/xmldsig#rsa-sha1" />      
         
     <!-- signature on entire PatientRecord    
          before encryption is default interpretation -->      
     <Reference URI="">    
       <Transforms    
Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710" />      
       <DigestMethod    
Algorithm="http://www.w3.org/2000/07/xmldsig#sha1" />    
       <DigestValue>kjsdf</DigestValue>    
     </Reference>    
   </SignedInfo>    
       
   <SignatureValue>xjksdasd</SignatureValue>    
       
   <KeyInfo>    
     <KeyName>Sally Smith's Integrity Key</KeyName>      
   </KeyInfo>      
 </Signature>      
</PatientRecord>
Example 7 - Detailed XML Encryption Example

Key Management: XML Key Management Specification (XKMS)

Purpose and Benefits

The XML Key Management Specification (XKMS) [ XKMS [18] ] defines protocols for Public Key management services. Public Key management includes the creation of a public and private key pair, the binding of this key pair with identity and other attributes, and the representation of this key pair in different formats, such as by key name, digital certificate or key parameters, to give some examples. Public key technology is an essential part of XML Digital Signatures, XML Encryption and other security applications. When signing, the private key is used to sign and the public key is used to verify signatures. When encrypting, the public key is used to encrypt and the private key is used to decrypt. In either case the private key must be maintained under control of the owner and the public key may be shared with others. XKMS is designed to help manage the sharing of the public key to enable signature verification and encrypting for recipients.

Public Key management usually requires a registration step in which the key pair is generated and some sort of token is issued to associate the public key with the identity and other attributes of the owner. This registration step usually incorporates some sort of due diligence to reduce the risks of associating the public key incorrectly, since people will rely upon the key pair later. Management also includes the ability to revoke the association of information with the key pair should circumstances change, such as the theft of the private key or a change in the owner's attributes (no longer an employee, for example). Likewise, information bound to the key pair may be updated. Traditionally, such bindings were managed using X.509 Digital Certificates, specialized protocols and public key infrastructures. XKMS defines XML message formats to support requests and responses for public key management, including registration, revocation and updates. This eliminates the need for applications to support other specialized public key registration and management protocols.

Once registration is complete, a public key pair may be used for signing and verification or encryption and decryption. The <KeyInfo> element defined in the XML Digital Signature recommendation may be used to provide information to the recipient of a digital signature or encrypted data block about the key needed to process that content. This information may take on a number of different forms, such as a key name, a digital certificate containing the public key, a set of key parameters, or a URI indicating where to obtain the public key. Given the variety of choices for providing information about a key to a recipient, it may be hard for an application to process and locate a key. In addition to the difficulty of anticipating all formats, some, such as X.509 certificates, require special cryptographic code and logic for processing. XKMS provides an XML message format to allow this processing to be performed by a service which will sort through the various options, determine the one that was used, and provide the key information to the recipient in a useful form.

Features

The XML Key Management Specification (XKMS) defines three specifications:

• XML Key Registration Service Specification (XKRSS),
• XML Key Information Service Specification (XKISS)
• Protocol Bindings

These specifications define the XML request and response messages necessary for registering and managing information associated with public keys and for ensuring that security requirements are met.

The registration service supports the binding of information with a public key pair, either one generated by the server or by the client. The binding associates information with the key pair, creating a <KeyBinding> element. This binding may have a validity period associated with it and may be reissued or revoked. The private key associated with a key binding may also be backed up recovered if the local copy is destroyed (as when an operating system requires reinstallation).

The key information service allows a client to request information associated with a <KeyInfo> element. This may include:

1. Locate - Resolve the <KeyInfo> element to return requested key information


2. Validate - Locate key information and provide an assertion on the validity of the binding to the key pair.

A key information request may specify the form of key information to be returned. For example, it may request that a <KeyName> and <KeyValue> be determined from a <KeyInfo> element. As part of this process, the server may perform validation to assert the validity of the binding to the key.

The Protocol Bindings specification defines mechanisms for meeting security requirements, including mechanisms to ensure message confidentiality, integrity, and security. This includes the following definitions:

• A two phase protocol to avoid replay attacks
• Pending response protocol
• Use of payload security
• Use of transport security such as SSL/TLS
• Use of Web Services security (see below)

Key Concepts

Important points about the XKMS specification are:

1. This specification defines XML protocol messages to convey key registration and information requests to a trust server and to convey responses from the server. The specification defines a binding of these messages to the XML Protocol (SOAP) and defines the relationships among the messages using the Web Services Definition Language (WSDL).
2. <ds:KeyInfo> processing is delegated to the trust service by the client, minimizing the complexity of the client. How the trust service is implemented is dependent on the service, but acting as a front-end to a public key infrastructure (PKI) is one possibility.
3. The XML Key Information Service Specification (XKISS) includes online status functionality equivalent to that in traditional PKI OCSP protocols as part of the Validate functionality.
4. Registration supports the requirements of smart card manufacturing, including bulk processing and pending responses.
5. The specification supports the use of XML Digital Signatures for message integrity and authentication. The specification also defines other authentication mechanisms, support for proof of key ownership and other security functionality.
6. A Locate or Validate request may include a <KeyInfo> element and <RespondWith> element in the request. The <RespondWith> element is used to specify what the <KeyInfo> element is to be resolved to, possibly more than one item. For example, the request <KeyInfo> might contain an X.509 certificate and the <RespondWith> might indicate that the KeyName and KeyValue are to be returned. Possibilities include KeyName, KeyValue, and Certificate, Certificate Chain (collection of certificates needed to trace a signature back to a trusted party) among the possibilities outlined in the specification.
7. A <KeyBinding> element is used to associate information with a key. This is what is returned in a Locate or Validate response. Every <KeyBinding> includes a <ValidityInterval> (NotBefore, NotOnOrAfter) and may also include <KeyInfo>, <ProcessInfo> (opaque data), <KeyUsage> and <UseKeyWith> elements.


8. Key usage definition is deliberately limited to Encryption, Signing and Key Exchange.


9. A <KeyBinding> <UseKeyWith> element defines which application and application entity the key is intended for. For example, a key may only be appropriate for authentication of an SSL server. In this case, the application is HTTPS, and the identifier is the URL of the server. Applications listed in the specification include S/MIME, HTTPS, SMTP, IPSec, PKIX and others.

Examples

A client might generate a key pair and wish to register it with a trust server, as in this example. (Complete examples are provided with the XKMS specification):

<RegisterRequest      
 xmlns:ds="http://www.w3.org/2000/09/xmldsig#"      
 Service="http://test.xmltrustcenter.org/XKMS"      
 RequestId="hZMRGyATbUL4H7rYOanR6Q=="      
 xmlns="http://www.w3.org/2002/03/xkms#">      
 <RespondWith>X509Cert</RespondWith>      
 <Prototype Id="tX4Y83grmj/eIVoeYNuTNg==">      
   <KeyInfo>      
     <ds:KeyValue>      
       <ds:RSAKeyValue>      
         <ds:Modulus>      
           zvbTdKsTprGAKJdgi7ulDR0eQBptL...      
         </ds:Modulus>      
         <ds:Exponent> AQAB </ds:Exponent>      
       </ds:RSAKeyValue>      
     </ds:KeyValue>      
   </KeyInfo>      
         
   <KeyUsage>Signature</KeyUsage>      
   <UseKeyWith      
     Application="urn:ietf:rfc:2633"      
     Identifier="alice@alicecorp.test" />      
 </Prototype>      
 <Authentication>      
   <ProofOfPossession>      
     <ds:Signature>      
       signing with the private key      
       demonstrates possession of it      
     </ds:Signature>      
   </ProofOfPossession>      
 </Authentication>      
</RegisterRequest>
Example 8 - XKMS Register Request

The server responds with the information requested with <RespondWith>:

<RegisterResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"      
               Service="http://test.xmltrustcenter.org/XKMS"      
               ResultMajor="Success"      
               RequestId="hZMRGyATbUL4H7rYOanR6Q=="      
               ResponseId="k9gyjDdhLLV1vbF7RzJjIw=="      
               xmlns="http://www.w3.org/2002/03/xkms#">      
   <KeyBinding Id="LVrJqd26QzO9GWJD0usQwg==">      
       <KeyInfo>      
          <KeyName>Sally Smith key</KeyName>      
       </KeyInfo>      
       <KeyUsage>Signature</KeyUsage>      
       <UseKeyWith Application="urn:ietf:rfc:2633"      
       Identifier="alice@alicecorp.test" />      
   </KeyBinding>      
</RegisterResult>
Example 9 - XKMS Register Response

A client could request an identity validation:

<ValidateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"      
                xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"      
                Service="http://test.xmltrustcenter.org/XKMS"      
                RequestId="zzjmNi9YL+dnkRXzDoqPoQ=="      
                xmlns="http://www.w3.org/2002/03/xkms#">      
   <RespondWith>KeyName</RespondWith>      
   <RespondWith>KeyValue</RespondWith>      
   <RespondWith>Multiple</RespondWith>      
   <KeyBindingQuery Id="T/QMi7gGuKCcNWPi120A/w==">      
       <KeyInfo>      
           <ds:X509Data>      
               <ds:X509Certificate>      
                   certificate encoded as text      
               </ds:X509Certificate>      
           </ds:X509Data>      
       </KeyInfo>      
       <KeyUsage>Signature</KeyUsage>      
       <UseKeyWith Application="urn:ietf:rfc:2633"      
                   Identifier="alice@alicecorp.test" />      
   </KeyBindingQuery>      
</ValidateRequest>
Example 10 - XKMS Validate Request

The following response indicates that the certificates are valid:

<ValidateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"      
               xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"      
               Service="http://test.xmltrustcenter.org/XKMS"      
               ResultMajor="Success"      
               RequestId="zzjmNi9YL+dnkRXzDoqPoQ=="      
               ResponseId="0WeinJVdbyBKruXhiqTscg=="      
               xmlns="http://www.w3.org/2002/03/xkms#">      
   <KeyBinding Id="m0/p5bekjemI4tV+FPBkig==">      
       <KeyInfo>      
           <ds:KeyValue>      
               <ds:RSAKeyValue>      
                   <ds:Modulus>...</ds:Modulus>      
                   <ds:Exponent>AQAB</ds:Exponent>      
               </ds:RSAKeyValue>      
           </ds:KeyValue>      
       </KeyInfo>      
       <KeyUsage>Signature</KeyUsage>      
       <UseKeyWith Application="urn:ietf:rfc:2633"      
                   Identifier="alice@alicecorp.test" />      
       <Reason>IssuerTrust</Reason>      
       <Reason>RevocationStatus</Reason>      
       <Reason>ValidityInterval</Reason>      
   </KeyBinding>      
</ValidateResult>
Example 11 - XKMS Validate Response

Authentication and Authorization Assertions: Security Assertion Markup Language (SAML)

Purpose and Benefits

Authentication is the process of establishing identity. This is required to limit access to resources, to identify participants in transactions, and to create seamless personalization of information based on identity. A means of sharing the fact that authentication has been performed successfully is necessary to allow "single sign-on" as well as to allow third party authentication services.

An example is a travel portal offering destination information, flight schedules, the ability to make reservations and other services. To a customer, it should appear as a single web site, but in fact different systems may be cooperating to implement the service. For usability and transparency, a customer should only need to authenticate once to the portal, and information on the successful authentication should be shared with the different underlying systems, with some validity period. A general requirement when using multiple networked systems is "single sign-on" - authenticating once and then sharing the result of authentication with multiple systems to avoid repeated authentication.

Related to authentication is authorization, the process of determining whether an authenticated party should be able to access a resource or perform an action. To give an example, human resources salary information may only be accessible to certain employees of a company, or only to members of the HR group. Such access control is based on the authenticated identity of an individual. To give another example, only specific individuals or individuals acting in specific roles should be able to enter into high value transactions on behalf of a company. Access control rules may be based on authenticated identity, the resource or action and other information, such as the time of day, day of week, or content of transactions.

Features

The XML Security Assertion Markup Language (SAML) defines an XML vocabulary for sharing security assertions, including authentication and authorization assertions, enabling "single sign-on" and third party management of these functions. It also defines a Request/Response protocol definition and an XML protocol (SOAP) binding. The SAML specification defines a general assertion framework, allowing assertions to be given validity time periods, and allowing assertions to be targeted to specific audiences (avoiding the potential for misuse). Assertions are associated with a given "subject" or named entity.

Key Concepts

The SAML specifications define:

1. An XML vocabulary for expressing authentication and authorization assertions, allowing statements about how and when authentication and authorization occurred to be passed among parties.


2. A request response protocol for conveying SAML assertions, as well as an XML protocol (SOAP) binding.


3. Unique identifiers (URNs) for different authentication mechanisms and authorization actions.


4. How digital signatures are associated with assertions.

SAML allows authentication information to be shared by creating an assertion that a subject was authenticated in a specific manner at a specific time. Different techniques for establishing identity are supported, ranging from use of a password to use of hardware tokens and personal physical attributes (biometrics). SAML allows assertions to specify which type of authentication mechanism was used and supports a variety of accepted mechanisms.

A SAML AuthorizationDecisionStatement may be used to assert that a request by a subject to access a specified resource has resulted in the specified decision, and may optionally include evidence to support the decision.

The SAML security considerations document discusses issues of security and privacy associated with SAML. For details see the SAML specifications [ SAML [19] ].

Examples

The following simplified authentication assertion example states that John Doe was authenticated using SSL client certificate authentication:

<Assertion>      
   <!-- Conditions may include optional XML attributes        
   defining a time period for validity -->      
   <Conditions NotBefore="dateTime" NotOnOrAfter="dateTime">      
       <!-- limit who can rely on this assertion -->      
       <AudienceRestrictionCondition>      
           <Audience>http:/www.example.com/Members</Audience>      
       </AudienceRestrictionCondition>      
   </Conditions>      
   <!-- Optional Advice used to include supporting        
   evidence, proofs, assertions, pointers to updates etc.        
   One or more of the possible sub-elements. -->      
   <Advice>      
       <AssertionIDReference>id</AssertionIDReference>      
       <!-- refer to other supporting assertion -->      
       <Assertion>...</Assertion>      
   <!-- provide inline information -->      
   </Advice>      
   <!-- Authentication - example:      
        SSL client certificate authentication -->      
   <AuthenticationStatement AuthenticationMethod="urn:ietf:rfc:2246"        
                            AuthenticationInstant="dateTime">      
       <Subject>      
           <NameIdentifier        
             Format="urn:oasis:names:tc:SAML:1.0:assertion#emailAddress">      
               john_doe@example.com        
           </NameIdentifier>      
       </Subject>      
   </AuthenticationStatement>      
   <ds:Signature>      
       XML Digital Signature for assertion      
   </ds:Signature>      
</Assertion>
Example 12 - SAML Authentication Assertion

The SAML specifications allow more complicated authentication statements, including the ability to include information needed to confirm subject identity, such as <KeyInfo> - see the SAML specification for details [ SAML [20] ].

The following example shows a response permitting John Doe to access a web resource:

<Assertion>      
   <!-- Conditions with optional XML attributes defining a      
        time period for validity -->      
   <Conditions NotBefore="dateTime" NotOnOrAfter="dateTime">      
       <!-- limit who can rely on this assertion -->      
       <AudienceRestrictionCondition>      
           <Audience>http:/www.example.com/Members</Audience>      
       </AudienceRestrictionCondition>      
   </Conditions>      
         
   <!-- Decision choices: "Permit", "Deny", "Indeterminate"-->      
   <AuthorizationDecisionStatement Resource=      
   "http://www.fjhirsch.com/info" Decision="Permit">      
       <Subject>      
           <NameIdentifier        
             Format="urn:oasis:names:tc:SAML:1.0:assertion#emailAddress">      
               john_doe@example.com        
           </NameIdentifier>      
       </Subject>      
       <Action Namespace="urn:oasis:names:tc:SAML:1.0:action:rwedc">      
           Read      
       </Action>      
       <Evidence>      
           <AssertionIDReference>LOG-Abc12Z</AssertionIDReference>      
       </Evidence>      
   </AuthorizationDecisionStatement>      
   <ds:Signature>      
       XML Digital Signature for assertion      
   </ds:Signature>      
</Assertion>
Example 13 - SAML Authorization Assertion

Authorization Rules: XML Access Control Markup Language (XACML)

Purpose and Benefits

Although SAML provides a mechanism for making authentication and authorization assertions and conveying these assertions using XML protocol, a vocabulary is also needed for expressing the rules needed to make authorization decisions. One XML vocabulary created specifically for expressing authorization rules is the XML Access Control Markup Language [ XACML [21] ].

Features

XACML defines:

1. An XML vocabulary for expressing authorization rules


2. An XML vocabulary for expressing a variety of conditions to be used in creating rules.


3. How rules are to be combined and evaluated


4. A means for creating policy statements, a collection of rules applicable to a subject.

Key Concepts

1. The XACML draft uses the SAML definitions for subjects and actions.


2. XACML defines rules as targets, effects and conditions.


3. A target includes resources, subjects and actions, as defined in SAML.


4. An effect is either "Allow" or "Deny".


5. Conditions are predicates and attributes defined in the XACML specification.

Examples

To make this concrete, consider the following rule taken from the XACML draft. This example will grant read access to records documents on the medico web site only if the SAML subject is the patient:

<Rule RuleId="//medico.corules/rule3" Effect="Permit">        
 <Target>        
   <Subjects>        
     <saml:Attribute AttributeName="RFC822Name"        
                     AttributeNamespace="//medico.com">        
       <saml:AttributeValue>*</saml:AttributeValue>        
     </saml:Attribute>        
   </Subjects>        
   <Resources>        
     <saml:Attribute AttributeName="documentURI"        
                     AttributeNamespace="//medico.com">              
       <saml:AttributeValue>//medico.com/records.*</saml:AttributeValue>        
     </saml:Attribute>        
   </Resources>        
   <Actions>        
     <saml:Action>read</saml:Action>        
   </Actions>        
 </Target>        
 <Condition>        
   <Equal>        
     <AttributeDesignator        
AttributeName="urn:oasis:names:tc:xacml:identifiers:AccessSubject" />        
     <AttributeDesignator AttributeName="patientName" />        
   </Equal>        
 </Condition>        
</Rule>
Example 14 - XACML Access Rule

Rules may be combined, and the XACML includes a specification on how this is done. In addition, rules may be collected into policy statements, including a target, rule-combining algorithm specification, a set of rules, and obligations. The target of a policy statement is used to determine where the policy is applicable and may be stated explicitly or derived from the targets of the policy rules. An obligation is an action to be performed once the authorization decision is complete. An example is sending a patient a notification email each time his or her record is accessed.

XML Security Applications

The XML Security standards form the basis for providing security to other XML-based initiatives, such as Web Services and Digital Rights Management.

Web Services Security: Roadmap and WS-Security

Purpose and Benefits

Web Services rely on XML Protocol ( SOAP) messages to link applications within an enterprise or across enterprises in an interoperable, platform-independent and programming language-neutral manner. This allows applications to be loosely coupled and integrated much more easily, inexpensively, and quickly than before. Ensuring that these interconnections are secure is essential to the future of Web Services.

Features

Microsoft and IBM have released a Web Services security architecture and roadmap [ WebSvcSecRoadmap [22] ] that outline a strategy and series of specifications to bring together different security technologies. The aim is to provide a unified, flexible and extensible security framework for Web Services. This architecture defines higher-level security requirements and terminology to allow those requirements to be met using one or more different security technologies. This use of high-level abstraction supports the goal of compatibility with existing and emerging security technologies.

The WS-Security specification outlines how XML Digital Signatures and XML Encryption may be used with XML Protocol (SOAP) messages as well as how security claims (such as identity credentials, for example) may be included with a message. This security mechanism goes beyond the SSL/TLS [ SSL-Intro [23], TLS-RFC [24] ] transport security mechanism, since it defines an end to end security mechanism and provides support for intermediary security processing.

The other specifications will be rolled out in a two-phase process. The first phase will include specifications necessary for Web Services Security across trust domains:

WS-Policy

Specify security requirements, capabilities, constraints and policies on Web Services intermediaries and endpoints

WS-Trust

Define security trust model allowing interoperation across security trust domains

WS-Privacy

Define a model for web service clients and services to state privacy preferences and practices

The second phase is intended to include those specifications for meeting more advanced requirements, specifically:

WS-SecureConversation

How to dynamically establish trust across trust domains using key exchange

WS-Federation

How to manage identities and other information across heterogeneous federated systems

WS-Authorization

How to manage authorization data and policies in a Web Services environment.

Key Concepts

One of the fundamental aspects of the Web Services Security Architecture is to define general terms for concepts, enabling the Web Services security standards to allow for different diverse security technologies, such as Public Key Infrastructure (PKI) as well as symmetric key systems such as Kerberos. Some of the concepts defined in the architecture include:

Principal

A person, application or business entity that can send or receive web service messages.

Claim

A statement (or assertion) about a subject that associates the subject with a property, such as the subject's identity, authorization, or other information. A claim may be made by a subject or some other party.

Token

A token is a representation of security related information and may be used to represent and substantiate a claim. A token may be unsigned (such as a shared secret password used to support an identity claim) or signed (such as a PKIX Identity certificate, a Kerberos ticket, or an authorization certificate). Use of an unsigned token may require secure transport such as provided by SSL/TLS or a VPN.

Note that having a token is often not enough - a signature is also required to demonstrate proof of possession of material associated with a token. An X.509 certificate, for example, may serve to demonstrate the binding of an identity with a public key, but proof of ownership of the corresponding private key may be provided by including a signature using that private key.

The architecture defines two base aspects of Web Services Security that are addressed. First is end to end message integrity and confidentiality, including consideration of the implications of intermediary processing. Second is the definition of secure web services endpoint processing, based on the ability to require some set of claims (a policy) to be met before performing processing. The message security model has been outlined in the WS-Security [ WS-Security [25] ] specification. The roadmap outlines a number of other specifications and how they will relate to each other and potential scenarios.

WS-Security defines how to extend SOAP to provide integrity and confidentiality and how to include security tokens in messages. This includes defining how to encode binary formats, including X.509 certificates and Kerberos tickets. The latest version of the Web Services Security Language (WS-Security) specification supersedes earlier specifications, including SOAP-SEC, WS-Security and WS-License from Microsoft. The specification addresses explicit requirements for supporting multiple security tokens, trust domains, and encryption technologies as well as supporting end to end integrity and confidentiality.

Examples

SOAP messages are defined to include a header and a body. Generally the payload is carried in the body of a SOAP message, and control information, such as that needed for intermediary processing and routing, is carried in the header. The WS-Security specification defines a <Security> XML element to be used in the SOAP message header to meet the SOAP security requirements. Thus, a simple SOAP stock quote request might be structured as follows, using an example given in WS-Security:

<?xml version="1.0" encoding="utf-8"?>        
<S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope"          
           xmlns:ds="http://www.w3.org/2000/09/xmldsig#">        
   <S:Header>        
       <!-- WS-Security specific information here -->        
       <wsse:BinarySecurityToken          
           xmlns:wsse="http://schemas.xmlsoap.org/Ws/2002/04/secext"          
           Id="myToken"          
           ValueType="wsse:X509v3"          
           EncodingType="wsse:Base64Binary">        
                MIIEZzCCA9CgAwIBAgIQEmtJZc0...          
       </wsse:BinarySecurityToken>        
       <wsse:Security          
           xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext">        
                   
           <ds:Signature>        
           <!-- XML Digital Signature on the MsgBody below        
                to provide payload integrity -->        
           </ds:Signature>        
       </wsse:Security>        
   </S:Header>        
   <!-- the Id provides a simple way for the security part        
        of the header to refer to the body -->        
   <S:Body Id="MsgBody">        
       <tru:StockSymbol xmlns:tru="http://fabrikam123.com/payloads">        
           QQQ          
       </tru:StockSymbol>        
   </S:Body>        
</S:Envelope>
Example 15 - Signed SOAP Request

This example shows use of a binary security token in the SOAP header. Used to convey key information, it includes the following identifying information:

• ValueType - what it is. Definitions include X.509V3 certificate, Kerberos ticket granting ticket, Kerberos service ticket.
• EncodingType - how it was encoded, such as base64 or hex encoding.

Alternately, a <KeyInfo> element , or a name and password token (over a secure transport like SSL/TLS) may be used. A security token may be combined with an XML Digital Signature by using a signature <Reference> to the token contained in a message header. This requires a <KeyInfo> extension defined in WS-Security.

Confidentiality of header and body elements may be provided using XML Encryption. As discussed in the previous section on XML Encryption, the encrypted element or element content is replaced by an <EncryptedData> element. Whenever an element or element content in a SOAP message is encrypted, a sub-element is required to be added to the <Security> element in the SOAP header:

An <xenc:ReferenceList> element may be added, giving the Id (fragment URI) of the <EncryptedData> element. This is most useful when key information is shared out of band. An example is:

<S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope"          
           xmlns:wsse="http://schemas.xmlsoap.org/Ws/2002/04/secext"          
           xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">        
   <S:Header>        
       <wsse:Security>        
           <xenc:ReferenceList>        
               <xenc:DataReference URI="#bodyID" />        
           </xenc:ReferenceList>        
       </wsse:Security>        
   </S:Header>        
   <S:Body>        
       <xenc:EncryptedData Id="bodyID">        
           <ds:KeyInfo>        
               <ds:KeyName>CN=Smith Joe, C=US</ds:KeyName>        
           </ds:KeyInfo>        
           <xenc:CipherData>        
               <xenc:CipherValue>...</xenc:CipherValue>        
           </xenc:CipherData>        
       </xenc:EncryptedData>        
   </S:Body>        
</S:Envelope>
Example 16 - Encrypted SOAP Payload

An <xenc:EncryptedKey> element is added to carry the encrypted key used to encrypt the portion of SOAP, to convey a symmetric key.

Attachments are possible using the same mechanism for providing email attachments, multi-part MIME (Multi-Purpose Internet Mail Extensions). Such attachments may be encrypted using XML Encryption.

The WS-Security specification gives detailed processing rules, examples and information about special issues such as canonicalization, so for more information refer to the specification [ WS-Security [26] ].

Privacy: Platform for Privacy Preferences (P3P)

Purpose and Benefits

Privacy is about controlling access to personally identifiable information, and, to a large degree, this is a human policy issue of ensuring that organizations and individuals with legitimate access to that information do not misuse that privilege. To give an example, although a medical office staff may have knowledge of a persons medical records, this does not mean they should share this information with others for profit or other purposes.

Features

The Platform for Privacy Preferences [ P3P [27] ] defines:

• An XML vocabulary for expressing user privacy preferences
• An XML vocabulary for expressing site privacy policies
• Mechanisms for retrieving site policies
• Processing rules

One of the goals is to provide machine-readable user preferences and site policies so that a P3P enabled client can alert users to sites that do not conform to their privacy expectations and help manage privacy.

Key Concepts

A P3P site policy indicates what information is collected and for what purpose, where to locate a human-readable policy, how the site manager may be contacted, and what assurances are made regarding privacy. P3P defines categories of data to be collected and provides the means to associate policy information with portions of a web site, URLs, and other information (such as cookies).

A site may associate privacy policies with different portions of the site. This is done by defining privacy meta information using an XML language defined in the P3P specification and either storing it at a well known location on the site, linking to it from an HTML or XHTML document using the link tag, or by referring to it in a special HTTP header defined in the P3P specification.

Examples

An example meta file from the P3P specification is:

<META xmlns="http://www.w3.org/2002/01/P3Pv1">          
   <POLICY-REFERENCES>          
       <EXPIRY max-age="172800" />          
       <POLICY-REF about="/P3P/Policy.xml#first">          
           <INCLUDE>/*</INCLUDE>          
           <EXCLUDE>/catalog/*</EXCLUDE>          
           <EXCLUDE>/cgi-bin/*</EXCLUDE>          
           <EXCLUDE>/servlet/*</EXCLUDE>          
       </POLICY-REF>          
       <POLICY-REF about="/P3P/Policies.xml#second">          
           <INCLUDE>/catalog/*</INCLUDE>          
       </POLICY-REF>          
       <POLICY-REF about="/P3P/Policies.xml#third">          
           <INCLUDE>/cgi-bin/*</INCLUDE>          
           <INCLUDE>/servlet/*</INCLUDE>          
           <EXCLUDE>/servlet/unknown</EXCLUDE>          
       </POLICY-REF>          
   </POLICY-REFERENCES>          
</META>
Example 17 - P3P Site Policy

The P3P specification also defines an XML language for writing a privacy policy, such as the following:

<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1">          
   <POLICY name="forBrowsers" xml:lang="en"          
discuri="http://www.catalog.example.com/PrivacyPracticeBrowsing.html">          
       <ENTITY>          
           <DATA-GROUP>          
               <DATA ref="#business.name">CatalogExample</DATA>          
               <DATA ref="#business.contact-info.postal.street">          
                   4000 Lincoln Ave.          
               </DATA>          
               ...          
               <DATA          
                 ref="#business.contact-info.telecom.telephone.number">          
                   3926753          
               </DATA>          
           </DATA-GROUP>          
       </ENTITY>          
       <ACCESS><nonident /></ACCESS>          
       <DISPUTES-GROUP>          
           <DISPUTES resolution-type="independent"          
                     service="http://www.PrivacySeal.example.org"          
                     short-description="PrivacySeal.example.org">          
               <IMG src="http://www.PrivacySeal.example.org/Logo.gif"          
                    alt="PrivacySeal's logo" />          
               <REMEDIES><correct /></REMEDIES>          
           </DISPUTES>          
       </DISPUTES-GROUP>          
       <STATEMENT>          
           <PURPOSE>          
               <admin />          
               <develop />          
           </PURPOSE>          
           <RECIPIENT><ours /></RECIPIENT>          
           <RETENTION><stated-purpose /></RETENTION>          
           <!-- Note also that the site's human-readable          
                privacy policy MUST mention that          
                data is purged every two weeks, or          
                provide a link to this information. -->          
           <DATA-GROUP>          
               <DATA ref="#dynamic.clickstream" />          
               <DATA ref="#dynamic.http" />          
           </DATA-GROUP>          
       </STATEMENT>          
   </POLICY>          
</POLICIES>
Example 18 - P3P Privacy Policy Statement

Digital Rights Management: eXtensible rights Markup Language (XrML) 2.0

Purpose and Benefits

Digital Rights Management (DRM) refers to controlling the use of content to conform to license policies, such as allowing single use, repeated use, no sharing with others and so on. Uses of DRM include control over movies, books, software and other electronic media. The general mechanism is to include usage rules with the content and then to enforce these rules in the applications that allow use of the content. This control mechanism is designed to be effective regardless of who is using the content, dynamically adjusting to the user. As a result, controls remain in place for copies and also adjust for content that is moved in a workflow among multiple users.

Digital rights management technology is an emerging technology. Use of a common language for rules would not only enable interoperability among "viewers" but also allow content to be passed through a workflow with multiple participants and applications. An emerging XML language for digital rights management is XrML 2.0, the extensible rights Markup Language [ XrML ]. This language is based on the Xerox PARC's Digital Property Rights Language (DPRL), first introduced in 1996 and converted from LISP to XML in 1999 and championed by ContentGuard.

Features

XrML defines a framework and language for expressing rights, a definition of terms (a common set of meanings), and a set of processing rules.

Key Concepts

Core concepts defined in XrML include the following:

Principal

A unique authenticated individual. Any authentication mechanism specified in the XrML principal definition may be used. One mechanism is to authenticate by demonstrating possession of a private key, by creating an XML Digital Signature.

License

Collection of grants giving certain rights to specified resources to certain principals under certain conditions as well as license issuer information.

Grant

A right issued to a principal against a resource under specified conditions

Right

An action a principal may perform against some resource under certain conditions. XrML defines actions, including read, write, delete, modify, install, play, transfer, and others.

Resource

An object that can be granted a right. Examples include digital works such as movies, books, images, audio as well as services such as email and transactions or other information (such as a name).

Condition

A condition is the terms and obligations that must be met to execute a grant against a resource. One condition may require other conditions as prerequisites. Example conditions include time, time period, use counters and viewer information

XrML uses XML Schema to define types and to provide for extensibility. XrML uses XML Namespaces to avoid name conflicts. XrML also uses XML Digital Signature to create signed licenses.

Examples

Here is an example from the XrML use cases document where the consumer pays $5.99 to play an eBook for one year and print up to 5 copies. In this example, detailed conditions are stored in a Web Services directory (UDDI) and referred to by a unique identifier(UUID):

<license xmlns:dsig='http://www.w3.org/2000/09/xmldsig#'>          
 <inventory>          
   <!-- PRINCIPAL specified by public key here -->          
   <keyHolder licensePartId="issuedToParty">          
     <info>          
      <dsig:KeyValue> specify public key </dsig:KeyValue>          
     </info>          
   </keyHolder>          
   <!-- RESOURCE specified by URI -->          
   <cx:digitalWork licensePartId="eBook">          
     <cx:locator>            
       <nonSecureIndirect          
         URI="http://www.contentguard.com/sampleBook.spd" />            
     </cx:locator>          
   </cx:digitalWork>          
 </inventory>          
 <!-- collection of GRANTs including general conditions on all -->          
 <grantGroup>          
   <keyHolder licensePartIdRef="issuedToParty" />          
   <sx:fee>          
     information about the fee, including type, amount,          
     currency, etc</sx:fee>          
   <grant>          
     <!-- RIGHT to play, for the validity interval          
          of 1 year (CONDITION) -->          
     <cx:play />          
     <cx:digitalWork licensePartIdRef="eBook" />          
     <sx:validityIntervalFloating>          
       validity interval, possibly unique identifier          
     </sx:validityIntervalFloating>          
   </grant>          
   <!-- RIGHT to print, for 5 times (CONDITION) -->          
   <grant>          
     <cx:print />          
     <cx:digitalWork licensePartIdRef="eBook" />          
     <sx:exerciseLimit>          
       Define use limit, possibly unique identifier          
     </sx:exerciseLimit>          
   </grant>          
 </grantGroup>          
 <issuer>          
   <dsig:Signature>          
     XML Digital Signature of issuer of license          
   </dsig:Signature>          
   <!-- issue time could be XML property within signature          
        but handled as part of <issuer> here -->          
   <details>          
       <timeOfIssue>2001-11-15T04:03:02</timeOfIssue>          
   </details>          
 </issuer>          
</license>

Example 19 - XrML Digital Rights Definition

Conclusion

The XML Security standards define XML languages and processing rules for meeting common security requirements. For the most part, these standards incorporate the use of the other XML Security standards, especially the core XML Digital Signature and XML Encryption standards. Another example is the sharing of policy statements by SAML and XACML. This set of interlocking standards has emerged quickly, and, since it is based on a foundation of accepted practices and technologies, should mature quickly. This article has presented a brief introduction to the set of standards and how they work together.

XML Security standards will be essential to moving business online as XML technologies are adopted for Web Services, Digital Rights Management and other emerging applications. Understanding of how XML may meet authentication, authorization, confidentiality,integrity, signature and privacy requirements will be essential. This paper has provided an introduction to these topics.

Acknowledgements

The author would like to thank Ed Frankenberry, Lorraine Hirsch and Dan Lanz for reviewing this document. All errors remain the author's.

References

[ 21CFR11 ]

Title 21 Code of Federal Regulations (21 CFR Part 11) Electronic Records; Electronic Signatures Final Rule Published in the Federal Register, March 20, 1997, http://www.fda.gov/ora/compliance_ref/part11/frs/background/11cfr-fr.htm [28]

[ BRML ]

Business Rules for Electronic Commerce: Project at IBM T.J. Watson Research, http://www.research.ibm.com/rules/home.html [29]

[ DocBook ]

The DocBook Document Type Committee Specification 4.2, 16 July 2002, Document identifier: cs-docbook-docbook-4.2 Location: http://www.oasis-open.org/docbook/specs/ [30]

[ Kerberos ]

Kerberos: The Network Authentication Protocol, http://web.mit.edu/kerberos/www/ [31]

[ MathML ]

Mathematical Markup Language (MathML™) 1.01 Specification W3C Recommendation, revision of 7 July 1999 http://www.w3.org/TR/REC-MathML/ [32]

[ Namespaces ]

Namespaces in XML, World Wide Web Consortium 14-January-1999, http://www.w3.org/TR/REC-xml-names/ [33]

[ P3P ] The Platform for Privacy Preferences 1.0 (P3P1.0) Specification

W3C Recommendation 16 April 2002, http://www.w3.org/TR/P3P/ [34]

[ PKI ]

Public-Key Infrastructure (X.509) (pkix), http://www.ietf.org/html.charters/pkix-charter.html [35]

[ RDF ] Resource Description Framework (RDF) Model and Syntax Specification

W3C Recommendation 22 February 1999, http://www.w3.org/TR/REC-rdf-syntax/ [36]

See also RDF Primer, W3C Working Draft 19 March 2002 http://www.w3.org/TR/rdf-primer/ [37]

[ RSS ]

RDF Site Summary (RSS) 1.0, December 6, 2000, http://purl.org/rss/1.0/spec [38]

[ SAML ] Security Assertion Markup Language

http://www.oasis-open.org/committees/security/ [39]

[ SOAP ] Simple Object Access Protocol

SOAP Version 1.2 Part 0: Primer, W3C Working Draft 26 June 2002, http://www.w3.org/TR/soap12-part0/ [40]

SOAP Version 1.2 Part 1: Messaging Framework, W3C Working Draft 26 June 2002, http://www.w3.org/TR/soap12-part1/ [41]

SOAP Version 1.2 Part 2: Adjuncts, W3C Working Draft 26 June 2002 http://www.w3.org/TR/soap12-part2/ [42]

[ SSLIntro] Introducing SSL and Certificates using SSLeay

Somewhat dated article (1997) providing an introduction to SSL/TLS: http://www.fjhirsch.com/Papers/wwwj/index.html [43]

[ TLSRFC ] The TLS Protocol, Version 1.0

INTERNET-DRAFT , March 2002 (Expires September 2002) http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc2246-bis-01.txt [44]

[ URI ]

Uniform Resource Identifiers (URI): Generic Syntax, RFC 2396, August 1998, http://www.ietf.org/rfc/rfc2396.txt [45]

[ WebSvcSecRoadmap]

Security in a Web Services World: A Proposed Architecture and Roadmap A Joint White Paper from IBM Corporation and Microsoft Corporation April 7, 2002, Version 1.0 , http://www-106.ibm.com/developerworks/security/library/ws-secmap/ [46]

[ WSDL ]

Web Services Description Language (WSDL) Version 1.2, W3C Working Draft 9 July 2002, http://www.w3.org/TR/wsdl12/ [47]

[ WS-Security ] Web Services Security (WS-Security)

Version 1.0, April 5, 2002, http://www-106.ibm.com/developerworks/library/Ws-secure/ [48]

[ X509Cert ]

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002, http://www.ietf.org/rfc/rfc3280.txt [49] (Note that this superceded RFC 2459)

Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002, http://www.ietf.org/rfc/rfc3279.txt [50]

An Internet Attribute Certificate Profile for Authorization, April 2002, http://www.ietf.org/rfc/rfc3281.txt [51]

[ XACML ] OASIS extensible Access Control Markup Language (XACML)

Working Draft 14, 14 June 2002 Document identifier: draft-xacml-specification-14.doc Location: http://www.oasis-open.org/committees/xacml/docs/ [52]

See http://www.oasis-open.org/committees/xacml/#documents [53] for related documents.

[ XHTML ]

XHTML™ 1.0: The Extensible HyperText Markup Language, A Reformulation of HTML 4 in XML 1.0, W3C Recommendation 26 January 2000, http://www.w3.org/TR/xhtml1/ [54]

[ XKMS ] XML Key Management Specification 2.0 (XKMS)

W3C Working Draft 18 March 2002, http://www.w3.org/TR/xkms2/ [55]

[ XML ]

Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation 6 October 2000 http://www.w3.org/TR/REC-xml [56]

[ XMLCanon ]

Canonical XML, Version 1.0, W3C Recommendation 15 March 2001, http://www.w3.org/TR/xml-c14n [57]

Exclusive XML Canonicalization, Version 1.0, W3C Proposed Recommendation 24 May 2002, http://www.w3.org/TR/xml-exc-c14n/ [58]

[ XMLDecTrans ]

Decryption Transform for XML Signature, W3C Candidate Recommendation, 04 March 2002 http://www.w3.org/TR/xmlenc-decrypt [59]

[ XML DigSig ] XML-Signature Syntax and Processing

W3C Recommendation 12 February 2002, http://www.w3.org/TR/xmldsig-core/ [60].

[ XML Enc ] XML Encryption Syntax and Processing

W3C Candidate Recommendation 04 March 2002, http://www.w3.org/TR/xmlenc-core/ [61].

[ XMLProt ]

XML Protocol Abstract Model, W3C Working Draft 9 July 2001, http://www.w3.org/TR/xmlp-am/ [62]

[ XMLRef ]

"Essential XML Quick Reference", Skonnard, Gudgin, Addison-Wesley, 2002

[ XPath ]

XML Path Language (XPath), Version 1.0, W3C Recommendation, 16 November 1999 http://www.w3.org/TR/xpath [63]

[ XPathFilter ]

XML-Signature XPath Filter 2.0, W3C Candidate Recommendation, 18 July 2002 http://www.w3.org/TR/xmldsig-filter2/ [64]

[ XrML ] extensible rights Markup Language (XrML) 2.0 Specification

20 November 2001 Available upon registration from http://www.xrml.org/m/ [65]

[1] http://www.w3c.org/TR/xmlp-am/
[2] http://www.w3c.org/TR/soap1-part0/
[3] http://www.w3c.org/TR/xpath
[4] http://www.w3c.org/TR/REC-xml
[5] http://www.w3c.org/TR/REC-xml-names/
[6] http://www.w3c.org/TR/xhtml1/
[7] http://www.oasis-open.org/docbook/specs
[8] http://purl.org/rss/1.0/spec
[9] http://www.w3.org/TR/REC-rdf-syntax/
[10] http://www.w3.org/TR/REC-MathML/
[11] http://www.research.ibm.org/rules/home.html
[12] http://www.w3c.org/TR/xmldsig-core/
[13] http://www.w3c.org/TR/xmldsig-filter2/
[14] http://www.ietf.org/rfc/rfc3280.txt
[15] http://www.w3c.org/TR/xml-c14n
[16] http://www.w3c.org/TR/xmlenc-decrypt
[17] http://www.w3c.org/TR/xmlenc-core/
[18] http://www.w3c.org/TR/xkms2/
[19] http://www.oasis-open.org/committees/security/
[20] http://www.oasis-open.org/committees/security/
[21] http://www.oasis-open.org/committees/xacml/docs/
[22] http://www-106.ibm.com/developerworks/security/library/ws-secmap/
[23] http://www.fjhirsch.com/Papers/wwwj/index.html
[24] http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc2246-bis-01.txt
[25] http://www-106.ibm.com/developerworks/library/Ws-secure/
[26] http://www-106.ibm.com/developerworks/library/Ws-secure/
[27] http://www.w3c.org/TR/P3P
[28] http://www.fda.gov/ora/compliance_ref/part11/frs/background/11cfr-fr.htm
[29] http://www.research.ibm.com/rules/home.html
[30] http://www.oasis-open.org/docbook/specs/
[31] http://web.mit.edu/kerberos/www/
[32] http://www.w3.org/TR/REC-MathML/
[33] http://www.w3.org/TR/REC-xml-names/
[34] http://www.w3.org/TR/P3P/
[35] http://www.ietf.org/html.charters/pkix-charter.html
[36] http://www.w3.org/TR/REC-rdf-syntax/
[37] http://www.w3.org/TR/rdf-primer/
[38] http://purl.org/rss/1.0/spec
[39] http://www.oasis-open.org/committees/security/
[40] http://www.w3.org/TR/soap12-part0/
[41] http://www.w3.org/TR/soap12-part1/
[42] http://www.w3.org/TR/soap12-part2/
[43] http://www.fjhirsch.com/Papers/wwwj/index.html
[44] http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc2246-bis-01.txt
[45] http://www.ietf.org/rfc/rfc2396.txt
[46] http://www-106.ibm.com/developerworks/security/library/ws-secmap/
[47] http://www.w3.org/TR/wsdl12/
[48] http://www-106.ibm.com/developerworks/library/Ws-secure/
[49] http://www.ietf.org/rfc/rfc3280.txt
[50] http://www.ietf.org/rfc/rfc3279.txt
[51] http://www.ietf.org/rfc/rfc3281.txt
[52] http://www.oasis-open.org/committees/xacml/docs/
[53] http://www.oasis-open.org/committees/
[54] http://www.w3.org/TR/xhtml1/
[55] http://www.w3.org/TR/xkms2/
[56] http://www.w3.org/TR/REC-xml
[57] http://www.w3.org/TR/xml-c14n
[58] http://www.w3.org/TR/xml-exc-c14n/
[59] http://www.w3.org/TR/xmlenc-decrypt
[60] http://www.w3.org/TR/xmldsig-core/
[61] http://www.w3.org/TR/xmlenc-core/
[62] http://www.w3.org/TR/xmlp-am/
[63] http://www.w3.org/TR/xpath
[64] http://www.w3.org/TR/xmldsig-filter2/
[65] http://www.xrml.org/m/