As the desciription under https://github.com/WebKit/webkit/blob/master/Source/WebCore/Modules/webauthn/apdu/ApduCommand.h "This class implements only the extended length encoding." There are still many legancy nfc java card for U2F can support short length encoding.
(In reply to nuno.sung from comment #0) > As the desciription under > https://github.com/WebKit/webkit/blob/master/Source/WebCore/Modules/webauthn/ > apdu/ApduCommand.h > "This class implements only the extended length encoding." > > There are still many legancy nfc java card for U2F can support short length > encoding. Besides supporting legacy devices, is there any other reasons to introduce short length encoding? I want to have a better understanding of its benefits to prioritize the work.
(In reply to Jiewen Tan from comment #1) > Besides supporting legacy devices, is there any other reasons to introduce > short length encoding? I want to have a better understanding of its benefits > to prioritize the work. Thanks for your consideration. Because these device still can be supported by other FIDO clients of Windows10 and Android with short APUD encoding. Although I don't know if they have other reasons for this support. And some users will be happy to keep using them on iOS .
Most authenticators support both short and extended length. The reason is that some number of desktop CCID readers don't support extended length encoding, If you know it is not a problem with the built in iOS reader then I wouldn't make it a high priority. If you are planning on supporting external readers on OSX like Windows then you will need to support short encoding as a fallback. NFC can be a bit of a pain in the ass but it is better than blue tooth.