Content for TS 23.057 Word version: 18.0.0

3.1 Definitions 3.2 Abbreviations 4.1 Generic MExE aspects 4.2 High level architecture 4.3 Multiple classmark support
...

1 Scope p. 8

The present document defines the stage 2 and stage 3 description of the Mobile Execution Environment (MExE). Stage 2 identifies the functional capabilities and information flows needed to support the service described in stage 1.

The present document includes information applicable to network operators, service providers and terminal, switch and database manufacturers.

The present document contains the core functions for a Mobile Execution Environment (MExE) which are sufficient to provide a complete service.

MExE uses a number of technologies to realise the requirements of the stage 1 description (TS 22.057). The present document describes how the service requirements are realised with the selected technologies. The TS is devised into clauses each covering the aspects relating to particular MExE technologies, it is intended that this specification will evolve along with the MExE technologies. A generic clause of the specification covers areas of MExE common to all technologies.

Implementation of this specification outside the UE (User Equipment) is outside the scope of this specification.

2 References p. 8

References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1] Void.

[2]

TS 22.057: "Mobile Execution Environment (MExE); Stage 1".

[3]

Personal Java 1.1.1 or higher: Sun Microsystems http://www.javasoft.com/products/personaljava/.

[4]

JavaPhone API version 1.0: http://java.sun.com/products/javaphone/.

[5] Void.

[6]

Wireless Application Protocol (WAP) June 2000 Conformance Release: http://www.wapforum.org.

[7] Void.

[8] Void.

[9]

RFC 2616: Hypertext Transfer Protocol - HTTP/1.1: http://www.w3.org/Protocols/rfc2616/rfc2616.

[10] Void.

[11]

TR 22.170: "Universal Mobile Telecommunications System (UMTS); Service aspects; Provision of Services in UMTS - The Virtual Home Environment".
→ to date, withdrawn by 3GPP

[12]

TS 22.121: "The Virtual Home Environment; Stage 1".

[13] Void.

[14]

TS 22.101: "Service Aspects; Service Principles".

[15]

CC/PP Exchange Protocol based on HTTP Extension Framework; W3C http://www.w3.org/Mobile/CCPP.

[16]

Composite Capability/Preference Profiles (CC/PP): A user side framework for content negotiation: http://www.w3.org/Mobile/CCPP.

[17]

UAProf Specification: http://www.wapforum.org/what/technical.htm.

[18]

JDK 1.1 security: http://www.javasoft.com/products/jdk/1.1/docs/guide/security/index.html.

[19]

Java 2 security: http://www.javasoft.com/products/jdk/1.2/docs/guide/security/index.html.

[20]

Java security tutorial: http://java.sun.com/docs/books/tutorial/security1.2/overview/index.html.

[21]

OCF 1.1: "Smartcard API specified by OpenCard Consortium http://www.opencard.org.

[22]

RFC 1738: "Uniform Resource Locators (URL)" http://www.w3.org/pub/WWW/Addressing/rfc1738.txt.

[23]

The MD5 Message Digest Algorithm", Rivest, R., RFC 1321, April 1992. URL: ftp://ftp.isi.edu/in-notes/rfc1321.txt.

[24]

ISO/IEC 10118-3 (1996): "Information technology - Security techniques - Hash-functions - Part 3: Dedicated hash-functions".

[25]

RFC 2368: "The mailto URL scheme".

[26]

ITU-T Recommendation X.509: "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks".

[27]

TS 51.011: "Specification of the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface".

[28]

TS 23.107: "QoS Concept and Architecture".

[29]

TS 24.007: "Mobile radio interface signalling layer 3; General Aspects".

[30]

TS 24.008: "Mobile radio interface layer 3 specification, Core Network Protocols; Stage 3".

[31]

TS 23.060: "General Packet Radio Service (GPRS); Service Description; Stage 2".

[32]

PKCS #15: "Cryptographic Token Information Syntax Standard" version 1.1, RSA Laboratories, June 2000

URL: ftp://ftp.rsa.com/pub/pkcs/pkcs-15/pkcs-15v1_1.doc.

[33]

RFC 2510 (1999): "Internet X.509 Public Key Infrastructure Certificate Management Protocols".

[34]

Connected Limited Device configuration, J2ME version 1.0: http://java.sun.com/j2me/docs/.

[35]

