The Java Community Process(SM) Program - JSRs: Java Specification Requests

Printed: Jan 14, 2025
From: http://jcp.org/en/jsr/detail?id=105

Summary | Proposal | Detail (Summary & Proposal) | Nominations

JSRs: Java Specification Requests

JSR 105: XML Digital Signature APIs

Stage	Access	Start	Finish
Final Release	Download page	24 Jun, 2005
Final Approval Ballot	View results	24 May, 2005	06 Jun, 2005
Proposed Final Draft	Download page	16 Apr, 2004
Public Review	Download page	30 May, 2003	29 Jun, 2003
Community Draft Ballot	View results	01 Apr, 2003	07 Apr, 2003
Community Review	Login page	06 Mar, 2003	07 Apr, 2003
Expert Group Formation		13 Mar, 2001	02 Oct, 2002
JSR Review Ballot	View results	27 Feb, 2001	12 Mar, 2001

Status: Final
JCP version in use: 2.9
Java Specification Participation Agreement version in use: 2.0

Description:
This defines and incorporates a standard set of high-level implementation-independent APIs for XML digital signatures services. The XML Digital Signature specification is defined by the W3C.

Expert Group Transparency:
Public Communications
Issue Tracking

Team

Specification Leads
	Sean Mullan	Sun Microsystems, Inc.
	Sean Mullan	Oracle

Expert Group
	Apache Software Foundation : Christian Geuer-Pollmann	Apache Software Foundation : Erwin van der Koogh	Betrusted Inc. : Merlin Hughes
	Fujitsu Limited : Kazuyuki Harada	Hewlett-Packard : Nicolas Catania	IAIK Graz University of Technology : Gregor Karlinger
	IBM : Yanni Zhang	Motorola : Donald E. Eastlake 3rd	NEC Corporation : Takuya Mori
	Oracle : Sean Mullan	Sun Microsystems, Inc. : Sean Mullan

Contributors

Updates to the Original Java Specification Request (JSR)

The following information has been updated from the original JSR.

2014.01.14:
JSR 105 is delivered in both a standalone manner and as part of the Java SE Platform (since Java SE 6). However, the JSR 105 API has been very stable since its initial release in 2005 and the need to provide standalone implementations on releases prior to SE 6 has diminished over time.

In accordance with the JCP 2.9 Process Document, 2.1.4 Platform Inclusion, we are announcing the end of the JSR 105 Standalone distribution. After this, JSR 105 will be delivered only as a part of Java SE. Future changes to the JSR 105 API will be defined through the Platform JSR. The subsumption of the JSR 105 API into the Platform JSR does not change any mechanisms defined in JSR 105. The service provider interfaces are the same except that they will now be directly specified in the Platform JSR. Deployment of alternative implementations of the JSR 105 APIs will continue to be supported. This change will take effect as of Java SE 9.

2014.01.13:
The Maintenance Lead moved this JSR to JCP 2.9.

2.15 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:

Is the schedule for the JSR publicly available, current, and updated regularly?

When the JSR was being developed, the schedule was posted and kept up-to-date on the JSR page. The JSR was completed in 2005 and has not required any updates since. This will be the first Maintenance Release.

Can the public read and/or write to a wiki for the JSR?

There is no wiki currently available, but if necessary, one would likely be created at https://wiki.openjdk.java.net.

Where is the issue-tracker for my JSR that the public can read?

https://bugs.openjdk.java.net/issues/

Do you have a Twitter account or other social media outlet that people could follow for updates on the JSR?

Yes: @seanjmullan

Have you spoken at conferences and events about the JSR recently?

No, not recently.

Are you using open-source processes for the development of the RI and/or the TCK?

Yes for the RI.

Have you updated the Community tab for the JSR with links to and information about all public communication mechanisms and sites for the development of your JSR?

No, but there is a link on that page to contact me.

2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

The RI and TCK were originally delivered both standalone and as part of Java SE platform edition (SE 6).

With the upcoming Maintenance Release, we are proposing to discontinue the standalone version and only include it in Java SE going forward.

2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

JSR 105 is delivered in both a standalone manner and as part of the Java SE Platform (since Java SE 6). The JSR 105 API has been very stable since its initial release in 2005 and the need to distribute a standalone version has diminished over time.

In accordance with the JCP 2.9 Process Document, 2.1.4 Platform Inclusion, we are announcing the end of the JSR 105 Standalone distribution. After MR1, JSR 105 will be delivered as a part of the Java SE solely. Future changes to the JSR 105 API will be defined through the Platform JSR. The subsumption of the JSR 105 API into the Platform JSR does not change any mechanisms defined in JSR 105. The service provider interfaces are the same except that they will then be directly specified in the Platform JSR. Deployment of alternative implementations of the JSR 105 APIs will continue to be supported.

2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

