The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
Advanced Search
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

Cover Stories
Articles & Papers
Press Releases

XML Query

XML Applications
General Apps
Government Apps
Academic Apps

Technology and Society
Tech Topics
Related Standards
Created: July 12, 2005.
News: Cover StoriesPrevious News ItemNext News Item

Final Release of the Java XML Digital Signature API Specification (JSR 105).


Developers from Sun, IBM, and other companies have announced the final release of Java XML Digital Signature API Specification (JSR 105) Version 1.0, produced under the Java Community Process (JCP). The purpose of this Java Specification Request is "to define a standard Java API for generating and validating XML signatures. The APIs for XML digital signatures services of JSR 105 implement the W3C XML-Signature Syntax and Processing Recommendation, and provide for support of the W3C XML-Signature XPath Filter 2.0 and Exclusive XML Canonicalization Version 1.0 Recommendations.

JSR 105 was developed by members of the JSR 105 Expert Group under the direction of Specification Leads Anthony Nadalin (IBM) and Sean Mullan (Sun Microsystems), who continue jointly in the role of JSR 105 Maintenance Lead.

The Java Community Process under which which JSR 105 was developed is a standards framework which "produces high-quality specifications in 'Internet time' using an inclusive, consensus building approach that produces a specification, a reference implementation (to prove the specification can be implemented), and a technology compatibility kit (a suite of tests, tools, and documentation that is used to test implementations for compliance with the specification). JCP participants include the international Java community, working to develop and evolve Java technology specifications."

JSR 105 has been approved in a Final Approval Ballot with votes from by Apache Software Foundation, Apple Computer, Inc., BEA Systems, Fujitsu Limited, Hewlett-Packard, IBM Corp., Intel Corp., IONA Technologies PLC, JBoss, Inc., Nortel Networks, SAP AG, and Sun Microsystems, Inc.

The Java XML Digital Signature API Specification supports software development projects that need to use the JSR 105 API to generate and validate XML signatures. It is also designed for use by Java programmers "who want to create a concrete implementation of the JSR 105 API and register it as a cryptographic service of a JCA provider. A cryptographic service provider is a package or set of packages that supply a concrete implementation of a subset of the Java 2 SDK Security API cryptography features."

The JSR proposal was to define and incorporate the high level implementation independent Java APIs for the XML Digital Signature specification as defined by the W3C. The W3C/IETF XML DSig Recommendation "specifies XML syntax and processing rules for creating and representing digital signatures. XML Signatures can be applied to any digital content (data object), including XML. An XML Signature may be applied to the content of one or more resources. Enveloped or enveloping signatures are over data within the same XML document as the signature; detached signatures are over data external to the signature element. More specifically, the specification defines an XML signature element type and an XML signature application; conformance requirements for each are specified by way of schema definitions and prose respectively. The XML DSig specification also includes other useful types that identify methods for referencing collections of resources, algorithms, and keying and management information."

The JSR 105 API specification contains six packages. Common classes for XML cryptography are included in the javax.xml.crypto package, which defines classes "used to perform XML cryptographic operations such as generating an XML signature or encrypting XML data; it allows developers to supply implementations which locate and optionally validate keys using the information contained in a KeyInfo object, and provided a URIDereferencer class which allows developers to create and specify their own URI dereferencing implementations." Classes for generating and validating XML digital signatures are defined in the javax.xml.crypto.dsig package, includes interfaces that represent the core elements defined in the W3C XML digital signature specification. A javax.xml.crypto.dsig.spec package "contains interfaces and classes representing input parameters for the digest, signature, transform, or canonicalization algorithms used in the processing of XML signatures." Two packages contain (W3C) DOM-specific classes, and a 'keyinfo' package provides classes for parsing and processing KeyInfo elements and structures.

API dependencies for JSR 105 include J2SE (JDK) 1.2 or higher, and the W3C DOM Level 2 API (required by classes of the javax.xml.crypto.dom and javax.xml.crypto.dsig.dom packages). Required support is specified for DOM as a default XML mechanism type, and the API SHOULD ensure that applications using a DOM implementation are portable and interoperable. On the other hand, the requirements provide for a DOM-independent API in the sense that it must be possible to create implementations of the API for different XML processing and mechanism representations, such as DOM, JDOM or dom4j. Further, it must be possible for a third-party to create and plug in an implementation responsible for managing and creating cryptographic and transform algorithms, dereferencing URIs, and marshalling objects to/from XML."

