 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 105: XML Digital Signature APIs
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
Updates to the Original Java Specification Request (JSR) The following information has been updated from the original JSR.
2014.01.14: 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:
2.15 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:
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.
There is no wiki currently available, but if necessary, one would likely be created at https://wiki.openjdk.java.net.
https://bugs.openjdk.java.net/issues/
Yes: @seanjmullan
No, not recently.
Yes for the RI.
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.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)
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: 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. 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) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
