XML Security

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

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

3.1. Core XML Security Standards

The core XML Security standards are:

1. XML Digital Signature for integrity and signatures,

2. XML Encryption for confidentiality,
3. XML Key Management (XKMS) for key management,
4. Security Assertion Markup Language (SAML) for making authentication and authorization assertions, and
5. XML Access Control Markup Language (XACML) for stating authorization rules.

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

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

3.1.1. Integrity & Signatures: XML Digital Signature (XML DigSig)

3.1.1.1. Purpose and Benefits

Digital signatures are useful for two purposes:

 1. To provide persistent content integrity, and
2. To create and verify portable electronic signatures

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

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

3.1.1.2. Features

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

1. Entire XML documents as well as element and element content portions of XML documents,
2. Arbitrary documents, including binary documents,
3. Compound documents including multiple documents and/or XML elements and element contents,
4. Properties to be included with a signature,
5. Counter-signatures (signatures that include other signatures)
In addition, the XML Signature recommendation supports the application of multiple XML Signatures to an XML document or
to different sections of a document, supporting a variety of use cases. The XML Digital Signature specification and related
specifications (XML Canonicalization) also define techniques so that signature verification can be robust even with variations
allowed in XML, such as whitespace. The reason for the concern is that cryptographic algorithms are concerned with exact text,
yet XML allows some flexibility. Canonicalization is used to reduce variations so that all XML Security applications can
interoperate.

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

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

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

Example 2 - Enveloped Signature

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

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

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

Example 3 - Enveloping Signature

3.1.1.3. Key Concepts

The following concepts are central to understanding XML digital signatures:

1. A signature is only valid if the signed content has not changed. This content is represented using a short, fixed-length
digest, designed to change if the content changes. Thus a signature will only be valid if a digest used to create a signature
is the same as a digest used to verify it later. A verifier can create a digest to see if it is the same.
2. An XML <Signature> element is an XML structure that contains a cryptographic signature value in a <SignatureValue>
element as well as an XML structure that has been signed, the <SignedInfo> structure. This means that the contents of the
<SignedInfo> structure should not change for the signature to be valid.
3. The signer creates a <Reference> for each item to be included in a signature. Each <Reference> includes a digest of the
item and a unique identifier (URI) for the item. It also identifies how to recreate the digest, specifying the algorithm and
other necessary information. Each Reference is part of the <SignedInfo> structure.

To verify a signature, a recipient must validate each <Reference> by independently generating the same digest for the
item. The verifier may use the URI to aid locating the item, and the algorithm information to know how to generate the
digest. If the item has not changed, the digest should be the same.

4. 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.
5. 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.
6. 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.
3.1.1.4. Examples

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

<PatientRecord xmlns="http://www.medical.org/">
<Name>John Doe</Name>
<account id="acct">123456</Account>
<Visit date="10pm March 10, 2002">
<Diagnosis>Broken second metacarpal</Diagnosis>
<lab:Diagnosis><lab:Xray>xhzhez</lab:Xray></lab:Diagnosis>
</Visit>
<Signature xmlns='http://www.w3.org/2000/09/xmldsig#'>
<!-- the SignedInfo element and all it contains is what is signed -->
<SignedInfo>

<!-- Canonicalization is used to ensure that XML is handled consistently by

different XML processors in light of white space and other variations. -->
<CanonicalizationMethod algorithm="URI for algorithm" />

<!-- the SignatureMethod is protected by the signature, avoiding substitution attacks

and defines how the signature is created -->
<SignatureMethod Algorithm="http://www.w3.org/2000/07/xmldsig#rsa-sha1" />

<!-- each item to be signed, XML document, portion of XML document

 or arbitrary content is represented using a Reference. Each Reference contains
a digest of the item, a URI to refer to the item, and possibly
transforms to apply to the item before creating the digest -->
<Reference URI="">
<Transforms Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710" />
<DigestMethod Algorithm="http://www.w3.org/2000/07/xmldsig#sha1" />
<DigestValue>
Short, fixed-length "fingerprint" of referenced item
</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>
encoded output of signature algorithm
</SignatureValue>