These will be using the same licenses as the Java SE Platform edition.

2.19 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.

Please use http://mail.openjdk.java.net/mailman/listinfo/security-dev

2.20 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?

https://bugs.openjdk.java.net/issues/

2.21 Please provide the location of the publicly accessible document archive you have created for the Expert Group.

http://cr.openjdk.java.net

2005.06.24:
This JSR was completed under JCP 2.1 with Sun Microsystems as Specification Lead.

2.11 Please describe the anticipated schedule for the development of this specification.

Expert Group JCP Schedule (all dates are tentative)

May 7: release rev 0.3
June 3: release rev 0.4
July 1: release rev 0.5 (if necessary)
July 29: release community draft
September: release public draft
November: release proposed final draft

Original Java Specification Request (JSR)

Identification | Request | Contributions

Original Summary: This JSR is to define a standard set of APIs for XML digital signatures services. The XML Digital Signature specification is defined by the W3C. This proposal is to define and incorporate the high level implementation independent Java APIs.

Section 1. Identification

Submitting Member: IBM

Name of Contact Person: Anthony Nadalin or Maxine Erlund

E-Mail Address: Anthony Nadalin - drsecure@us.ibm.com, Maxine Erlund - maxine.erlund@eng.sun.com

Telephone Number: Anthony Nadalin - +1 512 436 9568, Maxine Erlund - +1 408 517 5486

Fax Number: Anthony Nadalin - +1 512 838 3823, Maxine Erlund - +1 408 863 3155

Specification Lead: Anthony Nadalin and Sean Mullan

E-Mail Address: Anthony Nadalin - drsecure@us.ibm.com, Sean Mullan - sean.mullan@ireland.sun.com

Telephone Number: Anthony Nadalin - +1 512 436 9568, Sean Mullan - +353 1819 9176

Fax Number: Anthony Nadalin - +1 512 436 9568

Initial Expert Group Membership:
(Please provide company or organization names. Note that expert group members must have signed the JSPA.)

IBM - Anthony Nadalin

Sun - Sean Mullan

Section 2: Request

2.1 Please describe the proposed Specification:

This JSR is to define a standard set of APIs for XML digital signatures services. The XML Digital Signature specification is defined by the W3C. 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 XML Digital Signature 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 Digital Signature specification also includes other useful types that identify methods for referencing collections of resources, algorithms, and keying and management information.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

JDK 2 SDK, Standard Edition, V 1.3 and above

2.3 What need of the Java community will be addressed by the proposed specification?

Today there is no standard of APIs for XML digital signatures services. This JSR provides a Java API to the XML Digital Signature services.

2.4 Why isn't this need met by existing specifications?

There is no existing specification in JDK 2 SDK for accessing XML Digital Signature via a standard set of APIs.

2.5 Please give a short description of the underlying technology or technologies:

The XML Digital Signature specifies XML syntax and processing rules for creating and representing digital signatures. The XML Signature is a method of associating a key with referenced data; 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 the XML Digital Signature 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 and developers must give consideration to their application threat models.

2.6 Is there a proposed package name for the API Specification? (i.e., `javapi.something`, `org.something`, etc.)

javax.security.xml.dsig

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

2.8 Are there any security issues that cannot be addressed by the current security model?

2.9 Are there any internationalization or localization issues?

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

2.11 Please describe the anticipated schedule for the development of this specification.

NOTE that this information has been updated from the original JSR. Please go here to view the updated information.

I'd like to propose a 9-12 week schedule, with 2-3 internal review cycles within that timeframe:

6/1 Release API docs and preliminary spec.
9/25 Comments on first draft due
10/16 2nd draft released
10/30 Comments on 2nd draft due
11/13 3rd draft released (if necessary)
11/27 Comments on 3rd draft due (if necessary)
12/04 Community draft released

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

W3C/IETF XML Signature specification http://www.w3.org/2000/09/xmldsig#

JSR 55 Certification Path

3.2 Explanation of how these items might be used as a starting point for the work.

These documents describe the XML Digital signature standard developed by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF)

2.15 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:

2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

2.19 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.

2.20 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?

2.21 Please provide the location of the publicly accessible document archive you have created for the Expert Group.

2.11 Please describe the anticipated schedule for the development of this specification.

2.1 Please describe the proposed Specification:

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

2.3 What need of the Java community will be addressed by the proposed specification?

2.4 Why isn't this need met by existing specifications?

2.5 Please give a short description of the underlying technology or technologies:

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

2.8 Are there any security issues that cannot be addressed by the current security model?

2.9 Are there any internationalization or localization issues?

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

2.11 Please describe the anticipated schedule for the development of this specification.

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

3.2 Explanation of how these items might be used as a starting point for the work.

2.6 Is there a proposed package name for the API Specification? (i.e., `javapi.something`, `org.something`, etc.)