1. PC/SC Applications and New Developments
Boris Balacheff
Member of PC/SC Technical Workgroup
CTST’ 2000 Miami

2. PC/SC Revision 1.0 Limitations
Emergence of Multi-application smartcards finds a lack of support in Revision 1.0 (I.e. Windows for Smartcards, JavaCards…):
It is not possible to manage dynamically the off-card components that are used to interact with on-card applications
Smartcard reader support is not up-to-date with current reader technology developments
No support for synchronous and contactless cards
CTST’ 2000 Miami

3. Multi-Application Cards
Currently, Service Providers are mapped to a specific card-type (using ATR) in the Resource Manager database
With multi-application cards, the card-type does not reflect the card’s functionality/applications
Need for a flexible and dynamic mechanism to update Service Provider information on the PC platform along with on-card applications changes
ATR = Answer To Reset
CTST’ 2000 Miami

4. Multi-Application Cards (cont.)
It is not enough that the PC/SC Resource Manager can only recognise a smartcard based on manufacturer-specific ATR information
To be able to dynamically assign Services Providers, information describing the card must be held on the card
Need for a card recognition mechanism that is more flexible, in order to reflect what is on the card dynamically
CTST’ 2000 Miami

5. Enhanced Smartcard Readers
Revision 1.0 only supports readers with basic APDU communication capabilities
Reader technologies with extended capabilities become widespread (pinpads, displays, multi-slot, SecurePin, biometrics…)
Need to allow interoperability between cards and PC applications that use these new reader capabilities
APDU = Application Protocol Data Unit
CTST’ 2000 Miami

6. Other Card Technologies
Contactless cards are a growing market
Synchronous cards are already used by many applications
Need to provide some support to allow the same interfaces and look-and-feel as asynchronous cards, at the PC application level
CTST’ 2000 Miami

7. Introducing PC/SC Revision 2.0
Revision 2.0 of PC/SC aims at addressing these limitations. It does this by introducing the following:
A New card recognition mechanism
A Dynamic Service Provider Assignment mechanism
A Mechanism for enhanced smartcard reader support
Support for contactless and synchronous cards
CTST’ 2000 Miami

8. Card-Aware Application
PC/SC 2.0 Architecture
ICCSPs in the PC/SC Revision 1.0 sense
Card-Aware Application
Interfaces Enhanced reader capabilities
ADSP
IFD SP
ICCOS-SP
Resource Manager
ADSP Locator
Abstraction of reader capabilities
Slot 1
Slot 2
Pin Pad
Display
IFDSP = IFD Service Provider. This Service Provider interfaces the extended capabilities of an Enhanced IFD (I.e. SecurePIN, Display, Biometrics, Multiple slots…).
ICCOS-SP = ICC Operating System Service Provider. This Service Provider interfaces functionality relative to the card OS.
ADSP = Application Domain Service Provider. This Service Provider interfaces functionality specific to an on-card application.
ADSPL = ADSP Locator. This Service Provider is used by the Resource Manager to be able to list on-card applications, find the ADSP for a specific application.
IFD Handler
New component to manage dynamic access to on-card applications
Reader
Smart Card
CTST’ 2000 Miami

9. Typical Responsibility Application Developer
Revision 2.0 Approach
Card and Reader
Card Operating System
Card Applications
CardInfo Structure
IFD Subsystem (IFD + IFD Handler)
Software Components
ICCOS Service Provider
(ICCOS-SP)
Application Domain Service
Provider (ADSP)
ADSP Locator (ADSPL)
IFD Service Provider (IFDSP)
Typical Responsibility
Card Vendor
Application Developer
Card Issuer
IFD Vendor
CTST’ 2000 Miami

10. Card Recognition Resource Manager Smartcard Initial Access Data
ATR
History Bytes
Communications Parameters
Initial Access Data Command
Data Structures 1
CardInfo structure
ADSPL id
ICCOS id
CardInfo 3
Initial
Access
Data 2
Smartcard
CTST’ 2000 Miami

11. Service Provider Assignment
Guid of ADSP
IIDs of Interfaces
ID_ADSP_AppX
IID_I1, IID_I2 6
Application
ListAppInterfaces 3
Instantiate
(from ADSPL id)
ADSP-L 2
ID_ADSP_AppX + reader name 8
Find AppInterfaces I1 and I2 1
AppInterfaces and corresponding ADSP Guids 7
ListAppInterfaces 4
AppInterfaces 5
Resource Manager
ADPSL= Application Domain Service Provider Locator, or ADSP Locator.
Smartcard
CTST’ 2000 Miami

12. ICC-Aware Application
Enhanced IFDs
ICC-Aware Application
ADSP
IFD SP
These components are responsible for implementing and interfacing the Enhanced Reader Capabilities
ICCOS-SP
Resource Manager
ADSP Locator
Slot 1
Slot 2
Pin Pad
Display
IFD Handler
Reader
Smart Card
CTST’ 2000 Miami

13. Contactless and Synchronous Cards
ICC-Aware Application
ADSP
IFD SP
ICCOS-SP
Resource Manager
ADSP Locator
Slot 1
Slot 2
Pin Pad
Display
These components are responsible for implementing PC/SC support for Contactless and/or Synchronous cards
The darker components are responsible for handling the support of a contactless card type.
For contactless cards, functionality such as ATR, insertion/removal, and card selection, will have to be emulated in these component to match the specification model.
Contactless support will be provided for ISO proximity ICCs.
IFDs supporting Synchronous cards will have to support ISO for Synchronous card types 1 and 2.
IFD Handler
Reader
Smart Card
CTST’ 2000 Miami

14. Further Information WhitePaper on PC/SC Revision 2.0 available at:
CTST’ 2000 Miami