Mobile Information Device Profile, J2ME version 1.0: http://java.sun.com/j2me/docs/.

[36]

eXtensible Markup Language (XML) 1.0: W3C Recommendation. http://www.w3.org/XML.

[37]

Resource Definition Framework (RDF) Model and Syntax:W3C Recommendation. http://www.w3.org/RDF.

[38]

UML Partners: Unified Modelling Language: http://www.omg.org.

[39]

TS 31.102: "Characteristics of the USIM applications".

[40]

RFC 2396 (1998): "Uniform Resource Identifiers (URI): Generic Syntax". T. Berners-Lee, R. Fielding, L. Masinter.

[41]

RFC 2616 (1999): "Hypertext Transfer Protocol -- HTTP/1.1". R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee.

[42]

Description of the "JAR Manifest" file encoding, Sun Microsystems. URL: http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html.

[43]

RFC 2459 (1999): "Internet X.509 Public Key Infrastructure Certificate and CRL Profile". R. Housley, W. Ford, W. Polk, D. Solo.

[44]

TR 21.905: Vocabulary for 3GPP Specifications.

[45]

WAP Binary XML Content Format Specification (WBXML): http://www.wapforum.org/what/technical.htm.

[46]

RFC 1766: "Tags for the Identification of Languages".

[47]

WAP Certificate and CRL Profiles: WAP-211-WAPCert http://www.wapforum.org/what/technical.htm.

[48]

TS 23.227: "Applications and User interaction in the UE-Principles and specific requirements".

[49]

PKCS#1 "RSA Cryptographic Standard" version 2.0: RSA Laboratories, October 1998 http://www.rsasecurity.com/rsalabs/pkcs/pkcs-1/index.html.

[50]

Common Language Infrastructure: ECMA specification ECMA-335, http://www.ecma.ch/ecma1/STAND/ecma-335.htm.

[51]

Simple Object Access Protocol version 1.1, (SOAP): http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.

[52]

PKCS#7 "Cryptographic Message Syntax Standard" version 1.5: RSA Laboratories, November 1993 http://www.rsasecurity.com/rsalabs/pkcs/pkcs-7/index.html.

[53]

TS 23.040: "Technical realization of the Short Message Service (SMS)".

3 Definitions and abbreviations p. 10

3.1 Definitions p. 10

For the purposes of the present document, the following terms and definitions apply:

administrator:

administrator of the MExE device is the entity that has the control of the third party trusted domain, and all resources associated with the domain

best effort QoS (Quality of Service):

best effort QoS refers to the lowest of all QoS traffic classes

certificate:

entity that contains the issuer's public key, identification of the issuer, identification of the signer, and possibly other relevant information

delivered QoS:

actual QoS parameter values with which the content was delivered over the lifetime of a QoS session, TS 23.107.

End Entity:

user of PKI certificates and/or end user system that is the subject of a certificate.

fine grain:

refers to the capabilities of the Java security system to allow applications, sections of code or Java classes to be assigned permissions to perform a specific set of privileged operations

key pair:

key pairs are matching private and public keys

Operator:

term operator as used in this specification refers to the term Home Environment, defined as "Home Environment: The home environment is responsible for enabling a user to obtain UMTS services in a consistent manner regardless of the user's location or terminal used (within the limitations of the serving network and current terminal)" in TR 21.905.

negotiated QoS:

response to a QoS request, the network shall negotiate each QoS attribute to a level that is in accordance with the available network resources

personal certificate:

certificate loaded by the user or a user application which is limited to the application that it is intended for, and is not a MExE Certificate

phonebook:

dataset of personal or entity attributes

Mobile Execution Environment (MExE):

is defined in detail in the present document, but the scope of MExE does not include the operating system, or the manufacturer's execution environment

MExE API:

consists of interfaces present in the MExE device and exposed to MExE executables

MExE certificate:

used in the realisation of MExE security domains

MExE device:

UE (User Equipment) that supports MExE functionality in the ME (Mobile Equipment)

MExE executable:

is one or more applet, application, or content, which conforms to the MExE specification and may execute on any MExE device, conforming to the appropriate classmark

MExE Java VM:

this is a standard Java virtual machine used to execute MExE Java applets and applications

MExE native library:

this is a downloaded native library that can be accessed by MExE executables

MExE Server:

node supporting MExE services in the MExE service environment

MExE-(U)SIM:

