 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 155: Web Services Security Assertions
This JSR has been Withdrawn
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: Cisco Systems Name of Contact Person: Krishna Sankar E-Mail Address: ksankar@cisco.com Telephone Number: +1 408 853 8475 Fax Number: Specification Lead: Krishna Sankar E-Mail Address: ksankar@cisco.com Telephone Number: +1 408 853 8475 Fax Number: Initial Expert Group Membership:
Supporting this JSR: Cisco Systems Section 2: Request
2.1 Please describe the proposed Specification:One of the important pieces in the web services space is the exchange of assertions securely between web services. The OASIS SAML is defining the assertions and this JSR adds the assertions capabilities to Java. The assertions would include credential assertions, authentication assertions, authorization assertions, session assertions, attribute assertions et al as defined by SAML. This JSR would leverage the other JSRs on messaging, SOAP & security. It is the plan of this JSR not only to provide the Java Apis for assertions but also to provide the system patterns to achieve the exchange of assertions between web services. The patterns would include req/response, sync/async patterns, firenforget et al. These patterns would be based on the JAXM and Java-RPC JSRs. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)J2EE, J2SE 2.3 What need of the Java community will be addressed by the proposed specification?Exchanging assertions in the web services space. 2.4 Why isn't this need met by existing specifications?None of them address the assertions and patterns. 2.5 Please give a short description of the underlying technology or technologies:XML, XML Signature, XML ENcryption, SOAP, messaging. The assertions of course is based on XML and XML Schema. The SAML TC is also defining how assertions would be signed using XML Signature. For this JSR, the primary binding of the assertions would be SOAP, again as defined in the SAML specification. The messaging would be used to develop the assertion exchange patterns. The good thing is that there are already XML Signature, XML Encryption, SOAP-RPC and JAXM APIs being developed. This JSR would use those APIs as the technology substrate. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.security.assertions.* 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.Preliminary Draft :12/1/01 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.Normal expert group. 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.OASIS SAML specifications, SOAP specification, W3C XML Signature and XML Encryption
OASIS SAML Web Site : http://www.oasis-open.org/committees/security/ 3.2 Explanation of how these items might be used as a starting point for the work.The SAML specifications define the assertions. The security (signature and encryption come from the W3C specifications) Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.This JSR would leverage on the JAXM,JAX-RPC and the three Java security JSRs. |
