Securing Web Services

Martin G. Nystrom


Armed with simple tools, businesses are using web services to bring together disparate, network-separated applications. Due to the criticality and sensitivity of the data, however, securing the data and respective applications takes on growing importance. The first standards emerging for web services only addressed the interaction, without addressing encryption, authentication, or authorization. This paper seeks to explain some of the history and promise of web services, the problems they present, and techniques for securing them. It will cover emerging standards for web services security in the areas of encryption, authentication and signing, and authorization. Standards under the banner of WS-Security receive the most attention.

I. Introduction

The web services programming model is making it easier for businesses to conduct electronic commerce with one another. It does so by using well-accepted protocols such as XML and HTTP to represent the entire interaction in plain text. This technique is often heralded as a great step forward over traditionally complex models such as CORBA, DCE, and EDI, since it simply places a new protocol on the already pervasive HTTP “pipes”. It is because of the simplicity and pervasiveness of the web services model that effort must be placed upon securing them, before relying on these new applications to exchange critical and confidential information. This paper provides an overview of the emerging standards and techniques for securing web services.

II. Background


XML emerged in the late 1990s as a very simple, textual format for both holding and describing information. Its self-describing format makes it perfect for consumption by software applications. It’s also easy to transport, since it can easily flow over HTTP. XML is like “machine consumable” HTML: both were designed to present information, both of them over HTTP. Standards for sharing data via XML have solidified in recent years with the advent of XML namespaces and XML Schema. These standards have provided a standard representation for common data types such as strings, integers, etc. They also make it easy to build an entirely new vocabulary upon the foundation of simpler types. Because of its simplicity, and helped along by these foundational standards, XML has become a very attractive tool for representing data for exchange between applications.


Simple Object Access Protocol (SOAP) emerged as a technique for making remote calls between applications in the middle of 2000. It was brought to W3C by Microsoft, IBM, UserLand, and DevelopMentor. SOAP defined a textual envelope for carrying the message, rules for encoding the messages and faults, and rules for encoding remote procedure calls (RPCs) [1]. (See example 1 for a sample SOAP envelope.) Because SOAP is textual (it uses XML to encode everything), it can be used as a wire protocol over any transport you wish. That said, because SOAP is attractive as a tool for combining heterogeneous applications (using such tools as Java, Perl, and .Net), HTTP makes a good “common denominator” transfer protocol. Technically, SOAP can be used with CORBA, MOM, SMTP, and other transfer protocols, but HTTP has become the simplest and most pervasive backbone for SOAP messages. SOAP has become the de facto language of web services. Because of that, I will refer to SOAP when discussing web services throughout this paper.


Secure Sockets Layer (SSL) was developed by Netscape and is now used by all web servers and browsers as tool for authentication and encryption. It runs “on top of” TCP/IP but “underneath” transports such as HTTP and LDAP [2]. HTTP is run over SSL to create what is commonly called “HTTPS”. Normally, HTTPS is used to validate the identity of the server to the client (via a chain of trusted certificates), and provides end-to-end encryption for the HTTP protocol. HTTPS can also provide client authentication, but HTTP basic authentication (explanation directly below) is normally used for that.   HTTPS is often used to provide confidentiality (via strong encryption) for web services, but it’s not a complete solution to the problem, as we shall see later in this paper.

D. HTTP Basic Authentication

Basic authentication is often used to provide userid/password authorization to web resources. All web servers provide a means for protecting resources using basic authentication.  Using this technique, the web server checks to see if the user has sent authentication credentials when trying to access a protected resource. If the user has not logged in (indicated by the presence of base-64 encoded credentials in the HTTP header), he is challenged with a login dialog. [3] Basic authentication is not considered strong authentication, because it’s trivial to un-encode the username and password (Base64 encoding is not considered encryption, because there’s no secret key). HTTP digest authentication is also available, and is more secure than basic authentication, but it is not widely used, and support in browsers is inconsistent.

III. Security Concerns

The web services model, because it leverages tools and protocols designed for user-to-server interaction, presents some unique problems for traditional infrastructures.

A. Existing Firewalls

Firewalls are designed to protect networks by restricting connections to hosts and ports. Firewalls are vital to enable external access to resources like your company’s web server or mail server. For example, a firewall at Nitram Techologies might set up their ports to allow connections from anywhere to:

