Hi Jan-Frederik Thanks for the draft.
The draft states that the FIDO2 challenge is derived from the TLS keying material, and that the EAP-FIDO server verifies the FIDO signature using the public key stored in the database. I am afraid these specifications will limit the wider adoption of EAP-FIDO. The FIDO Alliance has defined the specification of FIDO2 server (which is part of WebAuthn Relying Party's server function), and FIDO2 servers operate as the backend for the WebAuthn Relying Party. Therefore, I would like to suggest reconsidering the EAP-FIDO specification to enable the use of FIDO2 server. Since FIDO2 servers that have passed the FIDO Alliance's conformance self-validation possess a common REST API, it is possible to delegate challenge generation and signature verification to the FIDO2 server using this REST API. FIDO2 servers are designed to generate their own FIDO2 challenges, which means that the current EAP-FIDO specification, using FIDO2 challenges derived from TLS keying material, does not allow for the use of existing FIDO2 servers. Could you consider alternative methods to using FIDO2 challenges derived from the TLS keying material to bind the TLS handshake phase to the FIDO-exchange phase? Any feedback or comments on this matter would be appreciated. Thanks, -- Yukiko MINAMIE _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
