 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 177: Security and Trust Services API for J2METM
JCP version in use: 2.6 Java Specification Participation Agreement version in use: 2.0 Description: 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) Team
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. 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: roman.zelov 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: zhiqun.chen@sun.com Telephone Number: +1 408 276 7389 Fax Number: +1 408 276 7608 Specification Lead: Zhiqun Chen E-Mail Address: zhiqun.chen@sun.com Telephone Number: +1 408 276 7389 Fax Number: +1 408 276 7608 Initial Expert Group Membership: Cingular 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:
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.)javax.microedition.se.* 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?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.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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
