- From: Firstyear via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Jan 2023 01:27:50 +0000
- To: public-webauthn@w3.org
> As I recall, the consensus last time we discussed this on the WG call was that `residentKey: "preferred"` should continue to work as it currently does when storage capacity is not a concern, but it's reasonable to recommend client implementations to be less generous when it is - for CTAP2.0 devices in particular. > > But that's also why we decided no change is needed in WebAuthn - it's specifically a CTAP2.0 concern, which is beyond the WebAuthn authenticator model and should be handled in CTAP specs/guidelines instead. As is, WebAuthn doesn't even have a concept of authenticator storage _capacity_, only a binary storage _capability_. It's CTAP2.1 as well. CTAP2.0 is especially bad due to the fact you can't delete a key once created, but CTAP2.1 still has many devices with extremely limited capacity available. Webauthn also isn't an abstraction above these concepts either - it's the glue that binds many things together, and in a way must be a leaky-abstraction. It's for webauthn to say "hey when you are an RP you need to consider this abstraction has X, Y, Z properties". One of those properties in this case *is* that binary storage is *limited* rather than just a boolean of "unlimited" or "none at all". > > I'm a bit torn on whether WebAuthn _should_ have such a concept, but I'm still leaning toward calling this out of scope. These are vendor-specific implementation concerns, we shouldn't clutter WebAuthn with them. Well, the issue is people will look to the Webauthn spec for guidance and they won't find it, then they'll search other places and a lot of the "hype" around passkeys will push people to rk=required which will alienate CTAP2.0 and CTAP2.1 users. Again, the WG has made a point many times that users should be free to use any authenticator they want, and if RP's choose rk=required/preferred this will prevent that because the extremely limited space will be consumed rapidly as RP's roll out things based on this advice. So I think as a WG it is our responsibility to encourage our community to consider the diverse range of devices webauthn can support. We already have "leaky abstraction" here with the definition of vendor-specific attestation types, so having a "leaky abstraction" that details how rk=discouraged/preferred/required should behave both with browsers *and* with authenticators would be in line with other things in the spec. Subsequently it would be good then if we were able to then proactively encourage the use of rk settings that will work in all cases with out consuming a finite resource on client devices. -- GitHub Notification of comment by Firstyear Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1822#issuecomment-1378121243 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 January 2023 01:27:52 UTC