Re: [webauthn] Use fully-specified COSEAlgorithmIdentifiers in examples and recommendations (#2283)

@akshayku 

> [...] 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. [...]

I was about to say there is no change in guidance for authenticators here, but on second thought I guess the changes to [ยง6.5.1.1. Examples of credentialPublicKey Values Encoded in COSE_Key Format](https://pr-preview.s3.amazonaws.com/w3c/webauthn/pull/2283.html#sctn-encoded-credPubKey-examples) do qualify, as do the new/updated test vectors. Good point!

> Again, what is the need to introduce these new algorithms in WebAuthn? [...]

Without it, authenticators that choose to implement support for ESP256 (-9) would be free to emit ESP256 COSE keys in compressed format since that is not forbidden for ESP256. Would that be a problem? RPs likely won't expect the compressed format and would have to update their code to support those authenticators that use the compressed format.

On the other hand I argued earlier that some incompatibility should be expected with new features, so maybe that's fine. Honestly I _would_ prefer to drop the restriction against compressed format for `ESP*`, I just figured we would cause fewer problems (i.e., less work for RPs) continuing that restriction for `ESP*` than we would by having it for `ES*` but not for `ESP*`.


@zacknewman 

> Another way to view this is now with these new IDs there are two equivalent IDs, from the perspective of WebAuthn, so we arbitrarily pick one (i.e., the legacy ID) to recommend.

No, not either one - we should _always_ recommend the legacy ID, the only question is whether we should _also_ recommend the new one. I believe there is no harm in recommending the new ID _and_ the old ID, and little or no harm in continuing to recommend only the old ID, but there certainly is harm in recommending the new ID _instead of_ the old ID.

So okay, I guess "little or no harm in continuing to recommend only the old ID" may be a signal that we should do just that.


> [...] about `getPublicKey`. Currently user agents are _required_ to return SPKI data from that function when the corresponding ID is EdDSA, ES256, or RS256. Presumably we add that user agents are required to support the new IDs as well?

We're not adding that requirement in L3. `getPublicKey()` is still required to support EdDSA (-8), ES256 (-7) and RS256 (-257), but is _not_ required to support Ed25519 (-19) or ESP256 (-9). Ed25519 (-19) and ESP256 (-9) should be "supported" in `pubKeyCredParams` just like they are today - in that the client doesn't throw an exception if you pass `pubKeyCredParams: [{ alg: -9, type: "public-key" }]`), but not necessarily in `getPublicKey()`. This is what's defined in the current L3 draft (without this PR) and I do not intend to change that in L3 (nor necessarily in L4+ if there are objections to it).

---

Okay, I've been convinced that we should at least reduce the scope of this change to keep the old IDs the "preferred" ones in examples and test vectors. I've updated the PR with that (I also changed the Ed25519 test vector to use the seed `'packed.EdDSA'` instead of `'packed.Ed25519'` since it is using the COSE identifier `EdDSA` (-8), in case we add an `Ed25519` (-19) test vector in the future).

I could go either way on recommending that RPs request the new IDs (_in addition_ to the respective old ones) in `pubKeyCredParams`. I've kept it in the PR for now. I think we should at the very least have some note saying if an RP requests one of the new IDs they really SHOULD also request the old one.

For now I've also kept the restriction against compressed form for `ESP*` public keys, but I'm happy to drop that too if we think it's a good idea for both compressed and uncompressed formats to coexist (but only with the new `ESP*` IDs, not with the old `ES*` IDs).

-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/2283#issuecomment-2895474947 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 18:47:20 UTC