Historically, this was fine, since the applications accessible through these routes were deliberately created for consumption by web browsers external to the company. The problem is that SOAP will use these same connections to expose new kinds of applications. For example, consider allowing one of your largest customers to cancel orders via a SOAP request.  This is a sensitive operation, requiring strong authentication, authorization, and non-repudiation.  However, this firewall is configured to allow any kind of valid TCP packet through these ports, regardless of what’s in it.  Therefore, this sensitive web service is naked and exposed to the world. Of course, it’s easy to configure the web server to require authentication by the client application (treating it as if it were a user.)  Still, you can see that the ease of access to a web service is a double-edged sword:

"One good thing about SOAP: By using HTTP you can send messages right through the firewall.  One bad thing about SOAP: By using HTTP you can send messages right through the firewall." Anthony Nadalin [4]

B. Securing the Pipe is Not Enough

HTTPS (HTTP over SSL) has served well as a tool for encrypting private information. Millions of consumers rely on it every day to hide their credit card numbers when they make purchases on the Internet. It can also provide authentication, but its typically only used to authenticate the identity of the web server to the client (via CA trust chains). It is capable of authenticating the client identity to the server, but most web servers are not set up for that. HTTPS can provide:

However, HTTPS cannot provide:

So, HTTPS does a good job of providing strong enough encryption and server identity authentication to the client. It’s also capable of providing client identity authentication to the server.  The problem is that it is a “point-to-point” security, which doesn’t allow intermediaries to act on the data, and requires trust between the HTTPS end-point and the location of the application being secured.  


1) Limitation #1: End-to-End

HTTPS runs from HTTP client to HTTP server.  It’s likely, however, that those are not the end-points of the application. The encryption stops at the web server, while the transaction continues on into the application server and database. Because HTTPS does not provide authorization and encryption to the end-points of the transaction, you must be able to trust the applications attached to the HTTP end-points instead. (Otherwise, the server application could receive rogue messages, claiming to come from trusted HTTP servers).

2) Limitation #2: Protocol Translation

Because HTTPS does not run all the way to the “end-points” of the transaction, the protocol must be translated, perhaps into CORBA/IIOP or SQL*Net, as the application traverses the rest of the pipes.  Authentication, identification, and confidentiality stop at the HTTP/S end points.

3) Limitation #3: Signature and Non-Repudiation

Because the protocol does not extend all the way into the database, it cannot provide an audit trail.  The web server (the end-point of the encryption) can provide a log file, but not one robust enough to use for non-repudiation.  It does not provide a signature that can be used for non-repudiation.

4) Limitation #4: Element-wise Encryption

HTTPS encrypts everything.  For the message to be routed through an intermediary, however, it must be decrypted in its entirety, then re-encrypted for the next “hop” in the route. This limits the ability to route XML messages via HTTPS, as it is “all or nothing” encryption that exposes too much to intermediaries. Intermediary applications should only be able to decrypt the portion relevant for their step of the processing. A good example of this need is a credit-card number, which you only want to expose to the credit clearinghouse, but not to the merchant [5]


C. HTTP Basic Authentication is not Strong Enough

Most web applications accept user authentication via HTTP basic or form authentication.  For applications attempting to use the same web servers to access web services, however, this presents a problem.  The client applications must record the userid and password for accessing the web service in their application code. If the client application code is compromised, a malicious user could use that recorded information to gain unauthorized access to the web service.  Therefore, traditional user-oriented authentication techniques are not strong enough when the client is an application.


IV. Security Solutions

There are a number of new standards that can be applied to web services and XML to provide security. This section will address the areas of authentication, authorization, identification, integrity, confidentiality, auditing, and non-repudiation.  As these solutions are presented, we’ll start with a simple SOAP envelope, and add security to it as we go.  This first example is just a simple SOAP message requesting an order for 2 books from


Example 1: A simple SOAP request, complete with envelope, header, and body

(01) <?xml version="1.0" encoding="utf-8"?>
(02) <S:Envelope xmlns:S="">

(03)    <S:Header>

   <!-- Later, we’ll put our security stuff in here -->

(05)    </S:Header>

(06)    <S:Body>
(07)       <m:PlaceOrder xmlns:m="">

(08)         <m:ISBN>0618134700</m:ISBN>
(09)         <m:Quantity>2</m:Quantity>
(10)         <m:CustomerNumber>ENJ-32423-CCNK</m:CustomerNumber>
(11)         <m:CreditCardNumber>4121883253447883</m:CreditCardNumber>
(12)         <m:CreditCardExp>06/06/2004</m:CreditCardExp>
(13)       </m:PlaceOrder>
(15) </S:Envelope>

A. Standards to Enable Integrity, Authentication, and Confidentiality of Web Services

Two elements that are essential to securing web services are strong authentication and confidentiality (via encryption).  There are three SOAP-oriented XML standards that address these areas.

1) WS-Security

The Web Services Security Specification (WS-Security) standard provides a framework for securing SOAP messages.  It describes how to exchange signed and encrypted messages in a SOAP environment.  It does this by providing extensions to SOAP (by way of new XML tags and structures). It can use PKI, Kerberos, Basic/Digest authentication, and SSL to provide the security.

WS-Security provides a framework that supports the concept of an intermediary.  It allows the participants to define a security context between a requester and a web service - with an intermediary between them, or to define two separate contexts, one between the requester and the intermediary, and another between the intermediary and the web service.

Figure 1: Security contexts in WS-Security (copied from [4]).

WS-Security defines a security header in the SOAP message, that allows you to attach credentials (such as a Kerberos ticket), along with a signature.  This header can be tagged with the SOAP mustUnderstand attribute to “force” the receiving web service to either handle the security header or reject the request altogether.

The payload (or portions thereof) can be encrypted and placed in the SOAP envelope, provided the binary output is converted to a textual format for transmission via XML. It also allows the requester to submit a claim. A claim is a statement that a client makes.  Examples are “name”, “identity”, “key”, “group”, “privilege”, etc.

The following example (example 2 below) shows a Security header (enclosed within the tags <wsse:Security>) inserted into a SOAP envelope. It includes an x509 certificate enclosed within the <wsse:BinarySecurityToken> tags.  The sender of this message is making a claim that they can be identified by the x509 certificate represented within the <wsse:BinarySecurityToken> tag.  Later, we’ll make use of that certificate by signing the request.

Each namespace refers to a web services or XML specification that will be discussed further in this paper. This example is taken from the Web Services Security Extensions specification [6], with some modifications.

Example 2: A SOAP envelope with an X.509 certificate enclosed in the header

(01) <?xml version="1.0" encoding="utf-8"?>

(02) <S:Envelope xmlns:S=""

(03)             xmlns:wsse=""

(04)    <S:Header>

(05)       <wsse:Security>

(06)          <wsse:BinarySecurityToken

(07)                      ValueType="wsse:X509v3"

(08)                      EncodingType="wsse:Base64Binary" 

(09)                      Id="X509Token">

(10)                   MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...

(11)          </wsse:BinarySecurityToken>

(12)       </wsse:Security>

(13)    </S:Header>

(14)    <S:Body>

(15)       <m:PlaceOrder xmlns:m="">

(16)         <m:ISBN>0618134700</m:ISBN>

(17)         <m:Quantity>2</m:Quantity>

(18)         <m:CustomerNumber>ENJ-32423-CCNK</m:CustomerNumber>

(19)         <m:CreditCardNumber>4121883253447883</m:CreditCardNumber>

(20)         <m:CreditCardExp>06/06/2004</m:CreditCardExp>

(21)       </m:PlaceOrder>

(22)    </S:Body>

(23) </S:Envelope>

Note that the body of the message contains only a simple request to place an order for 2 books. The rest of the message is devoted entirely to the SOAP header, which is entirely security information to support this request. WS-Security encapsulates two other important specifications that enable the authentication and encryption. These are discussed below.

 2) XML Digital Signatures

The ability to authenticate a SOAP message is vital to web services, especially if they become vital resources, as database resources are today.  Comparatively, this is not a trivial task. Consider that authentication normally expects the credentials of a single user, not another system.  In client/server systems, this often means a “pop-up” dialog box or a form to fill in.  Other systems offer a command-line prompt for user id and password.  Web-based systems prompt for HTTP basic authentication, digest authentication, or form-based authentication.  Web services, because they act more autonomously, need stronger authentication mechanisms that can be placed directly into XML messages.

The SOAP digital signature specification [7] provides message integrity (by signing a portion of the message that can be verified to see if it’s been altered), and message authentication (by checking the signature to ensure it came from a trusted source) [10].  Using digital signatures, the message sender takes a portion of the message (or more likely, the entire payload of the message – in this case, the whole body of the SOAP request), generates a digest (hash) of the data, and signs the message with its private key  (I say “its private key” instead of “his private key” because the sender of the message is another application, not a human being.) In the following example, I’ve added a reference to the XML digital signatures namespace (“ds”) on line 04, and have added the following signature information:

