Extended APDU are more and more used by applications and cards. But an application has no way to know if the reader is capable of supporting extended APDU. So an application + card may work with one reader and fail with another reader.
I proposed an evolution to the standard to add such a feature (adding a new tag to FEATURE_GET_TLV_PROPERTIES) but the PC/SC workgroup was not really enthusiastic about the idea. An application could have displayed an error message to the user indicating that the reader does not support extended APDU and that another reader should be used instead.
What we get instead is a PC/SC error to the application and bug reports to me and others.
So, after yet another bug report about a failing application because of extended APDU, I modified the reader lists (supported, should work, unsupported, disabled) and the reader matrix to contain the information: does this reader support extended APDU?
XIRING MyLeo
The reader matrix contains a new column 'limitations'. As with any column it is possible to sort the matrix using this 'limitations' column. You then get 2 groups of readers: those supporting extended APDU, and this NOT supporting extended APDU.
It will not help user determine why the application failed to work correctly. But at least it will indicate that the reader they are using is "limited".
If you have an application failure you can check if the reader you use does support extended APDU.
If you have other ideas to solve the problem just contact me or the MUSCLE mailing list.
Extended APDU
An extended APDU is an command to the card with a data or response of more than 256 bytes. It is not easy to detect an extended APDU unless you talk ISO 7816-3 fluently. I will not go into details here.PC/SC limitation
PC/SC (also called WinSCard) is the standard API to use smart card reader and a smart card. Unfortunately PC/SC can't tell the application if the reader will, or not, support extended APDU.I proposed an evolution to the standard to add such a feature (adding a new tag to FEATURE_GET_TLV_PROPERTIES) but the PC/SC workgroup was not really enthusiastic about the idea. An application could have displayed an error message to the user indicating that the reader does not support extended APDU and that another reader should be used instead.
What we get instead is a PC/SC error to the application and bug reports to me and others.
Reader support
Not all readers will support extended APDU. I created a web page to explain the situation when using my CCID driver. But the page may be do hard to find.So, after yet another bug report about a failing application because of extended APDU, I modified the reader lists (supported, should work, unsupported, disabled) and the reader matrix to contain the information: does this reader support extended APDU?
Examples
The user in the latest bug report was using a Xiring MyLeo reader. If you go to the description of this reader at http://pcsclite.alioth.debian.org/ccid/supported.html#0x0F140x0037 you will now see:XIRING MyLeo
USB descriptor: readers/Xiring_MyLeo.txt
Features: PIN Verification, PIN Modification
Limitations: No extended APDU
In CCID release: 1.4.2
The new field is "Limitations" (in red).The reader matrix contains a new column 'limitations'. As with any column it is possible to sort the matrix using this 'limitations' column. You then get 2 groups of readers: those supporting extended APDU, and this NOT supporting extended APDU.
It will not help user determine why the application failed to work correctly. But at least it will indicate that the reader they are using is "limited".
Conclusion
If you plan to buy a new reader you should take care of the reader ability to supported extended APDU.If you have an application failure you can check if the reader you use does support extended APDU.
If you have other ideas to solve the problem just contact me or the MUSCLE mailing list.
ConversionConversion EmoticonEmoticon