Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 177: Security and Trust Services API for J2METM

Stage Access Start Finish
Maintenance Release Download page 20 Aug, 2007  
Maintenance Draft Review Download page 17 Apr, 2007 21 May, 2007
Final Release Download page 03 Sep, 2004  
Final Approval Ballot View results 15 Jun, 2004 28 Jun, 2004
Proposed Final Draft Download page 04 May, 2004  
Public Review Download page 29 Oct, 2003 28 Nov, 2003
Community Draft Reconsideration Ballot View results 17 Jun, 2003 23 Jun, 2003
Community Draft Ballot View results 29 Apr, 2003 05 May, 2003
Community Review Login page 04 Apr, 2003 05 May, 2003
Expert Group Formation   02 Apr, 2002 07 Jun, 2002
JSR Review Ballot View results 19 Mar, 2002 01 Apr, 2002
Status: Maintenance
JCP version in use: 2.6
Java Specification Participation Agreement version in use: 2.0

This specification will provide J2ME applications with APIs for security and trust services through the integration of a Security Element.

Please direct comments on this JSR to the Spec Lead(s)

Specification Leads
  Saqib Ahmad Oracle
  Roman Zelov Sun Microsystems, Inc.
Expert Group
  Betrusted Inc. Gemalto Motorola
  Nokia Corporation NTT DoCoMo, Inc. Oberthur Card Systems
  Oracle Research In Motion, LTD (RIM) Softbank Mobile Corporation
  Sony Ericsson Mobile Communications AB Sun Microsystems, Inc. Telefonica Moviles Espana
  Vodafone Group PLC Vodafone Group Services Ltd

NOTICE: Please be aware the CDC 1.0 specification initially related to this JSR has been replace (superseded) with the newer CDC 1.1 specification. CDC 1.0 will no longer be supported after 18-Aug-2009. This JSR and other optional technologies based on the CDC 1.0 standards are fully compatible with the CDC 1.1 standards. All development and certification efforts should be updated to use the current, supported technology.

Note that this JSR was completed under JCP 2.1.

Updates to the Original JSR

The following information was updated from the original proposal.

2007.08.20: Roman Zelov was added as a Maintenance Lead.

Name of Maintenance Lead: Roman Zelov

E-Mail Address:

Telephone Number: +8 812 334 61 46

Fax Number: +8 812 334 30 38

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Sun Microsystems, Inc.

Name of Contact Person: Zhiqun Chen

E-Mail Address:

Telephone Number: +1 408 276 7389

Fax Number: +1 408 276 7608

Specification Lead: Zhiqun Chen

E-Mail Address:

Telephone Number: +1 408 276 7389

Fax Number: +1 408 276 7608

Initial Expert Group Membership:

France Telecom
Hutchison 3G
Telef?nica M?viles Espa?a
Sun Microsystems Inc.

Supporting this JSR:

Section 2: Request

2.1 Please describe the proposed Specification:

The purpose of this JSR is to define a collection of APIs that provide security services to J2ME enabled devices. These APIs are a necessary step for a device to become trusted, in other words provide security mechanisms to support a wide variety of application based services, such as access to corporate network, mobile commerce, and digital rights management.

Many of these services rely on the interaction with a Security Element in the device for secure storage and execution as described below:

  • Secure storage to protect sensitive data, such as the user?s private keys, public key (root) certificates, service credentials, personal information, etc.
  • Secure execution, such as cryptographic operations to support payment protocols, data integrity, and data confidentiality.
  • Custom and enabling security features that J2ME applications can rely on to handle many valued-added services, such as user identification and authentication, banking, payment, ticketing, loyalty applications, digital media play, etc.
A Security Element can be implemented in a variety of ways. Smart cards are most commonly used to implement a security element. They are widely deployed in wireless phones, such as SIM cards in GSM phones, UICC cards in 3G phones, and WIM applications in a SIM or UICC card in WAP-enabled phones. For instance in GSM networks, the network operator puts the network authentication data on a smart card, as well the subscriber's personal information such as the address book. This card, when inserted into a mobile handset, enables the handset to operate on the operators network for the benefits of the subscriber.

As the primary use for cards in these devices is to provide security (storage and processing) and other custom services, this specification provides an access model that enables applications running on J2ME enabled devices to communicate with a smart card inserted in the device. This access model intends to provide a flexible mechanism to allow service and equipment providers to define secure operations.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

This API will focus on supporting consumer devices (CLDC [Connected Limited Device Configuration] and CDC [Connected Device Configuration]) but should not be designed in such a way as to preclude its implementation on larger platforms such as J2SE.

The security and trust services API is proposed to be an optional package to be used together with several J2ME profiles.

2.3 What need of the Java community will be addressed by the proposed specification?

This API provides security services to Java applications running on J2ME enabled devices and to enable new value-added functions to be deployed on these devices.

Also see 2.1.

2.4 Why isn't this need met by existing specifications?

The current J2ME platform does not have APIs that provide security services to applications and does not include any way to access security elements from the underlying platform.

2.5 Please give a short description of the underlying technology or technologies:

In order to perform trusted operations, J2ME applications need to rely on the security services provided in a Security Element to ensure that, for example, the cryptographic keys are stored securely and that the cryptographic computations are performed securely. The proposed API establishes a Java programming model for accessing the features of a Security Element.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)*

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No. It depends largely on other standards and on their implementation on the various devices.

2.8 Are there any security issues that cannot be addressed by the current security model?

This JSR aims at extending the current security model to support client side, custom security solutions through the integration of a security element.

2.9 Are there any internationalization or localization issues?


2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?


2.11 Please describe the anticipated schedule for the development of this specification.

Q1 - Q2, 2003

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

The expert group will follow the model of the JSR118 expert group and others, using in the main email communications with occasional telephone and face to face meetings.

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.

General contributions:

3.2 Explanation of how these items might be used as a starting point for the work.

The APIs to be defined in the specification are intended to work with CLDC- and CDC-based profiles, in particular MIDP, and will be defined to take into consideration industry standards of related technologies.