Summary: | [WebAuthn] Any plan to support NFC APDU short length encoding ? | ||
---|---|---|---|
Product: | WebKit | Reporter: | nuno.sung <nuno.sung> |
Component: | WebKit Misc. | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW --- | ||
Severity: | Normal | CC: | jiewen_tan, loginllama, webkit-unassigned |
Priority: | P2 | ||
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Bug Depends on: | |||
Bug Blocks: | 181943 |
Description
nuno.sung
2020-02-14 21:58:31 PST
(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. |