A Reference Implementation for JSR 105 is available as part of the Java Web Services Developer Pack 1.6. In the JCP, a reference implementation (RI) is a prototype or proof-of-concept implementation of a specification which accompanies the required Technology Compatibility Kit (TCK). The Java Web Services Developer Pack (Java WSDP) is "a free integrated toolkit you can use to build, test and deploy XML applications, Web services, and Web applications with the latest Web service technologies and standards implementations. It contains Fast Infoset technology that can increase Web services performance 2-4x by using ANS.1-based binary encodings that decrease transmission and processing times for messages compared to times for XML (ASCII) messages. The Pack also includes a preview of the next generation of XML Web Services Security, a preview of the Service Registry for SOA (service-oriented architecture) applications." The source code for the JSR 105 reference implementation is available through the Java Research License (JRL).

As required as by the Java Community Process version 2.1, a Technology Compatibility Kit (TCK) for JSR 105 is also available to (help) "verify whether an implementation of the specification is compliant. This TCK, along with source code for the reference implementation, are available for licensing through the Java Distribution License (JDL). The TCK is also separately available for licensing. The TCK is available to Qualified Not-for-Profits and Qualified Individuals for no charge, as per Section F.III of the Java Specification Participation Agreement," explained in connection with the Compatibility Testing Scholarship Program.

Three examples in the JSR 105 final release demonstrate how to generate different types of simple XML Digital Signature using the API (generating a detached XML Digital Signature; generating an enveloped XML Digital Signature; generating an enveloping XML Digital Signature). Other prepared examples show how to generate an enveloping signature, how to validate an XML Signature. One of the six examples demonstrates how to construct, sign and validate a SOAP message using the SAAJ and JSR 105 APIs; another provides a sample implementation of a KeySelector that finds a trusted key from X.509 content contained in X509Data KeyInfo types. A hyperlinked Index document contains an alphabetic list of all classes, interfaces, constructors, methods, and fields.

Bibliographic Information

Java XML Digital Signature API 1.0 Final Release. Java Specification Request (JSR) 105. Copyright (c) 2003-2005, Sun Microsystems, Inc. and IBM Corporation.

Acknowledgements are given to members of the JSR 105 Expert Group: Nicolas Catania (Hewlett-Packard), Donald E. Eastlake 3rd (Motorola), Christian Geuer-Pollmann (Apache Software Foundation), Hans Granqvist (VeriSign), Kazuyuki Harada (Fujitsu), Anthony Ho (DSTC), Merlin Hughes (Baltimore Technologies), Joyce Leung (IBM), Gregor Karlinger (IAIK), Serge Mister (Entrust Technologies), Takuya Mori (NEC Corporation), Sean Mullan (Sun Microsystems - Co-Specification Lead), Anthony Nadalin (IBM - Co-Specification Lead), Erwin van der Koogh (Apache Software Foundation), and Chris Yeung (XML Asia).

Special thanks to: Valerie Peng, Vincent Ryan, Sharon Liu, Chok Poh, K. Venugopal Rao., Paul Rank, Alexey Gavrilov, Bill Situ, Eric Jendrock, Andrew Fan, Manveen Kaur, Tom Amiro, Michael Mi, Dmitri Silaev, Roman Makarchuk, Vanitha Venkatraman, Arkadiy Sutchilin, and Scott Fordin from Sun Microsystems, Vishal Mahajan from Apache, and Martin Centner from IAIK.

Related Security Specifications