You’ll note that the message digest and the signature value are plain characters.  That’s because this specification calls for the encoding of the binary data using Base 64 encoding, so that it can be transported within an XML message.  You’ll also note that I’ve shortened the values to make it easier to read the message. In reality, the digest and signature would take several lines each.

Now that you can see where the signature and message digest are, let’s go over the meaning of some of the other digital signature elements, and why they’re present:

Example 3: SOAP envelope with XML encoded digital signature using XML DSig 

(01) <?xml version="1.0" encoding="utf-8"?>

(02) <S:Envelope xmlns:S=""

(03)            xmlns:wsse=""

(04)             xmlns:ds="" >

(05)   <S:Header>

(06)      <wsse:Security>

(07)         <wsse:BinarySecurityToken

(08)                     ValueType="wsse:X509v3"

(09)                     EncodingType="wsse:Base64Binary" 

(10)                     Id="X509Token">

(11)                  MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...

(12)         </wsse:BinarySecurityToken>

(13)         <ds:Signature>

(14)            <ds:SignedInfo>

(15)               <ds:CanonicalizationMethod Algorithm=

(16)                     ""/>

(17)               <ds:SignatureMethod Algorithm=

(18)                     ""/>

(19)               <ds:Reference>

(20)                  <ds:Transforms>

(21)                     <ds:Transform Algorithm=

(22)                           "http://...#RoutingTransform"/>

(23)                     <ds:Transform Algorithm=

(24)                           ""/>

(25)                  </ds:Transforms>

(26)                  <ds:DigestMethod Algorithm=

(27)                       ""/>

(28)                  <ds:DigestValue>EULddytSo1...</ds:DigestValue>

(29)               </ds:Reference>

(30)            </ds:SignedInfo>

(31)            <ds:SignatureValue>

(32)              BL8jdfToEb1l/vXcMZNNjPOV...

(33)            </ds:SignatureValue>

(34)            <ds:KeyInfo>

(35)                <wsse:SecurityTokenReference>

(36)                    <wsse:Reference URI="#X509Token"/>

(37)                </wsse:SecurityTokenReference>

(38)            </ds:KeyInfo>

(39)         </ds:Signature>

(40)      </wsse:Security>

(41)   </S:Header>

(42)   <S:Body>

(43)      <m:PlaceOrder xmlns:m="">

(44)        <m:ISBN>0618134700</m:ISBN>

(45)        <m:Quantity>2</m:Quantity>

(46)        <m:CustomerNumber>ENJ-32423-CCNK</m:CustomerNumber>

(47)        <m:CreditCardNumber>4121883253447883</m:CreditCardNumber>

(48)        <m:CreditCardExp>06/06/2004</m:CreditCardExp>

(49)      </m:PlaceOrder>

(50)   </S:Body>

(51) </S:Envelope>

3) XML Encryption

XML encryption allows the message sender to protect the confidentiality of portions of the message, allowing that portion to be understood only by an intended recipient. A common example of this is a credit card number. A sender may route the SOAP message to a web service by way of a credit clearinghouse, who plucks out the credit card number, processes it, and routes the message to the destination web service. In this example, we don’t want to expose that credit card number to anyone but the credit clearinghouse.

XML encryption works by allowing the sender to specify which part of the body is encrypted, referencing the keys with which it was encrypted.  As you can see above, I’ve been transmitting the credit card number in plain-text all along.  Now let’s encrypt that credit card number:

Example 4: SOAP envelope with an encrypted element using XENC

(01) <?xml version="1.0" encoding="utf-8"?>

(02) <S:Envelope xmlns:S=""

(03)            xmlns:wsse=""

(04)             xmlns:ds=""

(05)             xmlns:xenc=””>

(05)   <S:Header>

(06)      <wsse:Security>

(07)         <wsse:BinarySecurityToken

(08)                     ValueType="wsse:X509v3"

(09)                     EncodingType="wsse:Base64Binary" 

(10)                     Id="X509Token">

(11)                  MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...

(12)         </wsse:BinarySecurityToken>

(13)         <ds:Signature>

(14)            <ds:SignedInfo>

(15)               <ds:CanonicalizationMethod Algorithm=

(16)                     ""/>

