Chapter 6. XPath: A Basic Building Block

The XML Security standards need a data model for and means of expressing operations on XML, particularly extraction of subdocuments. This need could entail modeling parsed XML and sending input to an application from an external encoding or XML that an application constructs internally and has not yet output.

For example, an XML document might represent a user form. Assume that a user fills in several fields that XML elements represent and then wants to digitally sign those fields. As Chapter 10 describes in detail, the signature object needs some method of specifying or pointing to these fields. XPath provides the necessary data model and method.

It might seem that meeting this goal would be easy because one data model would be in use throughout the XML standards, or at least throughout the XML standards issued by the W3C. After all, the W3C promotes tight integration of its standards activities, and its working group charters include mandatory review by related W3C working groups. In reality, the XML Recommendation, XML [Infoset], different levels of the Document Object Model [DOM], XPath, and so on all have somewhat different data models. Matters get even worse when you consider XML schema augmented infosets [Schema].

The XPath data model was chosen for two reasons:

• Subdocument extraction is necessary for both XML digital signatures and XML encryption: in the first instance when a subdocument is extracted for signing, and in the second instance when a subdocument is extracted for decryption. Both need a language such as XPath or XPointer (which is based on XPath) to express these operations.

• The data model must preserve literal prefix names, because these names can appear in patterns within attribute values or element content for XSLT and other XML standards, and they must be output as read or generated.

Given these requirements and this view of the best XML data model, it is not surprising that XML canonicalization is also based on XPath.

XPath is closely related to XSLT and XPointer. XPath was developed when it was found that both XSLT and XPointer need similar capabilities. XPath's initial goal was to support both of them.

Because XML canonicalization, signatures, and encryption all make use of XPath, at least for expository purposes, a general understanding of XPath is important to understanding these XML security standards. See Figure 6-1.

Figure 6-1. Some dependencies on xpath

If you are already familiar with XPath, you can skip this chapter. If you want more details on XPath, see the XPath Recommendation [XPath]. It assumes that XPath is operating on a node-set produced from an entire document. In XML Security, however, an XPath node-set often exists for a document subset.

The use of XPath to describe some operations in XML Security does not imply that the application must implement the full capabilities of XPath. Rather, an application typically needs only a subset of these features. Any method that produces the same results is considered acceptable.