- From: philomathic_life via GitHub <noreply@w3.org>
- Date: Mon, 02 Jun 2025 18:11:09 +0000
- To: public-webauthn@w3.org
> If the maximum length was a recommendation then this can pose a challenge for server implementations that use predefined db schemas. Just saying … there are stakeholders other than authenticator vendors that care about this kind of detail. This could include browsers (clients) as well. Those vendors already don't support the corresponding algorithms at least indirectly. For example, if a vendor feigns support for server-side RSA keys; they actually don't for large-enough keys since the corresponding credential ID would be too large. It's just bizarre behavior that perhaps is "too late" to fix. If an authenticator supports both client-side and server-side credentials, an RP discourages the creation of a "resident key", and only wants an RSA key; the authenticator will have no choice but to error by treating the resident key discouragement as a requirement, or go against the wishes of the RP and store the key on the client just because the credential ID length has this maximum length requirement. Just because some RPs have chosen to not support larger credential IDs seems unfortunate that in perpetuity newer keys will not be supported server-side. If a post-quantum signature with cryptographic strengths is created that doesn't have the property of ML-DSA where a private key can be re-created from a smaller "seed", why must it be impossible for all RPs to not support it? RPs that choose to not support larger credential IDs could simply not support such algorithms or only support such algorithms for client-side credentials. -- GitHub Notification of comment by zacknewman Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2299#issuecomment-2931878273 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 2 June 2025 18:11:10 UTC