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

I share some of Akshay's deployment concerns.

The RP sends an ordered list of alg ID in preference order.  Including the
new, more specific algID as well should not break any authenticators, they
have always needed to deal with RSA and possibly other unknown algID.

The authenticators can add the new ones without any trouble.

The problem will come down to RP education.

If they see a new algID for P256 and change to it, dropping the original
algID from the list, they will break in an obvious way.
Other algs like P384 may not be so obvious.

I know Chrome has or is fixing up some RP requests by tacking on P256 to
the end if the RP leaves it out.  I don't think we want the platforms to
have to do that sort of mapping.

I think we should be conservative about telling WebAuthn RP to change
algID, and rather encourage them to just use the new ones where applicable.

I think Win 10 has an alg allow list that will not change at this point, so
no matter what gets added to the authenticator, the new ones won't work.

Let's just not encourage RP to break things un neccicarrily.

I suspect we can have Fido communicate with the server vendors, as well.
 In reality, I don't know how many RP tweek these low-level settings.

John B

On Mon, May 19, 2025 at 9:09 AM Akshay Kumar via GitHub <sysbot+gh@w3.org>
wrote:

> > If I understand correctly, the existing webauthn behavior is that in
> cases where an algorithm worked with multiple curves, webauthn chose a
> curve, and does not support all the curves for that algorithm, is that
> correct?
>
> Yes
>
> > Just for my own clarity are there any hardware devices out there that
> use -7 with a curve other than P-256?
>
> No. AFAIK from over the years.
>
> > In other words, does webauthn make use of the "feature" that -7 works
> with P-384 and P-521, or does it just ignore that possibility, and assume
> that -7 is always with P-256? (and my webauthn, I really mean devices that
> can't be updated, as opposed to the spec itself)
>
> We always assume that -7 is ECDSA with P-256. Similarly with others (-8,
> -35, -36). We have put below descriptions in the spec.
>
> > Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [crv](
> https://tools.ietf.org/html/rfc9053#name-double-coordinate-curves)
> parameter and MUST NOT use the compressed point form.
>
> >Keys with algorithm ES384 (-35) MUST specify P-384 (2) as the [crv](
> https://tools.ietf.org/html/rfc9053#name-double-coordinate-curves)
> parameter and MUST NOT use the compressed point form.
>
> >Keys with algorithm ES512 (-36) MUST specify P-521 (3) as the [crv](
> https://tools.ietf.org/html/rfc9053#name-double-coordinate-curves)
> parameter and MUST NOT use the compressed point form.
>
> >Keys with algorithm EdDSA (-8) MUST specify Ed25519 (6) as the [crv](
> https://tools.ietf.org/html/rfc9053#name-double-coordinate-curves)
> parameter. (These always use a compressed form in COSE.)
>
> --
> GitHub Notification of comment by akshayku
> Please view or discuss this issue at
> https://github.com/w3c/webauthn/pull/2283#issuecomment-2891567189 using
> your GitHub account
>
>
> --
> Sent via github-notify-ml as configured in
> https://github.com/w3c/github-notify-ml-config
>
>