(U)SIM that is capable of storing a security certificate that is accessible using standard mechanisms

MIDP application:

MIDP application, or "MIDlet", is one that uses only the APIs defined by the MIDP and CLDC specifications.

MIDlet suite:

collection of MIDP Applications, or MIDlets packaged together and share resources within the context of a single Java Virtual Machine

owner:

owner of the MExE device

power up event:

abstract event that occurs when the MExE device is cold started (i.e. switched on)

QoS session:

Lifetime of PDP context, the period between the opening and closing of a network connection whose characteristics are defined by a QoS profile

QoS profile:

comprises of a number of QoS parameters

requested QoS:

QoS profile is requested at the beginning of a QoS session

sandbox:

sandbox is a safe area to run Java code. Untrusted Java code executing in a sandbox has access to only certain resources, JDK 1.1 security [18].

service:

service (which may consist of an application or applet, and its related content) is a set of functions offered to a user by an organisation, and may be performed on the MExE device and/or remotely

service name:

identifier associated with a service, which could be a string, a fully qualified Java class name, a unique URI or other identifier

session:

period between the launching of a MExE executable and its execution termination

signature:

"Signing" is the process of encrypting a hash of the data using a private key

signed JAR file:

archives of Java classes or data that contain signatures that also include a way to identify the signer in the manifest [42] (the Manifest contains a file which has attributes defined in it)

subscribed QoS:

network will not grant a QoS greater than that subscribed

user:

user of the MExE device

valid (U)SIM application:

identification by the MExE ME that a valid SIM card, or USIM application on the UICC, has been detected (e.g. through insertion of (U)SIM card, power up of MExE device etc.)

Further definitions specific to MExE are given in TS 22.057.

3.2 Abbreviations p. 12

For the purposes of the present document the following abbreviations apply:

Attribute Authority

API

Application Programming Interface

APDU

Application protocol data unit

ARPK

Administrator Root Public Key

Certification Authority

CC/PP

Composite Capability/Preference Profiles

CGI

Common Gateway Interface

CCM

Certificate Configuration Message

CLDC

Connected Limited Device Configuration

CLI

Common Language Infrastructure

CP-Admin

Certificate Present (in the MExE (U)SIM) - Administrator

CP-TP

Certificate Present (in the MExE (U)SIM) - Third Party

CRL

Certificate Revocation List

Diff-serv

Differentiated Services

DTMF

Dual Tone Multiple Frequency

GSM

Global System for Mobile Communication

GPRS

General Packet Radio Service

HTTP

HyperText Transfer Protocol

HTTPS

HyperText Transport Protocol Secure (https is http/1.1 over SSL, i.e. port 443)

IETF

Internet Engineering Task Force

Internet Protocol

ISDN

Integrated Services Digital Network

JAD

Java Application Descriptor

J2ME

Java 2 Micro Edition

J2SE

Java 2 Standard Edition

JTAPI

Java Telephony Application Programming Interface

JAR file

Java Archive File

Mobile Equipment

MIDP

Mobile Information Device Profile

MIDlet

MIDP Application

MMI

Man-Machine Interface

MRPK

Manufacturer Root Public Key

MSE

MExE Service Environment

MSISDN

Mobile Subscriber ISDN Number

Mobile Termination

OCF

OpenCard Framework

OEM

Original Equipment Manufacturer

OCSP

Online Certificate Status Protocol

ORPK

Operator Root Public Key

QoS

Quality of Service

PDP

Packet Data Protocol

PKI

Public Key Infrastructure

RDF

Resource Description Format

RFC

Request For Comments

RPK

Root Public Key

SCVP

Simple Certificate Verification Protocol

SIM

Subscriber Identity Module

SMS

Short Message Service

SOAP

Simple Object Access Protocol

SSL

Secure Socket Layer

Terminal Equipment

TLS

Transport Layer Security

Third Party

UDP

User Datagram Protocol

User Equipment

User Interface

UMTS

Universal Mobile Telecommunications System

URL

Uniform Resource Locator

URI

Uniform Resource Identifier

USIM

Universal Subscriber Identity Module

USSD

Unstructured Supplementary Service Data

Virtual Machine

WAE

Wireless Application Environment

WAP

Wireless Application Protocol

WBXML

WAP Binary XML

WDP

Wireless Datagram Protocol

WMLS

Wireless Markup Language Script

WSP

