Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
|
JSRs: Java Specification Requests
JSR 104: XML Trust Service APIs
This JSR has been Withdrawn The following information has been updated from the original JSR:
2007.02.27: 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
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.
JDK 2 SDK, Standard Edition, V 1.3 and above 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. JDK 2 SDK, Standard Edition does not provide a standard set of APIs for PKI
Trust Services. 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.
javax.security.tas Note that this has been updated from the original request.
NO NO NO NO 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. Note that this section has been updated from the original request.
Section 3: Contributions
W3C/IETF XML Signature specification http://www.w3.org/2000/09/xmldsig# Note that this section has been updated from the original request.
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.
|