JSRs: Java Specification Requests
JSR 300: DRM API for JavaTM ME
JCP version in use: 2.7
Java Specification Participation Agreement version in use: 2.0
This specification will define an optional package for developing JavaTM ME applications which utilize or interoperate with DRM agents that separately exist in devices.
Please direct comments on this JSR to the Spec Lead(s)
Updates to the Java Specification Request (JSR)
The following information has been updated from the original JSR:
2008.06.19: Spec Lead: Dnyanesh R Pathak
email id: dnyanesh
Telephone Number: +91 80 6615 5000
Fax Number: +91 80 6615 5100
Public Review: June 2008
If you would like to be added to the observer alias for this JSR and receive e-mail updates on the progress of the JSR, please send e-mail to the Spec Lead with "Add to observer alias" in the subject line.
Original Java Specification Request (JSR)
Section 1. Identification
Submitting Member: LG Electronics Inc.
Name of Contact Person: Yong Moo Kim
E-Mail Address: clew
Telephone Number: +82 31 450 1915
Fax Number: +82 31 450 4049
Specification Lead: Dnyanesh Pathak
E-Mail Address: Dnyanesh.pathak
Telephone Number: +91 80 5515 5000
Fax Number: +91 80 5515 5100Note that this information has been updated from the original JSR.
Initial Expert Group Membership:
Sun Microsystems Inc.
Supporting this JSR:
Sun Microsystems Inc.
Section 2: Request
2.1 Please describe the proposed Specification:
JavaTM ME platform enables users to download and use the digital content on the mobile handsets.
(2) Getting the information on the rights associated with content ? for enabling user to make decision on rights download
(3) Getting the DRM protected content in secure manner for rendering
The proposed JSR will bring out generic APIs for enabling the Java ME applications to access the DRM Content, abstracting out how the DRM content is handled internally by the underlying DRM Agent(s)
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)
The target is JavaTM platform for embedded devices (JavaTM ME).
2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.
The minimum configuration is the J2ME Connected, Limited Device Configuration v1.1. This Optional Package should be usable with any J2ME Profile based on that Configuration as well as Profiles based on the Connected Device Configuration
2.4 Should this JSR be voted on by both Executive Committees?
2.5 What need of the Java community will be addressed by the proposed specification?
Strength of JavaTM platform is mainly to support application portability and thus OTA download ability of JavaTM applications and digital content. The content being downloaded/ accessed needs to be protected against piracy and for revenue generation based on its usage by the end user. The proposed JSR will provide a standardized support for digital content protection and management of the rights by providing APIs to interact with the underlying DRM agent(s). The developers can use this JSR for interacting with the DRM agents for developing applications that handle the DRM protected content.
2.6 Why isn't this need met by existing specifications?
The existing J2ME specifications do not provide specific support for OMA DRM or other DRM specifications.
2.7 Please give a short description of the underlying technology or technologies:
DRM Description: The "Digital Rights Management" (DRM) enables the distribution and consumption of digital content in a controlled manner. The content is distributed and consumed on authenticated Devices per the usage rights expressed by the content owners. One of such prominent DRM specifications is OMA DRM2.0. OMA DRM addresses various technical aspects of this system by providing appropriate specifications for content formats, protocols, and a rights expression language.
2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)
2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?
2.10 Are there any security issues that cannot be addressed by the current security model?
2.11 Are there any internationalization or localization issues?
2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?
2.13 Please describe the anticipated schedule for the development of this specification.
The anticipated schedule for the JSR is as follows:
2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.
The Expert Group communication will be mainly via emails and teleconferences. The face-to-face meetings will be organized at regular intervals as required and for the major milestones for critical decisions.
2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.
The details of the progress of the JSR will be informed to the community and the public by
updating the JSR Community page regularly as the JSR progresses. The latest drafts will be
published for community and public review using the JSR Community page.
2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.
Standalone RI and TCK will be produced as a part of this JSR.
2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).
2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.
These terms only represent the initial commercial terms planned to be used at this time and
remain subject to the execution of final legal agreements covering the subject matter hereof to be
determined by LG Electronics at its sole discretion. Independent implementations will be allowed.
RI and TCK will be licensed separately to all interested parties.
For the RI we will charge a one-time access fee, and an annual maintenance fee.
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.
The OMA DRM2.0 standards are referred to, to bring up the basic idea for this JSR. DRM Sub-Working Group in Open Mobile Alliance (OMA) Browser and Content Working Group (BAC) ( http://www.openmobilealliance.org/tech/wg_committees/bac.html)
3.2 Explanation of how these items might be used as a starting point for the work.
As mentioned above, the OMA Standards for DRM are used to bring up the concept of this JSR. This standard will be referred to for designing this JSR.
Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.