defined by ISO 7816, a string used to uniquely identify card applet applications and certain types of files in card file systems. An AID consists of two distinct pieces: a 5-byte RID (resource identifier) and a 0 to 11-byte PIX (proprietary identifier extension). The RID is a resource identifier assigned to companies by ISO. The PIX identifiers are assigned by companies.
A unique AID is associated with each applet class in an applet application module. In addition, a unique AID is assigned to each applet instance during installation. This applet instance AID is used by an off-card client to select the applet instance for APDU communication sessions.
Applet instance URIs are constructed from their applet instance AID using the "aid" registry-based namespace authority as follows:
//aid/<RID>/<PIX>
where <RID> (resource identifier) and <PIX> (proprietary identifier extension) are components of the AID.
APDU-based application environment
consists of all the functionalities and system services available to applet applications, such as the services provided by the applet container.
within the context of this document, a Java Card applet, which is the basic component of applet-based applications and which runs in the APDU application environment.
contains applet-based applications and manages their lifecycles through the applet framework API. Also provides the communication services over which APDU commands and responses are sent.
applicable security requirements
the security requirements instance, application-assigned or card manager-assigned, that applies for a particular mode of communication. See security requirements.
takes the output of the application developer and ensures that it is a deployable unit. Thus, the input of the application assembler is the application classes and resources, and other supporting libraries and files for the application. The output of the application assembler is an application archive.
an event that an application may define in its own namespace and may be the only one allowed to fire.
a service that an application may define in its own namespace and may be the only one allowed to register.
see descriptor.
application framework class loader
a direct child of the extension library class loader, in charge of loading application framework libraries shared among a restricted set of application groups.
application-managed authentication
authentication that is programmatically triggered by an application's code based on some business logic.
application module class loader
a direct child in the class loader delegation hierarchy of either a group library class loader or of the classic library class loader, depending on the type of application model, in charge of loading the application module classes.
the set of permissions effectively granted to an application, that results from the combination of permissions granted by the platform security policy and the permissions granted by the card management security policy.
a role-based security policy defined for a specific application and for which all the logical user and client security roles have been mapped to actual user identities and client application identities or characteristics on the platform to which the application is deployed.
an operation that either completes in its entirety or no part of the operation completes at all.
state in which a particular operation is atomic. Atomicity of data updates guarantee that data are not corrupted in case of power loss or card removal.
the process of establishing or confirming an application or a user as authentic using some sort of credentials
an authentication service that can be invoked both by applications for application-managed authentication and by the web container for container-managed authentication.
the process of allowing access to those resources by entities (applications or users) that have been granted authority to use them.
logical channel 0, the only channel that is active at card reset in the APDU application environment. This channel is permanent and can never be closed.
the root of the class loader delegation hierarchy in charge of loading the Java Card RE system classes.
machine-independent code generated by the compiler and executed by the Java virtual machine.
a client that may directly and safely interact with the card holder. A card holder-facing client may typically be local, co-hosted on the card-hosting device, or in close proximity to the card.
the on-card application to download and install applications and libraries. The card manager receives executable binary and metadata from the off-card installer, writes the binary into the smart card memory, links it with the other classes on the card, and creates and initializes any data structures used internally by the Java Card Runtime Environment.
the Java Card platform layer responsible for securely adding and removing application code and instances onto the platform.
card management security policy
a permission-based security policy that is defined by a card management authority and that grants some permissions to an application or group of applications in accordance with the operational environment in which the application or group of applications is deployed.
a card session begins when it is powered up or reset. The card is then able to exchange messages with external clients. The card session ends when the card loses power or is reset.
applets with the same capabilities as those in previous versions of the Java Card platform and in the Classic Edition.
classic applet container mutex object
the object that is used by the Java Card RE to synchronize all concurrent accesses to a classic applet's code in order to guarantee its thread safety.
the Classic Edition is based on an evolution of the Java Card Platform, Version 2.2.2 and is backward compatible with it, targeting resource-constrained devices that solely support applet-based applications.
a Java programming language package that does not contain any non-abstract classes that extend the class javacard.framework.Applet. A classic applet application comprises a Java programming language package that contains one or more non-abstract classes that extend the javacard.framework.Applet class.
a direct child of the shareable interface class loader in charge of loading classic library classes.
classic SIO synchronization proxy
an object that implements a shareable interface of a classic applet application and that synchronizes with all other concurrent accesses to the classic applet application before delegating to the actual SIO. An SIO synchronization proxy is returned to each client of the classic applet application that requests access to that shareable interface.
a Java Card RE component that defines and enforces a different class namespace for the classes it loads.
class loader delegation hierarchy
the hierarchy of class loaders that enforces code isolation among applications while allowing for sharing of system and library code.
an on-card application that uses services provided by other applications (server applications).
a piece of software that preprocesses all of the Java programming language class files of a classic applet application that make up a package, and converts the package into a standalone classic applet application module distribution format (CAP file). The Converter also produces an export file.
when an object instance method is invoked, an owning context of the object becomes the currently active context for that particular thread of execution.
corresponds to the application owner identifier of the active context set upon entry into the group context for a particular thread of execution.
the applet container keeps track of the currently selected Java Card applet. Upon receiving a SELECT FILE command with this applet's AID, the applet container makes this applet the currently selected applet. The applet container sends all APDU commands to the currently selected applet.
a means of expressing an application's security structure, including roles, access control, and authentication requirements in a form external to the application, such as in the deployment descriptor of a web application.
an applet that is selected by default on a logical channel in the APDU application environment when it is opened. If an applet is designated the default applet on a particular logical channel in the APDU application environment on the Java Card platform, it becomes the active applet by default when that logical channel is opened using the basic channel.
The deployer takes one or more application archive files provided by an application developer and deploys the application into a card in a specific operational environment. The operational environment includes other installed applications and libraries, as well as standard bodies-defined frameworks. The deployer must resolve all the external dependencies declared by the developer.
The deployer is an expert in a specific operational environment. For example, the deployer is responsible for mapping the security roles defined by the application developer to the users that exist in the operational environment where the application is deployed.
see descriptor.
a document that describes the configuration and deployment information of an application. A deployment descriptor conveys the elements and configuration information of an application between application developers, application assemblers, and deployers. A runtime descriptor describes the configuration and deployment information of an application that are specific to an operating environment to which the application is to be deployed.
structure and encoding of a distribution or deployment unit intended for public distribution.
see deployment unit.
well-defined method of an object owned by an application (respectively the Java Card RE) that can be "legally" invoked by another application or the Java Card RE (respectively an application). SIO methods and other container-managed objects' lifecycle methods are application entry point methods. Java Card RE entry point objects' methods are Java Card RE entry point methods.
an object that encapsulates some occurring condition or situation. In the context of the event notification facility, an event is a shareable interface object that an application (event-producing application) uses to notify its clients (event-consuming applications) of an occurring condition.
an application that registers for notification of events fired by an event producing application.
an object that is registered to handle events when they occur. In the context of the event notification facility, an event listener is an object that a client application (event-consuming application) registers and uses to handle SIO-based events an application (event-producing application) produces.
a Java Card RE facility (or subsystem) that is used for event-driven inter-application communications.
see event listener.
the core component of the event notification facility. The event registry is used for registering for notification of events and for notifying of events.
a file produced by the Converter tool used during classic applet application development that represents the fields and methods of a package that can be imported by classes in other classic applet applications and classic libraries.
an applet with extended and advanced capabilities (compared to a classic applet) such as the capabilities to manipulate String objects and open network connections.
extension library class loader
a direct child of the shareable interface class loader in the class loader delegation hierarchy in charge of loading extension libraries.
in the Java Card platform, any classes, interfaces, their constructors, methods, and fields of an application that can be accessed from another application according to the Java programming language semantics, as defined by the Java Language Specification.
Externally visible items of a classic applet application are represented in an export file. For a classic library package, all classes, interfaces, their constructors, methods, and fields of an application that can be accessed from another application according to the Java programming language access control semantics, as defined by the Java Language Specification are listed in the export file.
an attribute of a file system object that indicates whether read or write operation on the object are permitted or denied.
a web application component that is used to transform the content or header information of HTTP requests or responses.
the process by which a Java virtual machine (VM) allows an unreferenced object instance to release non-memory resources (for example, close and open files) prior to reclaiming the object's memory. Finalization is only performed on an object when that object is ready to be garbage collected (meaning, there are no references to the object).
Finalization is not supported by the Java Card virtual machine. The method finalize() is not called automatically by the Java Card virtual machine.
the mechanism that prevents unauthorized accesses to objects in one application group context from another application group context.
a type of persistent mutable memory. It is more efficient in space and power than EPROM. Flash memory can be read bit by bit but can be updated only as a block. Thus, flash memory is typically used for storing additional programs or large chunks of data that are updated as a whole.
the process by which dynamically allocated storage is automatically reclaimed during the execution of a program.
the scope of a user authentication that can be tracked globally (card-wide). Global authentication is restricted to card-holder-users. Authorization to access resources protected by a globally authenticated card-holder-user identity is granted to all users.
protected object space associated with each application group and Java Card RE. All objects owned by an application belong to the context of the application group.
a direct child of the extension library class loader in charge of loading the libraries private to an application group. Libraries, private to different application groups, are loaded by distinct group library class loaders, one per web or extended applet application group.
a common pool of free memory in volatile and persistent spaces usable by a program. A part of the computer's memory used for dynamic memory allocation, in which blocks of memory are used in an arbitrary order.
The Java Card virtual machine's volatile heap is typically garbage collected on demand and on card tear.
The Java Card virtual machine's persistent heap is typically garbage collected on a less frequent basis. Memory associated with objects allocated from the persistent heap are not necessarily reclaimed.
in object-oriented programming, to produce a particular object from its class template. This involves allocation of a data structure with the types specified by the template, and initialization of instance variables with either default values or those provided by the class's constructor function.
a statement that indicates an operation for the computer to perform and any data to be used in performing the operation. An instruction can be in machine language or a programming language.
items that are not externally visible to other applications on the card. See also externally visible.
an acronym for Java Archive file, which is a file format used for aggregating and compressing many files into one.
Java Card Platform Remote Method Invocation
a subset of the Java Platform Remote Method Invocation (RMI) system optionally supported by the APDU application environment. It provides a mechanism for a client application to invoke a method on a remote object of an applet application on the card.
Java Card Runtime Environment (Java Card RE)
consists of the Java Card virtual machine and the associated native methods.
Java Card Virtual Machine (Java Card VM)
a subset of the Java virtual machine, which is designed to be run on smart cards and other resource-constrained devices. The Java Card VM acts an engine that loads Java class files and executes them with a particular set of semantics.
the context of the Java Card RE has special system privileges so that it can perform operations that are denied to contexts of applications.
Java Card RE entry point object
an object owned by the Java Card RE context that contains entry point methods. These methods can be invoked from any application group context and allows applications to request Java Card RE system services. A Java Card RE entry point object can be either temporary or permanent:
temporary - references to temporary Java Card RE entry point objects cannot be stored in class variables, instance variables or array components. The Java Card RE detects and restricts attempts to store references to these objects as part of the firewall functionality to prevent unauthorized reuse. Examples of these objects are APDU objects and the APDU byte array.
permanent - references to permanent Java Card RE entry point objects can be stored and freely reused. Examples of these objects are Java Card RE-owned AID instances.
a data item known within a block, but inaccessible to code outside the block. For example, any variable defined within a method is a local variable and cannot be used outside the method.
as seen at the card edge, works as a logical link to an applet application on the card. A logical channel establishes a communications session between a card applet and the terminal. Commands issued on a specific logical channel are forwarded to the active applet on that logical channel. For more information, see the ISO/IEC 7816 Specification, Part 4. (http://www.iso.org).
refers to embedding the Java Card virtual machine, runtime environment, and applications in the read-only memory of a smart card during manufacture.
designates the type or protocol of communication (HTTPS, SSL/TLS, SIO...) and the mode of operation (client or server) that characterizes a communication endpoint.
the logical unit of assembly of web or applet-based application. The components of a web application are assembled into a web application module. The components of an applet application are assembled into a applet application module.
implements the javacard.framework.MultiSelectable interface. Multiselectable applets can be selected on multiple logical channels in the APDU application environment at the same time. They can also accept other applets belonging to the same applet application being selected simultaneously.
an applet instance that is selected and, therefore, active on more than one logical channel in the APDU application environment simultaneously.
a permission that has a name but no actions list; the named permission is either granted or not. A named permission typically protects a function or functionality.
a method that is not implemented in the Java programming language, but in another language. The Card Manger does not load applications containing native methods.
a client that does not directly interact with the card holder, but interacts with some other-users such as remote administrators. A non-card holder-facing client may typically be a remote system that may interact with the card through the network to which the card-hosting device itself is connected.
memory that is expected to retain its contents between card tear and power up events or across a reset event on the smart card device.
normalization (classic applet)
the process of transforming and repackaging a Java application packaged for the Java Card Platform, Version 2.2.2, for deployment on both the Java Card Platform, Version 3, Connected Edition and the Java Card Platform, Version 3, Classic Edition.
the process of removing unnecessary "." and ".." segments from the path component of a hierarchical URI.
a software tool that allows Java applications packaged for Version 2.2.2 to be transformed and then repackaged for deployment on the Classic Edition.
the applet instance context or web application context or the Java Card RE context which was the currently active context when the object was instantiated.
in object-oriented programming, unique instance of a data structure defined according to the template provided by its class. Each object has its own values for the variables belonging to its class and can respond to the messages (methods) defined by its class.
an application that is not resident on the card, but runs at the request of a user's actions.
the off-card application that transmits the application and library executables to the card manager application running on the card.
a program or tool used to generate classic SIO synchronization proxies prior to packaging and deploying a classic applet application.
see client application.
the logical channel in the APDU application environment on which an APDU command is issued.
the application or Java Card RE context in which an object is instantiated or created.
see owning context.
an object that represents access to specific protected resources, such as security-sensitive system resources, or application resources, such as services provided by applications. Permissions are instances of subclasses of the Permission class. A permission has a name and may have an actions list.
an attribute of a permission used to designate those actions for which the resources designated by the target name are protected.
measures defined by a permission-based security policy that restrict access to protected system and library resources.
permission-based security policy
a security policy that maps some of the characteristics of an application requesting access to a protected resource to a set of permissions granted to the application.
an attribute of a permission used to designate a protected function or resource, or a set thereof.
the name attribute of a permission object (permission name) that designates the resource or set of resources that are protected with that permission.
persistent objects and their values persist from one card session to the next, indefinitely. Persistent object values are typically updated atomically using transactions. The term persistent does not mean there is an object-oriented database on the card or that objects are serialized and deserialized, just that the objects are not lost when the card loses power.
a well-defined event fired by the platform. Examples are clock resynchronization events.
a set of permissions granted to an application or group of applications by the platform security policy. A platform protection domain is defined by two sets of permissions: a set of included permissions that are granted and a set of excluded permissions that are denied and can never be granted.
the permission-based security policy that maps application models to sets of permissions granted to applications implementing these application models. For each of the application models, the platform security policy guarantees the consistency and integrity of the applications implementing the application model.
an entity that can be authenticated by an authentication protocol. A principal is identified by a principal name and authenticated by using authentication data. The content and format of the principal name and the authentication data depend on the authentication protocol.
a means for a security aware application to express the security model of the application when declarative security alone is not sufficient.
see protected resource.
an application or system resource that is protected by an access control mechanism.
temporary working space for storing and modifying data. RAM is non-persistent memory; that is, the information content is not preserved when power is removed from the memory cell. RAM can be accessed an unlimited number of times and none of the restrictions of EEPROM apply.
reachability disrupting object
a special object that prevents the promotion of a volatile object to become a persistent object. If a volatile object is referenced by a persistent object, which is not a reachability disrupting object, or by a root of persistence, the volatile object is automatically promoted and becomes a persistent object. An example of reachability disrupting object is a TransientReference object.
a fully functional and compatible implementation of a given technology. It enables developers to build prototypes of applications based on the technology.
an interface of an applet application, which extends, directly or indirectly, the interface java.rmi.Remote.
Each method declaration in the remote interface or its super-interfaces includes the exception java.rmi.RemoteException (or one of its superclasses) in its throws clause.
In a remote method declaration, if a remote object is declared as a return type, it is declared as the remote interface, not the implementation class of that interface.
In addition, Java Card RMI imposes additional constraints on the definition of remote methods of an applet application. See Runtime Environment Specification, Java Card Platform, v3.0.5, Classic Edition.
an object of an applet application whose remote methods can be invoked remotely from the off-card client. A remote object is described by one or more remote interfaces of an applet application.
an user whose identity may be assumed by a remote entity, such as a remote card administrator.
an object implementing the Runnable interface that has been registered for recurrent execution over card sessions. A task executes in its own thread.
a Java Card RE facility that is used for registering tasks for recurrent execution over card sessions.
an acronym for Remote Method Invocation. RMI is a mechanism for invoking instance methods on objects located on remote virtual machines (meaning, a virtual machine other than that of the invoker).
an abstract notion used by an application developer in an application that can be mapped by the deployer to a user, or group of users, in a security policy domain.
measures defined by a role-based security policy that restrict access by clients or by users to protected application resources.
a security policy that maps some of the characteristics of an application requesting access to protected resources, such as its identity and the identity of the user on behalf of whom the access is requested to roles permitted to access the protected resources.
memory used for storing the fixed program of the card. A smart card's ROM contains operating system routines as well as permanent data and user applications. No power is needed to hold data in this kind of memory. ROM cannot be written to after the card is manufactured. Writing a binary image to the ROM is called masking and occurs during the chip manufacturing process.
a URI that identifies the root of an application's namespace for a particular scheme. Examples are an application's service root URI, an application's event root URI.
see descriptors.
a web application container that redirects HTTP requests for protected content sent over unsecure connections to the secure port over which that content can be served. Protected content must be served only over a secure port.
a declarative way of defining the protection of web content. A security constraint associates authorization and or user data constraints with HTTP operations on web resources.
the scope over which security policies are defined and enforced by a security administrator of the security service. A security policy domain is also sometimes referred to as a realm.
designates the protected resources that can be accessed by individual applications or groups of applications. These protected resources may be security-sensitive system resources or application resources such as services provided by other applications.
the required security characteristics for a particular secure communication being established by either an application or by the web container on behalf of a web application.
a shareable interface object that a server application uses to provide a set of well-defined functionalities to its clients.
a Java Card RE facility (or subsystem) that is used for inter-application communications.
an object that the Java Card RE invokes to create a service - on behalf of the server application that registered that service - for a client application that looked up the service.
the core component of the service facility. The service facility is used for registering and looking up services.
an interface that defines a set of shared methods. These interface methods can be invoked from an application in one group context when the object implementing them is owned by an application in another group context.
shareable interface class loader
the direct child of the bootstrap class loader in the class loader delegation hierarchy in charge of loading publicly exposed shareable interfaces.
shareable interface object-based service
see service.
a card that stores and processes information through the electronic circuits embedded in silicon in the substrate of its body. Unlike magnetic stripe cards, smart cards carry both processing power and information. They do not require access to remote databases at the time of a transaction.
an acronym for Service Provider Interface or sometimes for System Programming Interface. The SPI defines calling conventions by which a platform implementer may implement system services.
a standard event with a well-defined semantic that an application may fire. Examples are standard application lifecyle events such as application creation and deletion events, and standard resource lifecyle events such as resource creation and deletion events.
a standard service with a well-defined interface that an application may provide and register. Examples are authenticators - authentication services.
is typically a computer in its own right with an interface which connects with a smart card to exchange and process data.
the basic unit of program execution. A process can have several threads running concurrently each performing a different job, such as waiting for events or performing a time consuming job that the program doesn't need to complete before going on. When a thread has finished its job, it is suspended or destroyed.
when an object instance method is invoked, the owning context of the object becomes the currently active context for that particular thread of execution. Synonymous with currently active context.
an atomic operation in which the developer defines the extent of the operation by indicating in the program code the beginning and end of the transaction.
a Java Card RE facility that enables an application to complete a single logical operation on application data atomically, consistently and durably within a transaction.
the state of transient objects do not persist from one card session to the next, and are reset to a default state at specified intervals. Updates to the values of transient objects are not atomic and are not affected by transactions.
classes whose instances can have their ownership transferred to a context different from their currently owning context. Transferable classes are of two types:
Implicitly transferable classes - Classes whose instances are not bound to any context (group contexts or Java Card RE context) and can, therefore, be passed and shared between contexts without any firewall restrictions. Examples are Boolean and literal String objects.
Explicitly transferable classes - Classes whose instances must have their ownership explicitly transferred to another application's group context in order to be accessible to that other application. Examples are arrays and newly created String objects.
a Java Card RE facility that allows for an application to transfer the ownership of objects it owns to an other application. Only instances of transferable classes can have their ownership transferred.
an on-card or off-card application client that an on-card application trusts on the basis of credentials presented by the client.
credentials that an on-card application uses to ascertain the identity of clients it trusts.
uniform resource identifier (URI)
a compact string of characters used to identify or name an abstract or physical resource. A URI can be further classified as a uniform resource locator (URL), a uniform resource name (URN), or both. See RFC 3986 for more information.
uniform resource locator (URL)
a compact string representation used to locate resources available via network protocols or other protocols. Once the resource represented by a URL has been accessed, various operations may be performed on that resource. See RFC 1738 for more information. A URL is a type of uniform resource identifier (URI).
a process performed on an application or library executable that ensures that the binary representation of the application or library is structurally correct.
memory that is not expected to retain its contents between card tear and power up events or across a reset event on the smart card device.