Smart Card Profiles
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
Card profiles: why “ISO 7816-4 compliant” is not a specification
Part 4 defines a large toolkit, most of it optional. A real card implements a subset. That subset — which commands, which file structures, which referencing methods, which security mechanisms — is what we mean by a card profile, and it is what actually determines whether two implementations interoperate.
What varies between cards
- Command coverage. Which instructions are implemented at all, and which parameter options each accepts.
- File structures offered. Whether linear variable or cyclic files are supported, not merely transparent and linear fixed.
- Referencing methods. Whether selection by path is supported, whether short EF identifiers are available, whether partial AID matching works.
- Length handling. Whether extended length fields are accepted, and on which protocols.
- Security mechanisms. Which authentication methods exist, which secure messaging modes are available, how access conditions are expressed.
- Concurrency. Whether logical channels are supported and how many.
Why this matters commercially
A datasheet line reading “ISO 7816-4 compliant” is close to contentless. Two cards can both be entirely conformant and still fail to run the same application, because one supports selection by path and the other does not, or because one accepts extended length only over T=1.
The questions worth asking a supplier are concrete: which instructions, with which parameter values, under which access conditions, on which protocols, with what maximum data lengths. A profile answers those; a compliance claim does not.
How profiles get pinned down in practice
Three mechanisms are used, usually together:
- Scheme specifications. Payment, identity and transit specifications each define a mandatory subset of Part 4 plus their own additions, and certify products against it. This is why an EMV or an eID card is a far more predictable target than a generic card.
- Card capability data. The card itself can describe parts of its profile, in the historical bytes and in retrievable data objects. Reading this at runtime is more robust than hard-coding assumptions.
- Vendor documentation. The full profile normally lives in the card platform’s own reference manual rather than in any standard.
Guidance for a product programme
- Write down the profile you depend on. An explicit list of required commands and options is the document that makes second-sourcing possible.
- Discover rather than assume. Where the card can tell you something — capabilities, file control information — ask it instead of hard-coding.
- Degrade deliberately. Design the terminal to detect an unsupported option and fall back, rather than failing on an unexpected status word.
- Re-qualify on any card change. A new mask revision from the same vendor can change profile details. Treat it as a new card until tested.
- Illustrative example. A terminal that prefers a short EF identifier read but falls back to an explicit SELECT when the card returns a wrong-parameters status will work across a much wider card population than one that assumes either mechanism universally.
Authoritative source
For the normative definition of the options a card may implement, refer to ISO/IEC 7816-4:2020, published by ISO. This page is Ambimat’s own engineering guidance on profiling and does not reproduce or replace the standard.