Wireless Session Protocol

WTA

Wireless Telephony Applications

WTAI

Wireless Telephony Applications Interface

WTLS

Wireless Transport Layer Security

WTP

Wireless Transaction Protocol

WWW

World Wide Web

XML

Extensible Markup Language

Further abbreviations are given in TS 22.057 and TR 21.905.

4 MExE basic principles p. 14

4.1 Generic MExE aspects p. 14

Support of at least one MExE classmark is mandatory. A MExE device may also include optional support for applications from any other MExE classmark (refer to clause 4.3 "Multiple Classmark support").

This clause defines the common aspects of all MExE compliant devices, independent of MExE technology.

Considering the wide and diverse range of current and future technology and devices that (will) use wireless communication and provide services based thereon a one-size-fits-all approach is unrealistic. Instead the present document categorises devices by giving them different MExE classmarks. In this specification the following MExE classmarks are defined:

MExE classmark 1 - based on WAP (Wireless Application Protocol) [6] - requires limited input and output facilities (e.g. as simple as a 3 lines by 15 characters display and a numeric keypad) on the client side, and is designed to provide quick and cheap information access even over narrow and slow data connections.
MExE classmark 2 - based on PersonalJava [3] - provides and utilises a run-time system requiring more processing, storage, display and network resources, but supports more powerful applications and more flexible MMIs.
MExE classmark 3 - based on J2ME CLDC and MIDP environment [34] and [35] - supports Java applications running on resource-constrained devices.
MExE classmark 4 - based on Common Language Infrastructure [50] Compact Profile - supports CLI based applications running on a broad range of connected devices.

Content negotiation allows for flexible choice of formats available from a server or adaptation of a service to the actual classmark of a specific client device.

Bi-directional capability negotiation between the MExE Service Environment and MExE device (including MExE classmark), supports the transfer of capabilities between the client and the server.

4.2 High level architecture p. 14

The following architectural model shows an example of how standardised transport mechanisms are used to transfer MExE services between the MExE device and the MExE service environment, or to support the interaction between two MExE devices executing a MExE service.

The MExE service environment could, as shown in Figure 1 "Generic MExE architecture", consist of several service nodes each providing MExE services that can be transferred to the MExE device using mechanisms such as (but not limited to) fixed/mobile/cordless network protocols, Bluetooth, infrared, serial links, wireless optimised protocols, standard Internet protocols. These service nodes may exist in the circuit switched domain, packet switched domain, IP multimedia core network subsystem or in the internet space (e.g. SMS service centres, multimedia messaging servers, internet servers etc.). The MExE service environment may also include a proxy server to translate content defined in standard Internet protocols into their wireless optimised derivatives.

For the versatile support of MExE services, the wireless network shall provide the MExE device with access to a range of bearer services on the radio interface to support application control and transfer from the MExE service environment. As MExE also applies to fixed and cordless environments, MExE device may also access MExE services via non wireless access mechanisms.

Copy of original 3GPP image for 3GPP TS 23.057, Fig. 1: Generic MExE architecture

Figure 1: Generic MExE architecture
(⇒ copy of original 3GPP image)

4.3 Multiple classmark support p. 15

Support of multiple MExE classmarks on a MExE device is optional.

A given MExE Classmark identifies support by a MExE device for a defined level of MExE functionality as defined by that classmark. Support of MExE classmarks by a MExE device shall enable flexible support of MExE functionality. A MExE device may support any multiple combinations of MExE classmarks.

The support of any other functionality by a MExE device is also possible, and is out of scope of this specification.

4.3.1 Classmark 1 service support in non-Classmark 1 MExE devices p. 16

Support of Classmark 1 executables in non-classmark 1 MExE devices is optional.

To allow access to services designed for MExE Classmark 1 devices, MExE devices other than Classmark 1 will need to support full or a subset of WAP protocol as identified below. Due to the fast evolution of new technologies, support of WAP in Classmarks other than Classmark 1 is not mandated by MExE specification. However WAP is a possibility for the integrity of service provisioning as well as quick access to information by feature rich devices (e.g. Java devices).

If Classmark 1 services are supported by non-Classmark 1 devices, Classmark 1 services shall execute in the same manner as they execute in a MExE Classmark 1 device. For that purpose, a MExE non-Classmark 1 device shall comply with data profile class (Class C) of WAP Class Conformance Requirement Specification [6].