Overview
ISO/IEC TS 23465-3:2023 - Card and security devices for personal identification: Programming interface for security devices - Part 3: Proxy describes the software layer called the proxy that sits between client applications and security devices (e.g., integrated circuit cards / ICCs). The proxy converts the abstract ISO/IEC 23465 API calls into device-specific communication, handles connectivity, enforces security conditions, and provides serialization/de‑serialization for messages exchanged with security devices.
Key topics and technical requirements
- Proxy responsibilities
- Acts as the dispatcher/mediator between the ISO/IEC 23465 API (client applications) and physical security devices.
- Hides low‑level addressing and APDU protocol details from clients.
- Layered proxy model
- Includes resolution, class-model resolution, administration, security, translation, connectivity, exception handling and optional layers (e.g., crypto, discovery, registration).
- Function resolution and class instantiation
- Defines how API calls are resolved (glue code) and how class objects for devices are instantiated and life‑cycled.
- Security handling
- Supports security attributes and access rules (user verification, authentication, secure messaging), interpretation of ISO/IEC 7816‑4 security conditions, and secure provisioning of confidentiality and authenticity.
- Connectivity and multi‑client support
- Multiplexing, task management and management of multiple security devices and parallel clients.
- Translation and serialization
- Specifies translation of abstract API functions into device commands and serialization/de‑serialization syntax and methods (note: common formats referenced in the specification context include CBOR and JSON).
- Data structures and resolving mechanisms
- Defines data objects and structures related to security device handling and function resolution.
Applications and who should use this standard
- System architects and middleware developers building lightweight, portable security stacks for mobile, IoT and embedded platforms.
- Smart card/secure element vendors and device manufacturers implementing drivers or proxy components to expose standardized APIs.
- Platform integrators in government ID, payment, telecom, enterprise identity and access management who need consistent access to heterogeneous security devices.
- Software developers implementing client applications that must interoperate with multiple ICC types without handling APDU complexity.
Practical benefits include reduced middleware footprint, simplified discoverability of card capabilities, improved portability of ICC functionality across devices, and a standardized way to translate high‑level API calls into secure, device‑specific commands.
Related standards