 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 183: Web Services Message Security APIs
Reason: Web services security (WS-Security) has become the defacto standard to secure web services messages. Lack of a standard in Java to write to these APIs, hasn't caused any interoperability or integration issues across vendor platforms. So, this JSR was withdrawn. JCP version in use: 2.1 Java Specification Participation Agreement version in use: 1.0 Description: This JSR is to define a standard set of APIs for Web services message security. The goal of this JSR is to enable applications to construct secure SOAP message exchanges. Please direct comments on this JSR to the Spec Lead(s) Team
This JSR has been Withdrawn The following information has been updated from the original JSR:
2007.02.22: Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: IBM Name of Contact Person: Anthony Nadalin E-Mail Address: drsecure@us.ibm.com Telephone Number: +1 512 436 9568 Fax Number: +1 512 436 9568 Specification Lead: Nataraj Nagaratnam E-Mail Address: natarajn@us.ibm.com Telephone Number: +1 919 486 1063 Fax Number: +1 919 543 2310 Initial Expert Group Membership:
Supporting this JSR: IBM Section 2: Request
2.1 Please describe the proposed Specification:The goal of this JSR is to enable applications to construct secure SOAP message exchanges. This specification is intended to provide a flexible set of mechanisms that can be used to construct a range of security protocols; in other words this JSR intentionally does not describe explicit fixed security protocols. As with every security protocol, significant efforts must be applied to ensure that security protocols constructed using this JSR are not vulnerable to a wide range of attacks. To summarize, the focus of this JSR is to describe a single-message security language that provides for message security that may assume an established session, security context and/or policy agreement. The requirements to support secure message exchange are listed below. Non-Goals The following topics are outside the scope of this JSR: (1) Establishing a security context or authentication mechanisms that require multiple exchanges. (2)Key exchange and derived keys (3)How trust is established or determined 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 set of APIs for Web services security 2.4 Why isn't this need met by existing specifications?There is no existing specification in JDK 2 SDK for securing Web services messages via a standard set of APIs. 2.5 Please give a short description of the underlying technology or technologies:In this JSR we specify an abstract message security model in terms of security tokens combined with digital signatures as proof of possession of the security token (key). Security tokens assert claims and signatures provide a mechanism for proving the sender's knowledge of the key. As well, the signature can be used to "bind" or "associate" the signature with the claims in the security token (assuming the token is trusted). Note that such a binding is limited to those elements covered by the signature. Furthermore note that this JSR does not specify a particular method for authentication, it simply indicates that security tokens may be bound to messages. A claim can be either endorsed or unendorsed by a trusted authority. A set of endorsed claims is usually represented as a signed security token that is digitally signed or encrypted by the authority. An X.509 certificate, claiming the binding between one's identity and public key, is an example of a signed security token. An endorsed claim can also be represented as a reference to an authority so that the receiver can "pull" the claim from the referenced authority. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)vax.security.ws 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 20-30 week schedule, with 2-3 internal review cycles within that timeframe: Release API docs and preliminary spec. 4 weeks later - Comments on first draft due 6 weeks later - 2nd draft released 4 weeks later - Comments on 2nd draft due 6 weeks later - 3rd draft released (if necessary) 4 weeks later - Comments on 3rd draft due (if necessary) 6 weeks later - Community draft released Note that this information has been updated from the original JSR.
2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.The working model is that the expert group will define the APIs and and provide an RI 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.SOAP] W3C Note, "SOAP: Simple Object Access Protocol 1.1," 08 May 2000. [SOAP-SEC] W3C Note, "SOAP Security Extensions: Digital Signature," 06 February 2001. [XML-C14N] W3C Recommendation, "Canonical XML Version 1.0," 15 March 2001. [XML-Encrypt] W3C Working Draft, "XML Encryption Syntax and Processing," 04 March 2002. [XML-ns] W3C Recommendation, "Namespaces in XML," 14 January 1999. [XML-Schema1] W3C Recommendation, "XML Schema Part 1: Structures,"2 May 2001. [XML-Schema2] W3C Recommendation, "XML Schema Part 2: Datatypes," 2 May 2001. [XML Signature] W3C Proposed Recommendation, "XML Signature Syntax and Processing," 20 August 2001. 3.2 Explanation of how these items might be used as a starting point for the work.These documents describe the XML standards developed by the World Wide Web Consortium (W3C) that will be used in the construction of this JSR Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.None |
|||||||||||||||||||||||||||||||||||||||||||||
