Application Selection and Card Services
ISO 7816 Part 4: Interindustry Commands for Interchange
ISO 7816 part 4, section..1 2 3 4 5 6 7 8 9 annex.. A B C D E F
Finding and using an application on a card
A modern card is rarely a single application. Part 4 defines the services that let a terminal discover what is present, select the application it wants, and then work with it — without either side needing prior knowledge of the other’s internal layout.
Card identification
Before selecting anything, a terminal may need to know what kind of card it is holding. Two sources answer this: the historical bytes in the ATR, which arrive for free at reset, and data objects retrievable with GET DATA once communication is established. The first is fast but unauthenticated; the second is richer and can be protected. Use the first to configure behaviour and the second when the answer must be trustworthy.
Application identifiers
An application is named by an Application Identifier (AID) of up to sixteen bytes. It has two parts: a registered application provider identifier, allocated through the registration scheme in ISO/IEC 7816-5, and a proprietary extension chosen by that provider. The registration is what makes an AID globally unique, and it is why inventing an AID from thin air for a production system is a mistake — collisions on a multi-application card are not theoretical.
Two ways to select
Implicit selection means the card has a default application active after reset, with no SELECT required. This is efficient and appears in closed systems where the card only ever does one thing.
Direct selection means the terminal issues SELECT with the AID as the target, telling the card which application it wants by name. This is what a multi-application card requires and what any terminal working across an open ecosystem will do.
Selection by AID supports partial matching: a terminal can present a prefix and ask for the first or next application whose AID begins with it. This is how a terminal enumerates a family of related applications without knowing every full identifier in advance.
Where a card carries a directory file listing the applications present, a terminal can read that instead of probing. Whether such a file exists is card-dependent.
What selection returns
A successful SELECT can return File Control Information describing the selected application — its parameters, and management data that may include a label, a preferred language, or a pointer to further data. Parsing this rather than assuming a layout is what makes terminal code survive a card profile change.
Services available once selected
- Data object retrieval. GET DATA fetches values by BER-TLV tag, independent of where or whether they are stored in a file.
- File selection and file I/O. The binary and record commands operate within the selected application’s context, either after an explicit SELECT or by naming a file through its short EF identifier.
Logical channels
Logical channels allow more than one application context to be open at once, each with its own selected file and its own security status. The channel number is carried in the low bits of the class byte. Support is optional and worth confirming before designing around it — but where it exists it avoids repeated selection and re-authentication when a terminal must interleave work across applications.
Practical notes
- Selecting a new application resets your security status. Expect to re-authenticate. Designs that assume a PIN verification persists across a selection will fail intermittently.
- Handle “application not found” as a normal outcome. On an open card population, most cards will not carry your application. A status word in the
6Arange indicating file or application not found is information, not a fault. - Do not rely on a card’s application order. Enumerate explicitly rather than assuming the first match is the one you want.
- Illustrative example. A terminal serving two schemes might: read the historical bytes to learn the card’s capabilities; attempt SELECT with the first scheme’s AID; on a not-found status, attempt the second; and on success, parse the returned FCI to locate the data it needs. Every step degrades cleanly if the card is unfamiliar.
Authoritative source
For the normative specification of application identification and selection, refer to ISO/IEC 7816-4:2020, published by ISO, and to ISO/IEC 7816-5 for the registration of application providers. This page is Ambimat’s own explanation and does not reproduce or replace the standard.