Consider using chained APDUs instead of extended APDUs for CTAP2/NFC

The CTAP2 transport specification for NFC allows two different encodings for long (fragmented) requests and responses: https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#nfc-fragmentation .

Extended APDUs are simpler to implement, however not all hardware (smartphones) supports these very large (~1KB) commands, some chipsets (e.g NXP PN532) are limited to 255 bytes. See also https://github.com/DangerousThings/flexsecure-applets/blob/master/docs/4-android.md#maximum-nfc-transceive-length , https://github.com/NXPNFCLinux/linux_libnfc-nci/issues/116 .

I suggest checking the chipset capabilities using IsoDep.getMaxTransceiveLength (https://developer.android.com/reference/android/nfc/tech/IsoDep#getMaxTransceiveLength()) before attemting so send extended APDUs, and fall back to chained APDUs otherwise.

Start by reviewing the CTAP2 NFC fragmentation specification and Android's IsoDep.getMaxTransceiveLength() API. Locate the NFC transport implementation in the repository, then verify that the available transceive length is checked before extended APDUs are used and that chained APDUs handle smaller limits. Done means long requests and responses work on hardware limited to 255 bytes.