AGL is correct the spec never specified backwards comparability for a discoverable credential to work over CTAP1 only CTAP1 credentials working over CTAP2. In practice because of Firefox and Android every one made non discoverable credentials work over CTAP1 assuming the RPID is correct. I think non discoverable was discussed but no one saw any value in it as Microsoft was the only one using discoverable and that required UV. Perhaps it was an oversight in the CTAP2.0 spec, but it is water under the bridge at this point. Yubikeys don’t support discoverable over CTAP1. Other authenticators might, but it was never tested as part of any conformance. So yes if an authenticator supported discoverable over CTAP1 and applied cred protect logic to those credentials then the L3 ones should not work. However that is a bit of an edge case. If a RP wants to continue using an allow list and specifying uv discouraged in get assertion, then they should make the credentials with uv discouraged and perhaps explicitly set credprotect L2. I don’t think this really breaks anything in practice. RP can however will need to set uv discouraged on make if they set it on get. John B. On Fri, Mar 10, 2023 at 11:45 AM Adam Langley <agl@google.com> wrote: > On Fri, Mar 10, 2023 at 2:53 AM DUBOUCHER Thomas < > thomas.duboucher@thalesgroup.com> wrote: > >> I have one important functional issue with 2. : Android still doesn’t >> support UV on security keys. So if I understand correctly the interactions, >> it means that credentials created on Chrome won’t be usable on Android. >> Until Android is updated, of course. >> > > Is this not already the case for discoverable credentials? I.e. if you > create a discoverable credential on, say, a Yubikey, it can't be exercised > over U2F I believe. So it's already inaccessible from Android. > > > Cheers > > AGL >
Received on Friday, 10 March 2023 15:10:49 UTC