Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)
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 Oracle
  Sean Mullan Sun Microsystems, Inc.
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

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?

NO

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

NO

2.9 Are there any internationalization or localization issues?

NO

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

NO

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)