Status: Withdrawn Reason: Withdrawn by the JSR 155 Spec Lead due to changing industry focus and continued JSR inactivity.JCP version in use: 2.1Java Specification Participation Agreement version in use: 1.0

Description:
To provide a set of APIs, exchange patterns & implementation to securely (integrity and confidentiality) exchange assertions between web
services based on OASIS SAML.

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.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
Community Draft : 1/1/02
Public Draft : 2/15/02
Final Release : 3/31/02 (Depends on the release of related JSRs. Need to
coordinate with those JSRs)

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.