Getting Started With XML Security
©Copyright 2002 Frederick Hirsch.
Please do not reprint without permission.
All names and identifiers in the examples are meant
to be fictitious. (Updated references and links 05-02-28)
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).
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,
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
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, Simple Object Access Protocol, SOAP),
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 ]).
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
XML Security standards:
as well as major XML Security applications:
- 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)
The XML specification [ XML ] defines a syntax and rules for using tags to
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.
- Web Services Security - Roadmap and WS-Security
- Privacy - Platform for Privacy Preferences (P3P)
- Digital Rights Management - eXtensible Rights Markup Language 2.0 (XrML)
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 ].
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.
reuse of tools and training, another advantage of XML.
Many XML languages have already been defined, including XHTML for creating web pages,
creating technical documentation, RSS for content distribution (syndication),
RDF for representing information,MathML for mathematics markup, BRML 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/">
<Visit date="10pm March 10, 2002">
<Diagnosis>Broken second metacarpal</Diagnosis>
<lab:Diagnosis><lab:Xray>encoded xray image</lab:Xray></lab:Diagnosis>
Example 1 - Sample XML Document With XML Namespaces
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
- 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
- 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
- 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.
technology may be used to protect privacy, but cannot prevent inappropriate sharing of
- 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
Traditionally, security technologies have required applications to be security or
Public Key Infrastructure
"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 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:
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.
The core XML Security standards are:
- 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
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] and extended in [ XPathFilter ]).
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.
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.
XML Security technologies reuse existing cryptographic and security technologies whenever possible,
without reinventing the
wheel. For example, X.509 V3 certificates [ X509Cert ] 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
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.
- XML Digital Signature for integrity and signatures,
- XML Encryption for confidentiality,
- XML Key Management (XKMS) for key management,
- Security Assertion Markup Language (SAML) for making authentication and authorization assertions, and
- XML Access Control Markup Language (XACML) for stating authorization rules.
Each standard defines the XML vocabulary necessary for describing the security information
for that aspect of security, as well as the processing rules necessary to understand how to
apply the standard.
3.1.1. Integrity & Signatures: XML Digital Signature (XML DigSig)
188.8.131.52. Purpose and Benefits
Digital signatures are useful for two purposes:
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.
- To provide persistent content integrity, and
- To create and verify portable electronic signatures
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".
The XML Digital signature recommendation defines mechanisms to support the full range of digital
and verification, including the ability to sign and verify:
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) 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.
- Entire XML documents as well as element and element content portions of XML documents,
- Arbitrary documents, including binary documents,
- Compound documents including multiple documents and/or XML elements and element contents,
- Properties to be included with a signature,
- Counter-signatures (signatures that include other signatures)
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
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"
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:
<Account> 123456 </Account>
<Visit date="10pm March 10, 2002">
<Diagnosis> Broken second metacarpal </Diagnosis>
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,
<SignedInfo> ... </SignedInfo>
<SignatureValue> ... </SignatureValue>
<p:Purpose xmlns:p="http://www.myexample.com/schemas">Approval </p:Purpose>
Example 3 - Enveloping Signature
184.108.40.206. Key Concepts
The following concepts are central to understanding XML digital
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.
can create a digest to see if it is the same.
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
This means that the contents of the <SignedInfo> structure should not change for the
signature to be
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.
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
information to know how to generate the digest. If the item has not changed, the digest should be the
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.
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.
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.
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:
<Visit date="10pm March 10, 2002">
<Diagnosis>Broken second metacarpal</Diagnosis>
<!-- the SignedInfo element and all it contains is what is signed -->
<!-- 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 -->
<Transforms Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710" />
<DigestMethod Algorithm="http://www.w3.org/2000/07/xmldsig#sha1" />
Short, fixed-length "fingerprint" of referenced item
encoded output of signature algorithm
<!-- Optional KeyInfo used to convey key information needed to verify signature -->
<KeyName>Sally Smith's Integrity Key</KeyName>
<!-- optional Object to allow additional information to be associated with signature,
such as meta information for example (time and purpose of signing) -->
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>:
<Transform Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710" />
<DigestMethod Algorithm="http://www.w3.org/2000/07/xmldsig#sha1" />
<DigestValue> kjsdf </DigestValue>
Example 5 - Reference Transform Using XPath
3.1.2. Confidentiality: XML Encryption (XML Enc)
220.127.116.11. 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:
The recipient may obtain the original content using the following steps:
- Encrypt the content using a symmetric key
- Encrypt the symmetric key using the recipient's public key
- Package the encrypted content, encrypted key and necessary algorithm information together
- Send the package to the recipient
- Unpack the package to obtain the algorithm information, the encrypted symmetric key and the encrypted content
- Decrypt the symmetric key with their private key
- Decrypt the content with the symmetric key
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:
- XML and non-XML content may be encrypted, giving broad applicability to the recommendation.
- 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.
- 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.
- XML Encryption is compatible with and may be used in conjunction with XML Digital Signatures.
XML Encryption allows for encryption of a symmetric key that may be packaged with encrypted content.
XML Encryption supports a variety of encryption algorithms and techniques.
18.104.22.168. Key Concepts
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:
- When an XML element or element content is encrypted, it is replaced by an <EncryptedData> element.
- When non-XML content is encrypted, the result is a new XML document containing an <EncryptedData> element.
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.
- The <EncryptedData> element defines the algorithm used for encryption, provides the
encrypted content, and may include information necessary to determine the key needed for
- The symmetric key used to encrypt content may be conveyed in an <EncryptedKey>
XML Encryption supports the selection of appropriate encryption algorithms and defines XML
identifiers for common cases and may be extended for others.
- Definitions for identifying key information are based on XML Digital
Signature definitions and extended.
- User-defined properties may be associated with an encrypted element, such as a
timestamp or log reference.
The actual cipher text, the result of encryption, is specified using a <CipherData>
This may contain the actual encrypted data within a <CipherValue> element, or a URI
to encrypted data that is stored elsewhere (<CipherReference>). A reference is useful
encrypted data is large and not needed by most parties, such as processing intermediaries.
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
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.
<PatientRecord xmlns="http://www.medical.org/" xmlns:lab="http://www.lab.org/">
<Name> John Doe </Name>
<Account> 123456 </Account>
Example 6 - Encrypted and Signed Document
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
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
<EncryptedKey Id='EK' xmlns='http://www.w3.org/2001/04/xmlenc#'>
Dr Kutter's public key pair
Dr Kutter's symmetric key
<ds:KeyName>Dr Kutter's symmetric key</ds:KeyName>
<Visit date="10pm March 10, 2002">
<Diagnosis>Broken second metacarpal</Diagnosis>
<!-- signature on entire PatientRecord before encryption is default
<KeyName>Sally Smith's Integrity Key</KeyName>
Example 7 - Detailed XML Encryption Example
3.1.3. Key Management: XML Key Management Specification (XKMS)
22.214.171.124. Purpose and Benefits
The XML Key Management Specification (XKMS) [ XKMS ]
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
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
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
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.
The XML Key Management Specification (XKMS) defines three specifications:
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.
- XML Key Registration Service Specification (XKRSS),
- XML Key Information Service Specification (XKISS)
- Protocol Bindings
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:
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.
- Locate - Resolve the <KeyInfo> element to return requested key information
- Validate - Locate key information and provide an assertion on the validity of the binding
to the key pair.
The Protocol Bindings specification defines mechanisms for meeting security requirements, including
mechanisms to ensure message confidentiality, integrity, and security. This includes the following
- 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)
126.96.36.199. Key Concepts
Important points about the XKMS specification are:
- 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).
<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.
The XML Key Information Service Specification (XKISS) includes online status
functionality equivalent to that in traditional PKI OCSP protocols as part of the Validate
Registration supports the requirements of smart card manufacturing, including bulk processing
and pending responses.
The specification supports the use of XML Digital Signatures for message integrity and
specification also defines other authentication mechanisms, support for proof of
key ownership and other
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.
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.
Key usage definition is deliberately limited to Encryption, Signing and Key Exchange.
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.
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):
signing with the private key demonstrates possession of it
Example 8 - XKMS Register Request
The server responds with the information requested with <RespondWith>:
<KeyName>Sally Smith key</KeyName>
Example 9 - XKMS Register Response
A client could request an identity validation:
certificate encoded as text
Example 10 - XKMS Validate Request
The following response indicates that the certificates are valid:
Example 11 - XKMS Validate Response
3.1.4. Authentication and Authorization Assertions: Security Assertion
Markup Language (SAML)
188.8.131.52. 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
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
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.
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.
184.108.40.206. Key Concepts
The SAML specifications define:
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.
- An XML vocabulary for expressing authentication and authorization assertions,
allowing statements about how and when authentication and
authorization occurred to be passed among parties.
- A request response protocol
for conveying SAML assertions, as well as an XML protocol (SOAP) binding.
- Unique identifiers (URNs) for different authentication mechanisms and authorization actions.
- How digital signatures are associated with assertions.
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.
security considerations document discusses issues of security and
privacy associated with SAML. For details see the SAML
specifications [ SAML ].
The following simplified authentication assertion example states
that John Doe was authenticated using SSL client certificate
<!-- Conditions may include optional XML attributes defining a time period for validity -->
<Conditions NotBefore="dateTime" NotOnOrAfter="dateTime">
<!-- limit who can rely on this assertion -->
<!-- Optional Advice used to include supporting evidence, proofs, assertions, pointers
to updates etc. One or more of the possible sub-elements. -->
<!-- refer to other supporting assertion -->
<!-- provide inline information -->
<!-- Authentication - example: SSL client certificate authentication -->
XML Digital Signature for 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 ].
The following example shows a response
permitting John Doe to access a web resource:
<!-- Conditions with optional XML attributes defining a time period for validity -->
<Conditions NotBefore="dateTime" NotOnOrAfter="dateTime">
<!-- limit who can rely on this assertion -->
<!-- Decision choices: "Permit", "Deny", "Indeterminate"-->
<AuthorizationDecisionStatement Resource="http://www.fjhirsch.com/info" Decision="Permit">
XML Digital Signature for assertion
Example 13 - SAML Authorization Assertion
3.1.5. Authorization Rules: XML Access Control Markup Language (XACML)
220.127.116.11. 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 ].
- An XML vocabulary for expressing authorization rules
- An XML vocabulary for expressing a variety of conditions to be used in creating rules.
- How rules are to be combined and evaluated
- A means for creating policy statements, a collection of rules applicable to a subject.
18.104.22.168. Key Concepts
- The XACML draft uses the SAML definitions for subjects and actions.
- XACML defines rules as targets, effects and conditions.
- A target includes resources, subjects and actions, as defined in SAML.
- An effect is either "Allow" or "Deny".
- Conditions are predicates and attributes defined in the XACML specification.
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.com/rules/rule3" Effect="Permit">
<AttributeDesignator AttributeName="patientName" />
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
The XML Security standards form the basis for providing security to other XML-based initiatives, such as Web Services and Digital Rights Management.
22.214.171.124. 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.
Microsoft and IBM have released a Web Services security
architecture and roadmap
[ WebSvcSecRoadmap ]
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, TLS-RFC ]
transport security mechanism, since it defines an end to end
security mechanism and provides support for intermediary
The other specifications will be rolled out in a two-phase process. The
first phase will include specifications necessary for Web Services Security across
- Specify security requirements, capabilities,
constraints and policies on Web Services intermediaries and
- Define security trust model allowing interoperation
across security trust domains
- 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:
- How to dynamically establish trust
across trust domains using key exchange
- How to manage identities and other information
across heterogeneous federated systems
- How to manage authorization data and
policies in a Web Services environment.
126.96.36.199. 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:
- Person, application or business entity that
can send or receive web service messages
- 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.
- 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 ] 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.
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"?>
<!-- WS-Security specific information here -->
<!-- XML Digital Signature on the MsgBody below to provide payload
<!-- the Id provides a simple way for the security part of the header to
refer to the body -->
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:
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.
- ValueType - what it is. Definitions include X.509V3
certificate, Kerberos ticket granting ticket, Kerberos service
- EncodingType - how it was encoded, such as base64 or hex
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
<xenc:DataReference URI="#bodyID" />
<ds:KeyName>CN=Smith Joe, C=US</ds:KeyName>
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
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 ].
3.2.2. Privacy: Platform for Privacy Preferences (P3P)
188.8.131.52. 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.
The Platform for Privacy Preferences [ P3P ]
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.
- An XML vocabulary for expressing user privacy preferences
- An XML vocabulary for expressing site privacy policies
- Mechanisms for retrieving site policies
- Processing rules.
184.108.40.206. 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.
An example meta file from the P3P specification is:
<EXPIRY max-age="172800" />
Example 17 - P3P Site Policy
The P3P specification also defines an XML language for writing a
4000 Lincoln Ave.
alt="PrivacySeal's logo" />
mention that data is purged every two weeks, or provide a link
to this information. -->
<DATA ref="#dynamic.clickstream" />
<DATA ref="#dynamic.http" />
3.2.3. Digital Rights Management: eXtensible rights Markup Language
220.127.116.11. 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.
XrML defines a framework and language for expressing rights, a
definition of terms (a common set of meanings), and a set of
18.104.22.168. Key Concepts
Core concepts defined in XrML include the following:
- 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.
- Collection of grants giving certain rights to
specified resources to certain principals under certain conditions
as well as license issuer information.
- A right issued to a principal against a resource under
- 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.
- 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).
- 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.
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):
<!-- PRINCIPAL specified by public key here -->
<info> <dsig:KeyValue> specify public key </dsig:KeyValue> </info>
<!-- RESOURCE specified by URI -->
<nonSecureIndirect URI="http://www.contentguard.com/sampleBook.spd" />
<!-- collection of GRANTs including general conditions on all -->
<keyHolder licensePartIdRef="issuedToParty" />
<sx:fee>information about the fee, including type, amount, currency, etc</sx:fee>
<!-- RIGHT to play, for the validity interval of 1 year (CONDITION) -->
<cx:digitalWork licensePartIdRef="eBook" />
validity interval, possibly unique identifier
<!-- RIGHT to print, for 5 times (CONDITION) -->
<cx:digitalWork licensePartIdRef="eBook" />
<sx:exerciseLimit>Define use limit, possibly unique identifier</sx:exerciseLimit>
XML Digital Signature of issuer of license
<!-- issue time could be XML property within signature but handled as part of
<issuer> here -->
Example 19 - XrML Digital Rights Definition
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.
The author would like to thank Ed Frankenberry, Lorraine Hirsch and Dan Lanz for reviewing this
document. All errors remain the author's.
- [ 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,
- [ BRML ]
- Business Rules for Electronic Commerce: Project at IBM T.J. Watson Research,
- [ DocBook ]
- The DocBook Document Type Committee Specification 4.2, 16 July 2002,
Document identifier: cs-docbook-docbook-4.2
- [ Kerberos ]
- Kerberos: The Network Authentication Protocol, http://web.mit.edu/kerberos/www/
- [ MathML ]
- Mathematical Markup Language (MathML™) 1.01 Specification
W3C Recommendation, revision of 7 July 1999
- [ Namespaces ]
- Namespaces in XML, World Wide Web Consortium 14-January-1999,
- [ P3P ]
The Platform for Privacy Preferences 1.0 (P3P1.0) Specification
- W3C Recommendation 16 April 2002,
- [ PKI ]
Public-Key Infrastructure (X.509) (pkix),
- [ RDF ] Resource Description Framework (RDF)
- See specifications and primer at
- [ RSS ]
- RDF Site Summary (RSS) 1.0, December 6, 2000, http://purl.org/rss/1.0/spec
- [ SAML ] Security Assertion Markup Language
- [ SOAP ] Simple Object Access Protocol
- SOAP Version 1.2 Part 0: Primer, W3C Working Draft 26 June 2002,
SOAP Version 1.2 Part 1: Messaging Framework, W3C Working Draft 26 June 2002,
SOAP Version 1.2 Part 2: Adjuncts, W3C Working Draft 26 June 2002
- [ SSLIntro] Introducing SSL and Certificates using SSLeay
- Somewhat dated article (1997) providing an introduction to SSL/TLS:
- [ TLSRFC ] RFC 2246, The TLS Protocol, Version 1.0
- RFC 2246 , January 1999
- [ URI]
- Uniform Resource Identifiers (URI): Generic Syntax, RFC 2396, August 1998,
- [ 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 ,
- [ WSDL ]
- Web Services Description Language (WSDL) Version 2.0, W3C Working Draft 3 August 2004,
- [ WS-Security ] Web Services Security: SOAP Message Security 1.0
See related material on OASIS web site: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
- [ X509Cert ]
- [ XACML ] OASIS extensible Access Control Markup Language (XACML) Version 2.0
- OASIS Standard, 1 Febrary 2005
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml for more information.
- [ XHTML ]
- XHTML™ 1.0: The Extensible HyperText Markup Language, A Reformulation of HTML 4 in XML 1.0,
W3C Recommendation 26 January 2000,
- [ XKMS ] XML Key Management Specification 2.0 (XKMS)
- W3C Working Draft 18 March 2002,
- [ XML ]
- Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation 6 October 2000
- [ XMLCanon]
Canonical XML, Version 1.0, W3C Recommendation 15 March 2001,
Exclusive XML Canonicalization, Version 1.0, W3C Proposed Recommendation 24 May 2002,
- [ XMLDecTrans ]
- Decryption Transform for XML Signature, W3C Candidate Recommendation, 04 March 2002
- [ XML DigSig ] XML-Signature Syntax and Processing
- W3C Recommendation 12 February 2002,
- [ XML Enc ] XML Encryption Syntax and Processing
- W3C Candidate Recommendation 04 March 2002,
- [ XMLProt ]
- XML Protocol Abstract Model, W3C Working Draft 9 July 2001,
- [ XMLRef ]
- "Essential XML Quick Reference", Skonnard, Gudgin, Addison-Wesley, 2002
- [ XPath ]
- XML Path Language (XPath), Version 1.0, W3C Recommendation, 16 November 1999
- [ XPathFilter ]
- XML-Signature XPath Filter 2.0, W3C Candidate Recommendation, 18 July 2002
- [ XrML ] extensible rights Markup Language
(XrML) 2.0 Specification
- 20 November 2001 Available upon registration from