<!-- Optional KeyInfo used to convey key information needed to verify signature -->
<KeyInfo>
<KeyName>Sally Smith's Integrity Key</KeyName>
</KeyInfo>

<!-- optional Object to allow additional information to be associated with signature,

such as meta information for example (time and purpose of signing) -->
<Object>
<SignatureProperties>
<p:Purpose xmlns:p="http://www.myexample.com/schemas">
Integrity
</p:Purpose>
</SignatureProperties>
 </Object>
</Signature>
</PatientRecord>

Example 4 - Detailed XML Signature Example

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

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

Example 5 - Reference Transform Using XPath

3.1.2. Confidentiality: XML Encryption (XML Enc)

3.1.2.1. Purpose and Benefits

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

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

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

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

1. Encrypt the content using a symmetric key

2. Encrypt the symmetric key using the recipient's public key
3. Package the encrypted content, encrypted key and necessary algorithm information together
4. Send the package to the recipient
The recipient may obtain the original content using the following steps:

1. Unpack the package to obtain the algorithm information, the encrypted symmetric key and the encrypted content
2. Decrypt the symmetric key with their private key
3. Decrypt the content with the symmetric key

3.1.2.2. Features

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

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

3.1.2.3. Key Concepts

1. When an XML element or element content is encrypted, it is replaced by an <EncryptedData> element.

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

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

<PatientRecord xmlns="http://www.medical.org/" xmlns:lab="http://www.lab.org/">

<Name> John Doe </Name>
<Account> 123456 </Account>
<EncryptedData Type='element'>
...
</EncryptedData>
<Signature>
<SignedInfo>
<Reference URI="">
...
 </Reference>
</SignedInfo>
</Signature>
</PatientRecord>

Example 6 - Encrypted and Signed Document

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

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

3.1.2.4. Examples

Use of both <EncryptedData> and <EncryptedKey> elements may be summarized using the previous example where the
account information is encrypted for confidentiality. Additional information on the EncryptedData and EncryptedKey portions
of this example are explained in the XML Encryption candidate recommendation [ XML Enc ]:
<PatientRecord xmlns="http://www.medical.org/"
xmlns:lab="http://www.lab.org/tests">
<Name>John Doe</Name>
<EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'
xmlns='http://www.w3.org/2001/04/xmlenc#'>
<EncryptionMethod
Algorithm='http://www.w3.org/2001/04/xmlenc#3des-cbc'/>

<ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
<EncryptedKey Id='EK' xmlns='http://www.w3.org/2001/04/xmlenc#'>
<EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />

<ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
<ds:KeyName>
Dr Kutter's public key pair
</ds:KeyName>
</ds:KeyInfo>
<CipherData><CipherValue>xyzabc</CipherValue></CipherData>
<CarriedKeyName>
Dr Kutter's symmetric key
</CarriedKeyName>
</EncryptedKey>
<ds:KeyName>Dr Kutter's symmetric key</ds:KeyName>
</ds:KeyInfo>
<CipherData>
<CipherValue> a17xj2z</CipherValue>
</CipherData>
 </EncryptedData>
<Visit date="10pm March 10, 2002">
<Diagnosis>Broken second metacarpal</Diagnosis>
<lab:Diagnosis><lab:Xray>xhzhez</lab:Xray></lab:Diagnosis>
</Visit>
<Signature xmlns='http://www.w3.org/2000/09/xmldsig#'>
<SignedInfo>
<SignatureMethod
Algorithm="http://www.w3.org/2000/07/xmldsig#rsa-sha1" />
<!-- signature on entire PatientRecord before encryption is default
interpretation -->
<Reference URI="">
<Transforms
Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710"/>

<DigestMethod
Algorithm="http://www.w3.org/2000/07/xmldsig#sha1" />
<DigestValue>kjsdf</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>xjksdasd</SignatureValue>
<KeyInfo>
<KeyName>Sally Smith's Integrity Key</KeyName>
</KeyInfo>
</Signature>
</PatientRecord>
Example 7 - Detailed XML Encryption Example

3.1.3. Key Management: XML Key Management Specification (XKMS)

3.1.3.1. 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 protocols.

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

