Transporting APDUs over T=1
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
Carrying APDUs over T=1
T=1 is a block-oriented, half-duplex protocol. Where T=0 moves bytes under the card’s moment-to-moment direction, T=1 moves framed blocks with their own length, sequencing and error detection. The practical consequence is that an application-level APDU maps onto T=1 almost directly.
Block structure
Every T=1 block has the same frame:
- NAD — node address, identifying source and destination.
- PCB — protocol control byte, which determines the block type and carries sequence and chaining information.
- LEN — length of the information field.
- INF — the information field, carrying application data where present.
- EDC — error detection code over the block.
Three block types
- I-blocks carry application data. A command APDU travels in one or more I-blocks; the response comes back the same way.
- R-blocks carry no data. They acknowledge receipt or request retransmission after an error.
- S-blocks handle protocol housekeeping: negotiating the information field size, requesting a waiting time extension, resynchronising after a failure, and aborting a chain.
Chaining
An APDU larger than the negotiated information field size is split across several I-blocks, each flagged in the PCB as having more to follow. The receiver reassembles them. Chaining is what allows T=1 to carry large commands and responses without special application-level handling — and it is why extended length fields are considerably less troublesome on T=1 than on T=0.
Why T=1 is easier for application code
Because a block can carry data in either direction and the protocol frames each transfer explicitly, the four APDU cases all map naturally. There is no GET RESPONSE dance for a case 4 command, and no 6Cxx length-correction round trip caused by the transport. Error recovery — retransmission after a corrupted block, resynchronisation after a lost one — is handled inside the protocol rather than surfacing to the application.
The cost is complexity in the transport implementation itself: sequence number tracking, chaining state, and timer management all live there.
Implementation guidance
- Negotiate the information field size and then respect it. The S-block exchange that sets it exists for a reason; sending oversized blocks is a common cause of failures that look intermittent.
- Implement waiting time extension. A card performing a long cryptographic operation will ask for more time. Refusing it turns valid operations into timeouts.
- Handle resynchronisation as a real path. It is rare in a lab and less rare in the field, particularly with worn contacts.
- Do not assume T=1 availability. The ATR states which protocols the card offers. Where both are offered, PPS negotiation selects between them.
- Where you control both ends, prefer T=1. Large transfers and case 4 commands are simpler, and the error handling is more robust.
Authoritative source
For the normative mapping of APDUs onto T=1, refer to ISO/IEC 7816-4:2020, published by ISO, together with ISO/IEC 7816-3, which specifies the T=1 protocol itself. This page is Ambimat’s own explanation and does not reproduce or replace the standard.