|2.1 Proposed Specification:
|Simple Authentication and Security Layer (SASL)
specifies a challenge-response protocol in which data is exchanged between
the client and the server for the purposes of authentication and (optional)
establishment of a security layer on which to carry on subsequent communications.
It is used with connection-based protocols such as the
Lightweight Directory Access Protocol (LDAP) v3, and Internet
Message Access Protocol (IMAP) v4. SASL is described in
There are various mechanisms defined for
SASL. Each mechanism defines the data that must be exchanged between the
client and server in order for the authentication to succeed. Mechanisms
are registered with IANA.
This proposal is to define a SASL client and server
API in the Java programming language.
|2.2 What is the target Java platform?
|2.3Need of the Java community that this will addressed
- Makes easier the development of libraries written
in the Java programming language for popular protocol standards that use
SASL, such as LDAP v3 and IMAP v4.
- Independence between those building and supplying
SASL mechanisms and those using them.
|2.4 Why isn't this need met by existing specifications?
|There is currently no standard Java API for SASL.
Protocol libraries written in the Java programming language that support
SASL, such as LDAP v3 and IMAP v4, currently support SASL in an adhoc manner.
A mechanism implementation for one protocol cannot easily be used in another
|The proposal defines classes and interfaces for
SASL mechanisms. It also provides a pluggable authentication framework
that allows SASL mechanisms to be added dynamically to the runtime environment.
The API will allow developers to write client and server applications or
protocol libraries that can authenticate using different SASL mechanisms,
and to write mechanism implementations that can be used by such SASL-enabled
|2.6 Proposed package name
Java Authentication and Authorization Service
|2.8 Security issues that cannot be addressed by the current security
|The proposed API can use the current security
|2.9 Internationalization or localization issues
|2.10 Existing specifications that might be rendered obsolete, deprecated,
or in need of revision