(17)               <ds:SignatureMethod Algorithm=

(18)                     ""/>

(19)               <ds:Reference>

(20)                  <ds:Transforms>

(21)                     <ds:Transform Algorithm=

(22)                           "http://...#RoutingTransform"/>

(23)                     <ds:Transform Algorithm=

(24)                           ""/>

(25)                  </ds:Transforms>

(26)                  <ds:DigestMethod Algorithm=

(27)                       ""/>

(28)                  <ds:DigestValue>EULddytSo1...</ds:DigestValue>

(29)               </ds:Reference>

(30)            </ds:SignedInfo>

(31)            <ds:SignatureValue>

(32)              BL8jdfToEb1l/vXcMZNNjPOV...

(33)            </ds:SignatureValue>

(34)            <ds:KeyInfo>

(35)                <wsse:SecurityTokenReference>

(36)                    <wsse:Reference URI="#X509Token"/>

(37)                </wsse:SecurityTokenReference>

(38)            </ds:KeyInfo>

(39)         </ds:Signature>

(40)         <xenc:ReferenceList>

(41)            <xenc:DataReference URI=”#cardnum”/>

(42)         </xenc:ReferenceList>
(43)      </wsse:Security>

(44)   </S:Header>

(45)   <S:Body>

(43)      <m:PlaceOrder xmlns:m="">

(44)        <m:ISBN>0618134700</m:ISBN>

(45)        <m:Quantity>2</m:Quantity>

(46)        <m:CustomerNumber>ENJ-32423-CCNK</m:CustomerNumber>

(47)        <xenc:EncryptedData Id=”cardnum”>

(48)          <ds:KeyInfo>

(49)              <ds:KeyName>CN=iTransact Inc., C=US</ds:KeyName>

(50)          </ds:KeyInfo>

(51)          <xenc:CipherData>

(52)            <xenc:CipherValue>Xd57Sui8/9eVfh...</xenc:CipherValue>

(53)          </xenc:CipherData>

(54)        </xenc:EncryptedData>

(55)        <m:CreditCardExp>06/06/2004</m:CreditCardExp>

(56)      </m:PlaceOrder>

(57)   </S:Body>

(58) </S:Envelope>

In this example, we’ve replaced the plain-text credit card number with an encrypted data element enclosed in the <xenc:EncryptedData> tags on lines 47 – 54. Here is the meaning of the elements:

B. Standards to Enable Authorization for Web Services

There are two standards that enable authorization in web services: Security Assertions Markup Language (SAML), and XML for Access Control Lists (XACL).

1) Security Assertions Markup Language

It may not be obvious at first, but one key aspect of web services is the concept of single sign-on.  The idea is that once the user has authenticated once, an application (or another web service) can forward that user’s credentials to another web service and request action on the user’s behalf.  For this to work, we need a method for encoding the “assertion” by one application that it has authenticated the user’s credentials, allowing it to pass those credentials securely.  An assertion is a declaration of facts (statements) about a subject (according to some SAML authority).  Assertions can also be digitally signed, to prove that they came from a trusted source [12].

In addition, we need the ability to describe what parts of an application the user is authorized to access.  SAML enables applications (web services) to exchange identity and entitlement information with each other [11].  SAML works by exchanging “assertions”, which confirm information about a user’s authorization, authentication, or other information.  These assertions are usually time-bound, and describe events that have already occurred, such as, “This user has been successfully authenticated”, or “This application is authorized to take this action.”  Here’s an example SAML authentication assertion, taken directly from [12].  This assertion says, “I authenticated mnystrom on via password at 10:02AM on March 21st, 2002.”

Example 5: SAML authentication assertion

(01) <saml:Assertion

(02)   MajorVersion=”1” MinorVersion=”0”

(03)   AssertionID=””

(04)   Issuer=”Cisco Systems, Inc.”

(05)   IssueInstant=”2002-03-21T10:02:00Z”>

(06)   <saml:Conditions NotBefore=”2002-03-21T10:02:00Z” NotAfter=”2002-03-21T10:07:00Z” />

(07)   <saml:AuthenticationStatement

(08)      AuthenticationMethod=”password”

(09)      AuthenticationInstant=”2002-03-21T10:02:00Z”>

(10)      <saml:Subject>

(11)          <saml:NameIdentifier SecurityDomain=”” Name=”mnystrom” />

(12)      </saml:Subject>

(13)   </saml:AuthenticationStatement>

