- From: Nuno Sung via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Jul 2022 03:47:23 +0000
- To: public-webauthn@w3.org
> Some protos like CTAP2.1 enforce that if rk was sent from the browser to the device it MUST create an rk or error ( https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309.html#op-makecred-step-rk ) but this may not be necesarily be true for all classes of authenticators. @emlun Since ctap2.1 spec has addressed it, RP could use attestation on this part for different types of authenticators. - ctap2.0 authenticators, the credential is discoverable or not may be different to the parameter or credProps. - ctap2.1 authenticators, the credential's type is equal to this in credProps. - Else (un-attestable authenticators), no authenticator flags could be trusted even specs add this flag finally. My points are, - The flag from "weird ctap2.1 authenticator" may be still wrong. It should be another topics that how to address wrong behaviors from certified and attestable authenticators. - Add a new authenticator flag definition into ctap2.2/2.3 specs to address an optional behavior of ctap2.0 authenticator is weird too. -- GitHub Notification of comment by nuno0529 Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1761#issuecomment-1189787376 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 July 2022 03:47:25 UTC