3.1.3.2. Features

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

 XML Key Registration Service Specification (XKRSS),

 XML Key Information Service Specification (XKISS)
 Protocol Bindings

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

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

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

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

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

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

 A two phase protocol to avoid replay attacks

 Pending response protocol
 Use of payload security
 Use of transport security such as SSL/TLS
 Use of Web Services security (see below)

3.1.3.3. Key Concepts

Important points about the XKMS specification are:

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

3.1.3.4. Examples

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

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

Example 8 - XKMS Register Request

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

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

Example 9 - XKMS Register Response

A client could request an identity validation:

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

Example 10 - XKMS Validate Request

The following response indicates that the certificates are valid:

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

Example 11 - XKMS Validate Response

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

3.1.4.1. Purpose and Benefits

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

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

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

3.1.4.2. Features

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

3.1.4.3. Key Concepts

The SAML specifications define:

 1. An XML vocabulary for expressing authentication and authorization assertions, allowing statements about how and when
authentication and authorization occurred to be passed among parties.
2. A request response protocol for conveying SAML assertions, as well as an XML protocol (SOAP) binding.
3. Unique identifiers (URNs) for different authentication mechanisms and authorization actions.
4. How digital signatures are associated with assertions.

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

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

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

3.1.4.4. Examples

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

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

Example 12 - SAML Authentication Assertion

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

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

<Assertion>
<!-- Conditions with optional XML attributes defining a time period for validity -->
<Conditions NotBefore="dateTime" NotOnOrAfter="dateTime">
<!-- limit who can rely on this assertion -->
<AudienceRestrictionCondition>
<Audience>http:/www.example.com/Members</Audience>
</AudienceRestrictionCondition>
</Conditions>

<!-- Decision choices: "Permit", "Deny", "Indeterminate"-->

<AuthorizationDecisionStatement Resource="http://www.fjhirsch.com/info" Decision="Permit">
<Subject>
<NameIdentifier
Format="urn:oasis:names:tc:SAML:1.0:assertion#emailAddress">
[email protected]
</NameIdentifier>
</Subject>
<Action Namespace="urn:oasis:names:tc:SAML:1.0:action:rwedc">
Read
</Action>
<Evidence>
<AssertionIDReference>LOG-Abc12Z</AssertionIDReference>
 </Evidence>
</AuthorizationDecisionStatement>
<ds:Signature>
XML Digital Signature for assertion
</ds:Signature>
</Assertion>

Example 13 - SAML Authorization Assertion

3.1.5. Authorization Rules: XML Access Control Markup Language (XACML)

3.1.5.1. 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 ].

3.1.5.2. Features

XACML defines:

1. An XML vocabulary for expressing authorization rules

2. An XML vocabulary for expressing a variety of conditions to be used in creating rules.
3. How rules are to be combined and evaluated
4. A means for creating policy statements, a collection of rules applicable to a subject.

3.1.5.3. Key Concepts

1. The XACML draft uses the SAML definitions for subjects and actions.
 2. XACML defines rules as targets, effects and conditions.
3. A target includes resources, subjects and actions, as defined in SAML.
4. An effect is either "Allow" or "Deny".
5. Conditions are predicates and attributes defined in the XACML specification.

3.1.5.4. Examples

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

<Rule RuleId="//medico.com/rules/rule3" Effect="Permit">

<Target>
<Subjects>
<saml:Attribute AttributeName="RFC822Name"
AttributeNamespace="//medico.com">
<saml:AttributeValue>*</saml:AttributeValue>
</saml:Attribute>
</Subjects>
<Resources>
<saml:Attribute AttributeName="documentURI"
AttributeNamespace="//medico.com">
<saml:AttributeValue>//medico.com/records.*</saml:AttributeValue>
</saml:Attribute>
</Resources>
<Actions>
<saml:Action>read</saml:Action>
</Actions>
 </Target>
<Condition>
<Equal>
<AttributeDesignator
AttributeName="urn:oasis:names:tc:xacml:identifiers:AccessSubject" />
<AttributeDesignator AttributeName="patientName" />
</Equal>
</Condition>
</Rule>

Example 14 - XACML Access Rule

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