Central to SAML is the concept of an “issuing authority”.  An issuing authority is a central service responsible for authenticating and authorizing users or applications.  This can be accomplished by using federated security service providers (such as Microsoft’s Passport service), using a private 3rd party security service provider (such as American Express), or setting up your own private issuing authority within your own domain. 

Figure 2: SAML topography (taken from here).

2) XML for Access Control Lists (XACL)

It’s not what you think – this isn’t a way to set up ACLs on network routers using XML.  Instead, XACL allows you to hide or expose certain portions of an XML document from users, based on their roles.  The idea is simple, in addition to the XML document you want to protect, define an extra document that references the original, and constrains access by role.  [13].

Here’s an example of a simple XML document for which we may want to restrict access to certain portions, taken from [14]:

Example 6: Simple XML document as fodder for XACL policy

(01) <personnel_info>

(02)    <name>Johnson</name>

(03)    <salary currency=”USD”>200,000</salary>

(04) </personnel_info>

Now, let’s say that we want to restrict access to the salary node to only those users with the role of  “Manager”. We do this by setting a policy in the Access Control Rules file, that looks like this:

Example 7: XACL policy document

(01)  <policy>

(02)    <xacl>

(03)       <object href=”/personnel_info/salary”/>

(04)       <rule>

(05)          <acl>

(06)              <subject>

(07)                 <role>Manager</role>

(08)              </subject>

(09)              <action name=”read” permission=”grant”/>

(09)          </acl>

(10)       </rule>

(11)    </xacl>

(12)  </policy>

This allows you to authorize viewing of only certain portions of the document based upon the role of the user. The usefulness seems dubious, since there are existing authorization models in database systems and applications with which it must compete.  However, it does provide a way to define authorization via XML.


Web services present a unique challenge to the web.  They offer the ability to integrate and automate much of the e-commerce that is currently conducted “manually” (consumer to business.)  They leverage the simplicity and ubiquity of HTTP and XML to allow new kinds of interactions between applications.  However, the simplicity is a double-edged sword, as web services place more sensitive and critical B2B transactions through the channels designed only for user transactions.

WS-Security offers a framework for strong authentication and encryption, while SAML and XACL provide strong authorization.  Non-repudiation and auditing (via logging) can be provided by existing web servers and application servers.

These techniques provide a means to secure web services.  They can become effective as they are absorbed into application and web servers, so that application developers can harness their power without being hindered by their complexity.  Tools from vendors such as Netegrity (, and Oblix ( offer solutions for implementing these standards.


 [1] D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. F. Nielsen, S. Thatte, and D. Winer. (2000, May 8).   Simple Object Access Protocol (SOAP) 1.1. W3C Standard.  [Online]. Available at

[2] Netscape Corporation. (1998, October 10). Netscape DevEdge. [Online].  Available at


[4] Anthony Nadalin and Nataraj Nagaratnam. (May 2002). Securing Web Services.  Presented at IBM DeveloperWorks Live! 2002.

[5] Maryann Hondo, Martin W. Sachs, Peter Brittenham. (May 2002).  Web Services Security Metadata.  Presented at IBM DeveloperWorks Live! 2002.

[6] Microsoft, IBM, Verisign (April 2002).  IBM developerWorks.  [Online].   Available at

[7] A. Brown, B. Fox,  S. Hada, B. LaMaccia, H. Maruyama. (2001, February 6).  SOAP Security Extensions: Digital Signature. W3C Note.  [Online].  Available at

[8] D. Eastlake, J. Reagle.  (2002, March 4).  XML Encryption Syntax and Processing.  W3C Candidate Recommendation.  [Online].  Available at

[9] J. Boyer.  (2001, March 15).  Canonical XML, Version 1.0. W3C Recommendation. [Online].  Available at

[10] M. Bartel, J. Boyer, B. Fox, E. Simon.  (2000, October 31).  XML-Signature Syntax and Processing.  W3C Candidate Recommendation.  [Online].  Available at

[11] J. Byous.  (2002, May 9). Single Sign-on Simplicity with SAML. Java Developer Connection. [Online}.  Available at:

[12] J. Rouault.  (2002, January 18). Introduction to SAML. [Online].  Available at

[13] M. Kudo, S. Hada.  (2000, October 24). XML Access Control. Proposal to W3C.  [Online].   Available at

[14] IBM (2001, August 31).  XACL Simple Example.  [Online].  Available at