- From: Akshay Kumar via GitHub <sysbot+gh@w3.org>
- Date: Tue, 20 May 2025 15:08:33 +0000
- To: public-webauthn@w3.org
> @akshayku Ok, but I don't understand what part of this PR would mean more work for any implementations? We are not replacing the old IDs, only adding the new ones to the set of recommended arguments. Adding it to the WebAuthn means that we are endorsing those new algorithms for WebAuthn. Some algorithms just being registered as COSEAlgorithmIdentifier does not necessarily means that it works in WebAuthn across browser/OS/Authenticator. There are many more COSEAlgorithmIdentifier that does not work for WebAuthn. And I think, Realisticly, the current state is that only algorithms mentioned in the webAuthn spec works in reality across the ecosystem. Actually that also is not true across the ecosystem for -8. > > * Current implementations - of authenticators, of clients and of RPs - that only support/request the old IDs will continue to work with the old identifiers. Yes. > * New implementations that support/request both IDs will work with both. Yes, but they don't have to. There is no need, and this is extra work for Authenticators for no benefit. And new code means new potential bugs. And this is again guidance for the authenticators. May be there is some authenticator vendor who has not read all this conversation to only implement newer algorithms. And suddenly their release devices can't be fixed. > * New RP implementations that request only the new IDs will not work with current authenticator implementations that only support the old IDs, so they are incentivized to also request the old IDs. RPs will get it wrong. Let's have one such example. Let's say that these newer Ecdsa algorithms gets supported on certain combination of browser/OS and RP didn't test all the platforms/Browser/OS combination. Just because they only tested major OS/Browser combination. I have seen this happen over the years. Also, we have already established that these new algorithms will not be supported on all authenticators/platforms. So, these RPs will have support costs for these unsupported combination situations down the road. Suddenly there is a situation that existing security keys for example does not work. Is RP staffed to add those? May be someone from RP says it is not the worth given their large population may not have security keys (I have seen this happen too). Then the user who has gone out of its way to buy such security key, will be left stranded. You can add more guidance for the RPs. But even with current guidance, people get it wrong. Unless there was any issue with security/incompatibility/privacy, I don't think we should just add new definitions that can cause those incompatibilities. Again, what is the need to introduce these new algorithms in WebAuthn? Agreed that they are not fully specified yet in COSE registry. But we have already made it clear in our spec about what those algorithms means. > > * Consequently, existing authenticator implementations do not need to update (even in new versions) and can continue supporting only the old IDs if they wish. Provided that RP does the right thing. We shouldn't even open the possibility for RPs to get it wrong, IMO. There is no benefit. For example, if an RP wants ECDSA with ECC P-256 with SHA256, they use -7 today. There is no need to redefine it to something else. > * New authenticator implementations that support only the new IDs will not work with current RP implementations that only request the old IDs, so they are incentivized to also support the old IDs. Again, this is extra work for Authenticator for no benefit. All the cons of these proposals are because of various combinations of browsers/OS/Authenticators. Some are upgradable, some are not. And I don't think this is even a problem. > > * Consequently, existing RP implementations do not need to update (even in new versions) and can continue requesting only the old IDs if they wish. Yes. That is the ideal state. Newer RPs shouldn't be thinking different from existing implementation that just works. We don't know how > > So I agree, we're not going to realistically _eliminate_ the old IDs short of a complete ecosystem-wide migration to PQC/etc. But eliminating the old IDs was never a goal either, so I don't see how that is a problem? > > Note also that the new IDs will be available for RPs to request and for authenticators to implement _regardless_ of whether we make any change to WebAuthn. The `COSEAlgorithmIdentifier`s are registered, and WebAuthn L1 and L2 allow any `COSEAlgorithmIdentifier` to be used. WebAuthn L3 will too unless we explicitly forbid these specific values ([which would in my opinion be worse](https://github.com/w3c/webauthn/pull/2283#discussion_r2079594682)). All this PR does is inform RPs of this new reality: that for maximum compatibility they should request both the old and new IDs (well ok, it does also carry the format restriction on from `ES*` to `ESP*`, but that is not what introduces the new alg IDs). Overall, there is no benefit of adding these new algorithms for existing algorithms defined in WebAuthn spec. -- GitHub Notification of comment by akshayku Please view or discuss this issue at https://github.com/w3c/webauthn/pull/2283#issuecomment-2894782206 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 20 May 2025 15:08:34 UTC