The final release version of JSR 105 references three other security specifications. The primary document is the XML Signature Recommendation: requirements specify that the API "must allow a programmer to generate and validate XML Signatures such that all of the 'SHOULD' and 'MUST' requirements specified by the W3C XML-DSig recommendation can be satisfied, and that the API must allow an implementation of the API to be created such that all of the SHOULD and MUST requirements specified by the W3C XML-DSig recommendation can be satisfied. Further, an implementation should support the W3C Recommendation, XML-Signature XPath Filter Transform 2.0, and an implementation should support the W3C Recommendation, Exclusive XML Canonicalization Version 1.0." References:

  • XML-Signature Syntax and Processing. W3C Recommendation. 12-February-2002. Also published as IETF Standards Track RFC 3275. Produced by members of the IETF/W3C XML Signature Working Group. The document "specifies XML digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere... The XML Signature is a method of associating a key with referenced data (octets); it does not normatively specify how keys are associated with persons or institutions, nor the meaning of the data being referenced and signed. Consequently, while this specification is an important component of secure XML applications, it itself is not sufficient to address all application security/trust concerns, particularly with respect to using signed XML (or other data formats) as a basis of human-to-human communication and agreement. Such an application must specify additional key, algorithm, processing and rendering requirements..."

  • XML-Signature XPath Filter 2.0. W3C Recommendation. 08-November-2002. Produced by members of the IETF/W3C XML Signature Working Group. The XML-Signature Syntax and Processing recommends a standard means for specifying information content to be digitally signed and for representing the resulting digital signatures in XML. Some applications require the ability to specify a subset of a given XML document as the information content to be signed. The XML Signature specification meets this requirement with the XPath transform. However, this transform can be difficult to implement efficiently with existing technologies. This [XML-Signature XPath Filter 2.0] specification defines a new XML Signature transform to facilitate the development of efficient document subsetting implementations that interoperate under similar performance profiles. It provides a method for computing a portion of a document to be signed. In the interest of simplifying the creation of efficient implementations, the architecture of this transform is not based on evaluating an XPath expression for every node of the XML parse tree (as defined by the XPath data model). Instead, a sequence of XPath expressions is used to select the roots of document subtrees — location sets, in the language of XPointer — which are combined using set intersection, subtraction and union, and then used to filter the input node-set..."

  • Exclusive XML Canonicalization Version 1.0. W3C Recommendation. 18-July-2002. The Canonical XML Recommendation "specifies a standard serialization of XML that, when applied to a subdocument, includes the subdocument's ancestor context including all of the namespace declarations and attributes in the xml: namespace. However, some applications require a method which, to the extent practical, excludes ancestor context from a canonicalized subdocument. For example, one might require a digital signature over an XML payload (subdocument) in an XML message that will not break when that subdocument is removed from its original message and/or inserted into a different context. This requirement is satisfied by Exclusive XML Canonicalization. The goal of this [Exclusive XML Canonicalization] specification is to establish a method for serializing the XPath node-set representation of an XML document or subset such that: (1) The node-set is minimally affected by any XML context which has been omitted; (2) The canonicalization of a node-set representing well-balanced XML will be unaltered by further applications of exclusive canonicalization; (3) It can be determined whether two node-sets are identical except for transformations considered insignificant by this specification under XML 1.0 and Namespaces in XML..."

About the Java Community Process (JCP)

"The international Java community develops and evolves Java technology specifications using the Java Community Process (JCP). The JCP produces high-quality specifications in "Internet time" using an inclusive, consensus building approach that produces a specification, a reference implementation (to prove the specification can be implemented), and a technology compatibility kit (a suite of tests, tools, and documentation that is used to test implementations for compliance with the specification).

Experience has shown that the best way to produce a technology specification is to gather a group of industry experts who have a deep understanding of the technology in question and then have a strong technical lead work with that group to create a first draft. Consensus around the form and content of the draft is then built using an iterative review process that allows an ever-widening audience to review and comment on the document.

Since its introduction in 1998 as the open, participative process to develop and revise the Java technology specifications, reference implementations, and test suites, the Java Community Process (JCP) program has fostered the evolution of the Java platform in cooperation with the international Java developer community. The JCP has over 900 company and individual participants; more than 275 Java technology specifications are in development in the JCP program out of which 45% are in final stages.

[Any person or organization] can become a JCP member by signing the Java Specification Agreement (JSPA). The JSPA is an agreement between a company, organization or individual, and Sun, setting out each Community Member's rights and obligations when participating on the development of Java technology specifications in the JCP.

A JSR is a Java Specification Request. This is the document submitted to the PMO by one or more members to propose the development of a new specification or significant revision to an existing specification. There are currently [multiple dozens of] Java technology specifications in development in the JCP program, including the next versions of Java 2, Micro Edition (J2ME), Java 2 Platform Enterprise Edition (J2EE), and Java 2 Standard Edition (J2SE)..." [from the FAQ and Overview]

Principal References

Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation


XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Bottom Globe Image

Document URI:  —  Legal stuff
Robin Cover, Editor: