- From: My1 via GitHub <sysbot+gh@w3.org>
- Date: Tue, 10 Jan 2023 15:37:21 +0000
- To: public-webauthn@w3.org
The problem tho is that the problem in the first place is ctap2.0 and that those devices generally cannot be updated, unlike webauthn which is comparatively easy to update as that's just a thing generally in software on the client Emil Lundberg ***@***.***> schrieb am Di., 10. Jan. 2023, 16:27: > 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*. > > 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. > > — > Reply to this email directly, view it on GitHub > <https://github.com/w3c/webauthn/issues/1822#issuecomment-1377443100>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABTC4TCOVX2UX7QCMZQ46RTWRV5WDANCNFSM6AAAAAAR3JMUE4> > . > You are receiving this because you commented.Message ID: > ***@***.***> > -- GitHub Notification of comment by My1 Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1822#issuecomment-1377456977 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 10 January 2023 15:37:23 UTC