Link and Contact
Website |
Support |
Copyright © Calypso Networks Association, https://calypsonet.org.
This specification is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International (CC BY-ND 4.0).
You are free to share — copy and redistribute this document in any medium or format for any purpose, even commercially — under the following terms:
-
Attribution — You MUST give appropriate credit to the Calypso Networks Association, provide a link to the license, and indicate if changes were made. You MAY do so in any reasonable manner, but not in any way that suggests the Calypso Networks Association endorses you or your use.
-
NoDerivatives — If you remix, transform, or build upon this document, you MAY NOT distribute the modified material.
No additional restrictions — You MAY NOT apply legal terms or technological measures that legally restrict others from doing anything the license permits.
Implementation grant — The NoDerivatives condition above applies to this specification document only — its text, tables and diagrams. It does not restrict the use of the technical information the document contains. The Calypso Networks Association hereby grants everyone an irrevocable, worldwide, royalty-free permission to use the information contained in this specification to design, develop, and distribute software implementations of this API, in any programming language, under the license of their choice.
The full license text is available at https://creativecommons.org/licenses/by-nd/4.0/.
1. Abstract
This document is the official technical specification of the Terminal Generic Card API standardised by the Calypso Networks Association (CNA). It defines, in a language-agnostic way, the interfaces, classes, enumerations, exceptions, structural relationships and behavioural requirements that any conforming implementation of the Terminal Generic Card API MUST satisfy.
The Terminal Generic Card API is part of the broader CNA Terminal API family. It exposes the minimal contract required to exchange raw APDUs with an ISO/IEC 7816-4 card that has been selected through the Terminal Reader API, without prescribing any specific card application model.
Document Status
Reference |
YYMMDD-SP-CNATerminalAPI-GenericCard |
|---|---|
Short name |
CNA-TGC-API |
Version |
2.0.0-SNAPSHOT |
Revision date |
2026-07-20 |
Editor |
Calypso Networks Association |
Source repository |
https://github.com/calypsonet/calypsonet-terminal-genericcard-uml-api |
Reference license |
Creative Commons Attribution-NoDerivatives 4.0 International (CC BY-ND 4.0) |
| The present document specifies the 2.0.0-SNAPSHOT of the Terminal Generic Card API. It defines a single, coherent baseline against which conforming implementations are evaluated; the Since column indicates the version in which each member was introduced. |
Revision List
|
This section lists the high-level changes per version. The complete, fine-grained
changelog is maintained in the |
| Version / Date | Modifications |
|---|---|
v2.0.0-SNAPSHOT |
Baseline. |
2. Introduction
2.1. Purpose
The Terminal Generic Card API defines the contract used by terminal applications that need to exchange raw APDUs with an ISO/IEC 7816-4-compliant card without relying on a card-specific application layer (e.g. Calypso). It complements the Terminal Reader API (CNA-TR-API) by providing:
-
a card-selection extension that allows additional successful status words to be declared for the Select Application APDU,
-
a minimal transaction manager that prepares APDU commands, attaches an optional command identifier and an optional per-command duration bound (relay-attack countermeasure), and processes them as a single batch, returning the raw responses to the application.
Conforming implementations MUST guarantee interoperability with reader implementations of the CNA-TR-API specification.
2.2. Scope
This specification covers:
-
the factory used to instantiate the public types of the API,
-
the card-selection extension used to enrich the selection scenario for generic cards,
-
the transaction manager used to prepare and exchange APDUs with the selected card, including the per-command identifier and the per-command duration bound,
-
the property holder exposing the API version.
The following topics are out of scope:
-
the parsing of APDU payloads — the API exposes raw bytes only,
-
the application-level dialog with specific card products (covered by dedicated specifications),
-
the management of secure channels.
2.3. Conformance
A software product conforms to this specification if and only if:
Throughout this specification, the key words MUST, MUST NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in all capitals.
In conformance with RFC 2119, SHALL is equivalent to MUST; this specification uses MUST exclusively in order to avoid ambiguity.
2.4. Document Conventions
2.4.1. Naming
Type names follow UpperCamelCase; operation, parameter and enumeration-member names follow lowerCamelCase
except for enumeration values which use UPPER_SNAKE_CASE. Names defined by this specification are reproduced
as-is in the UML class diagram (Section 4.3).
2.4.2. Language-agnostic types
The following symbolic type names are used in operation signatures and are mapped, in each binding, to the closest equivalent native type. Implementations MUST preserve the semantic intent rather than the syntactic form.
| Symbolic type | Description | Typical bindings |
|---|---|---|
|
Sequence of characters, UTF-8 encoded by default. |
|
|
Two-state truth value. |
|
|
Signed 8-bit value. |
|
|
Signed 32-bit integer. |
|
|
Signed 64-bit integer. |
|
|
Ordered sequence of octets. |
|
|
Ordered collection of |
|
|
Indicates that an operation returns no value. |
|
2.4.3. Type tables
Each interface, class, enumeration and exception defined in this document is described by a table of the form:
Name |
The type’s normalized name. |
|---|---|
Kind |
The category of the type (interface, class, enumeration, exception, etc.). |
Namespace |
The namespace in which the type is defined. |
Extends |
The type extended by this type, when applicable. |
Implements |
The interface implemented by this type, when applicable. |
Since |
The version of the API in which the type was introduced. |
Purpose |
A normative description of the type’s responsibility. |
See also |
Cross-references to related operations or types, each a hyperlink to the corresponding table. Present only when applicable. |
The Purpose row states, in one or two sentences, the responsibility of the type and the way an instance is obtained. It is meant to be scanned, not read: any content that requires structure or depth — rules, lists, notes, value tables or examples — is placed as prose below the table.
2.4.4. Operation tables
Each operation defined in this document is described by a table of the form:
Signature |
The operation’s language-agnostic signature. |
|---|---|
Since |
The version of the API in which the operation was introduced. |
Description |
A normative description of the operation’s behaviour. |
Parameters |
A description of each input parameter. |
Returns |
A description of the returned value, if any. |
Throws |
A list of exceptional conditions, each mapped to a specific exception type. |
See also |
Cross-references to related operations or types, each a hyperlink to the corresponding table. Present only when applicable. |
2.4.5. Operation contracts
To avoid repetition, the following rules apply to every operation table in Chapter 5 and are therefore not restated for each operation:
-
Non-
nullarguments. Unless explicitly stated otherwise, every input parameter MUST be non-null. An implementation MUST raiseIllegalArgumentExceptionif anullvalue is supplied. This implicitnullcheck is not repeated in the Throws row, which statesNone.when no other exception can occur. -
Non-
nullresults. Unless the return type is marked nullable (T?) or the Returns row states otherwise, an operation returns a non-nullvalue. -
Collections. Unless the return type is marked nullable (
T?), an operation whose return type is a collection (e.g.list,set,map) returns an empty collection rather thannull. -
Fluent composition. Builder-style operations return the current instance so that calls can be chained.
2.4.6. Concurrency
Unless explicitly stated otherwise, the stateful types defined by this specification are not thread-safe. A given instance MUST be accessed from a single thread at a time; concurrent use of the same instance without external synchronisation results in undefined behaviour. Distinct instances MAY be used concurrently.
2.5. References and Resources
2.5.1. Calypso References
References to CNA Terminal APIs designate the indicated major version; any later release within the same major is backward-compatible per that API’s evolution policy.
| Reference | Document |
|---|---|
CNA Terminal API — Reader (SP-CNATerminalAPI-Reader), version 3.0, Calypso Networks Association. |
2.5.2. Normative References
| Reference | Document |
|---|---|
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, March 1997. |
|
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words, B. Leiba, May 2017. |
|
2.5.3. External Resources
| Resource | Link |
|---|---|
Calypso Networks Association |
|
Terminal APIs website |
|
Terminal APIs documentation |
3. Glossary and Acronyms
3.1. Glossary
| Term | Definition |
|---|---|
APDU |
Application Protocol Data Unit, the message format used between the terminal and the card, as defined in ISO/IEC 7816-3. |
Card Reader |
Hardware or software component capable of detecting cards and exchanging data with them. |
Command Identifier |
Application-supplied integer attached to a prepared APDU, used to retrieve the corresponding response or to identify the failing command in case of error. |
Relay Attack |
Software-level attack consisting in interposing a relay between the card and the terminal to redirect APDU exchanges to a distant card. |
3.2. Acronyms
| Abbreviation | Expansion |
|---|---|
AID |
Application IDentifier |
APDU |
Application Protocol Data Unit |
CNA |
Calypso Networks Association |
ISO |
International Organization for Standardization |
SW |
Status Word |
4. Architectural Overview
4.1. Functional positioning
4.2. Logical namespaces
| Namespace | Role | Summary |
|---|---|---|
|
Public API |
Factory, selection extension and transaction manager. Properties. |
4.3. UML class diagram
The following UML class diagram provides a visual representation of the types and relationships defined by this specification:
5. API Specification
5.1. Classes
5.1.1. Generic Card API Properties
Name |
|
|---|---|
Kind |
Final class |
Namespace |
|
Since |
1.0 |
Purpose |
Exposes the immutable properties of the Terminal Generic Card API. |
Constants
| Name | Type | Since | Description |
|---|---|---|---|
|
|
1.0 |
String representation of the version of the API implemented by the conforming binding (e.g. |
|
The |
5.2. API Interfaces
5.2.1. Card Transaction Manager
Name |
|
|---|---|
Kind |
Interface |
Namespace |
|
Extends |
|
Since |
1.0 |
Purpose |
Provides the basic operations required to prepare, identify and process APDU exchanges with an ISO/IEC 7816-4
card. The stereotype on |
The CardTransactionManager uses a prepare/process model inherited from CNA-TR-API: the application prepares
APDU commands with the prepareCommand overloads and processes them through the inherited processCommands()
operation. Each prepared command MAY carry an optional command identifier (idCommand) supplied by the
application, used to retrieve the corresponding response or to identify the failing command in case of error.
Each prepared command MAY also carry an optional maximum duration (maxDuration, in milliseconds) used to
detect a relay attack at the individual-command level.
Get Last Execution Response
Signature |
|
|---|---|
Since |
2.0 |
Description |
Returns the response of the command identified by |
Parameters |
|
Returns |
The non-empty response bytes, or |
Throws |
None. |
Get Last Execution Responses
Signature |
|
|---|---|
Since |
2.0 |
Description |
Returns the responses collected during the last call to This operation does not alter the internal state of the manager: the list of responses remains available
until |
Returns |
A |
Throws |
None. |
Prepare Command (APDU)
Signature |
|
|---|---|
Since |
2.0 |
Description |
Prepares an APDU command without command identifier nor duration bound. |
Parameters |
|
Returns |
The current instance ( |
Throws |
None. |
Prepare Command (APDU, ID Command)
Signature |
|
|---|---|
Since |
2.0 |
Description |
Prepares an APDU command with an application-supplied identifier. The identifier MAY later be used to retrieve
the corresponding response via |
Parameters |
|
Returns |
The current instance ( |
Throws |
None. |
Prepare Command (APDU, ID Command, Max Duration)
Signature |
|
|---|---|
Since |
2.0 |
Description |
Prepares an APDU command with an application-supplied identifier and a maximum tolerated exchange duration. The
effective duration of the corresponding APDU exchange is measured, and an |
Parameters |
|
Returns |
The current instance ( |
Throws |
None at preparation time. The duration check is performed at processing time. |
5.2.2. Generic Card API Factory
Name |
|
|---|---|
Kind |
Interface |
Namespace |
|
Since |
1.0 |
Purpose |
Factory used by the application to obtain instances of the public types provided by the API. |
The GenericCardApiFactory is the single entry point through which the application instantiates the public types
of the API. It is provided as a single instance whose accessors each return a fresh, fully initialised object.
Create Card Transaction
Signature |
|
|---|---|
Since |
1.0 |
Description |
Returns a new, freshly initialised |
Parameters |
|
Returns |
|
Throws |
None. |
Create Generic Card Selection Extension
Signature |
|
|---|---|
Since |
1.0 |
Description |
Returns a new, freshly initialised |
Returns |
|
Throws |
None. |
5.2.3. Generic Card Selection Extension
Name |
|
|---|---|
Kind |
Interface |
Namespace |
|
Extends |
|
Since |
1.0 |
Purpose |
Extends the |
Add Successful Status Word
Signature |
|
|---|---|
Since |
1.0 |
Description |
Adds a status word to the list of those considered successful for the Select Application APDU. Note: the list initially contains the standard successful status word |
Parameters |
|
Returns |
The current instance ( |
Throws |
None. |