Find JSRs
Submit this Search


Ad Banner
 
 
 
 

JSRs: Java Specification Requests
JSR 104: XML Trust Service APIs

This JSR has been Withdrawn
Reason: The Java world has moved on since 2001 and the need for this JSR has declined.

Updates to the Java Specification Request (JSR)

The following information has been updated from the original JSR:

2007.02.27:
05/2007 Release API docs and preliminary spec.
10/2007 Comments on first draft due
11/2007 2nd draft released
12/2007 Comments on 2nd draft due
03/2008 3rd draft released (if necessary)
04/2008 Comments on 3rd draft due (if necessary)
06/2008 Community draft released

Original Java Specification Request (JSR)

Identification | Request | Contributions

Original Summary: This JSR is to define a standard set of APIs and a protocol for a "Trust Service" A key objective of the protocol design is to minimize the complexity of applications using XML Signature. By becoming a client of the trust service, the application is relieved of the complexity and syntax of the underlying PKI used to establish trust relationships, which may be based upon a different specification such as X.509/PKIX, SPKI or PGP.

Section 1. Identification

Submitting Member: IBM

Name of Contact Person: Anthony Nadalin or Maryann Hondo

E-Mail Address: Anthony Nadalin - drsecure@us.ibm.com, Maryann Hondo - mhondo@us.ibm.com

Telephone Number: Anthony Nadalin - +1 512 436 9568, Maryann Hondo - +1 617 693 4299

Fax Number: Anthony Nadalin - +1 512 838 3823, Maryann Hondo - +1 617 693 5531


Specification Lead: Anthony Nadalin and Maryann Hondo

E-Mail Address: Anthony Nadalin - drsecure@us.ibm.com, Maryann Hondo - mhondo@us.ibm.com

Telephone Number: Anthony Nadalin - +1 512 436 9568, Maryann Hondo - +1 617 693 4299

Fax Number: Anthony Nadalin - +1 512 838 3823, Maryann Hondo - +1 617 693 5531


Initial Expert Group Membership:

IBM - Anthony Nadalin/Maryann Hondo



Section 2: Request

2.1 Please describe the proposed Specification:

This JSR is to define a standard set of APIs and a protocol for a "Trust Service" to support the delegation by an application to a service of the processing of XML Signature Key Information associated with an XML signature, XML encryption, or other public key. Its functions include the location of required public keys and the binding of such keys to identification information.

Note that this has been updated from the original request.

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?

A key objective of the protocol design is to minimize the complexity of application implementations by allowing them to become clients and thereby shielded from the complexity and syntax of the underlying PKI used to establish trust relationships. By becoming a client of the trust service, the application is relieved of the complexity and syntax of the underlying PKI used to establish trust relationships, which may be based upon a different specific. These may be based upon a different specification such as X.509/PKIX, SPKI or PGP.

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

JDK 2 SDK, Standard Edition does not provide a standard set of APIs for PKI Trust Services.

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

This allows a client to delegate part or all of the tasks required to process XML Signature Key Information to a "Trust Service". A key objective of the design is to minimize the complexity of applications using XML Signature. By becoming a client of the trust service, the application is relieved of the complexity and syntax of the underlying PKI used to establish trust relationships, which may be based upon a different specification such as X.509/PKIX, SPKI or PGP.

By design, the XML Signature Specification does not mandate use of a particular trust policy. The signer of a document is not required to include any key information, a key name, X.509 certificate, a PGP Key Identifier etc. Alternatively, a link may be provided to a location where the full Key Information may be found.

Note that this section has been updated from the original request.

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

javax.security.tas

Note that this has been updated from the original request.

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.

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
Note that this information has been updated from the original JSR.

Note that this section has been updated from the original request.





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

Note that this section has been updated from the original request.

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)

Note that this section has been updated from the original request.