Gemalto Prox–DU Guide

PC/SC Guide
Prox–DU & Prox–SU
www.gemalto.com
DOC119811A Public Use Page 14/129
Second, it is responsible for controlling the allocation of reader resources (and hence
access to smart cards) across multiple applications. It does this by providing mechanisms
for attaching to specific readers in shared or exclusive modes of operations.
Finally, it supports transaction primitives on access to services available within a given
smart card. This is extremely important because current smart cards are single-threaded
devices that often require execution of multiple commands to complete a single function.
Transactions allow multiple commands to be executed without interruption, ensuring that
intermediate state information is not corrupted.
Service Provider
The service provider is optional and is not described in this document because it is smart
card dependant. However some information is given in the next paragraph.
The service provider is the mechanism through which a smart card-specific set of
functionalities (in the form of an API) is made accessible to smart card-aware application
software. For every smart card, there will be at least one service provider; it is through this
service provider that an application can access data or services on that specific smart card.
The following three classes of services are widely implemented within existing smart cards:
• File services
• Authentication Services
• Cryptographic Services
These services, when present, have a high degree of functionality in common across smart
cards. Consequently, it is beneficial to standardize interfaces to these services so that
application development and maintenance are simpler. This specification defines such
interfaces as well as a standard interface for controlling basic access to a smart card.
Additional smart card services tend to reflect the needs of specific application domains
(EMV, GSM, and so on). It is believed most appropriate for groups within specific industries
to standardize interfaces in such areas. This architecture fully supports the addition of such
interfaces to the core set identified above.
The definition of the API’s exposed by a specific service provider generally comes from a
third-party workgroup (EMV, GSM, PC/SC, etc.). The service provider, by definition, has an
intimate knowledge of the smart card to which it provides access. The implementation of
these API’s might be expected to come from a variety of sources, including (but not limited
to) the following:
• The smart card supplier who wants to enable smart card use within the PC
environment. Providing a service provider makes accessing the smart card an
application software development effort that can be pursued by application
developers with no specific expertise in smart card technology (either smart cards
or readers).
• The smart card issuer, who might layer a “personalized” service provider on top of
the service provider provided by its smart card supplier.
• A smart card-Aware Application supplier who wishes to define the level of
functionality required of a smart card to adequately support the application. In
defining the API, the application supplier enables one or more smart card suppliers
to provide a smart card and the service provider that implements the API defined by
the application supplier.
• One or more parties interested in a specific domain, who wish to enable the
development of both applications and smart cards to support those applications
within a domain of interest.

Gemalto Prox–DU Specifications

General

Brand	Gemalto
Model	Prox–DU
Category	Card Reader
Language	English