![](https://csdnimg.cn/release/download_crawler_static/10624214/bgb.jpg)
11/58 TEE Client API Specification
Copyright 2010 GlobalPlatform Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this
information is governed by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly
prohibited.
Specify only communication mechanisms:
o This API focuses on defining the underlying communications channel. It does not define
the format of the messages which pass over the channel, or the protocols used by specific
Trusted Applications. These must be defined in other specifications.
3.2. Fundamental Concepts
This section outlines the behavior of the TEE Client API, and introduces key concepts and terminology.
3.2.1. TEE Contexts
A TEE Context is an abstraction of the logical connection which exists between a Client Application and a
TEE. A TEE Context must be initialized before a Session can be created between the Client Application
and a Trusted Application running within the TEE which that TEE Context represents. The TEE Context
should be finalized when the connection with the TEE is no longer required, allowing resources to be
released.
It is possible for a Client Application to initialize multiple TEE Contexts concurrently, either with the same
underlying TEE, or with multiple TEEs if they are available. The number of concurrent contexts which may
exist is implementation-defined, and may additionally depend on run-time resource constraints.
3.2.2. Sessions
A Session is an abstraction of the logical connection which exists between a Client Application and a
specific Trusted Application. A Session is opened by the Client Application within the scope of a particular
TEE Context. The number of concurrent Sessions which may exist is implementation-defined, depending
on the design of the TEE and the Trusted Applications in use, and may additionally depend on run-time
resource constraints.
When creating a new Session the Client Application must identify the Trusted Applications which it wishes
to connect to using the Universally Unique IDentifier (UUID) of the Trusted Application. The open session
operation allows an initial data exchange to be made with the Trusted Application, if this is required in the
protocol between the Client Application and the Trusted Application.
Connection Methods: Login
Some Trusted Applications may require the Implementation to identify or authenticate the Client
Application or the user executing it. For example, a Trusted Application may restrict access to the data or
functionality it provides based on the identity of the user running the Client Application in the rich operating
environment. When opening a Session the Client Application can nominate which connection method it
wants to use and hence which login credentials are presented to the TEE or Trusted Application. It is likely
that the connection method will form part of the protocol exposed by the Trusted Application in use;
attempting to open a Session with an incorrect connection method may result in a failed attempt.
3.2.3. Commands
A Command is the unit of communication between a Client Application and a Trusted Application within a
Session. When starting a new Command the Client Application identifies the function in the Trusted
Application which it wishes to execute by passing a numeric identifier, and may also provide an operation
payload in accordance with the protocol the Trusted Application exposes for that function. The Command
invocation blocks the Client Application thread, waiting for an answer from the Trusted Application. A
Client Application may use multiple threads to have multiple Commands which are outstanding
concurrently. The number of concurrent Commands which may exist is implementation-defined,
depending on the design of the TEE and the Trusted Applications in use, and may additionally depend on
run-time resource constraints.