Repository: w3c/webauthn
Pull request #2283: Account for new fully-specified ECDSA and Ed448 COSEAlgorithmIdentifiers
Author: login: emlun
Labels: name: type:technical
Created: 2025-04-25T14:33:09Z | Merged: 2025-05-22T15:40:55Z

Fixes #2282.

This: 

- Adds a normative recommendation against using the identifiers -9 (ESP256), -51 (ESP384), -52 (ESP512) and -19 (Ed25519), recommending to continue using -7 (ES256), -35 (ES384), -36 (ES512) and -8 (EdDSA) instead.
- Carries forward the restriction against compressed point format from the `ES*` algorithms to the new `ESP*` algorithms.
- Adds Ed448 test vectors.
- Changes the -8 (EdDSA) test vectors to using the seed `'packed.EdDSA'` and link anchor `#sctn-test-vectors-packed-eddsa` instead of `'packed.Ed25519'` and `#sctn-test-vectors-packed-ed25519`, in case we want to add test vectors with COSE alg -19 (Ed25519) in the future.


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://pr-preview.s3.amazonaws.com/w3c/webauthn/pull/2283.html" title="Last updated on May 22, 2025, 3:40 PM UTC (472e8d0)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/webauthn/2283/86e50a9...472e8d0.html" title="Last updated on May 22, 2025, 3:40 PM UTC (472e8d0)">Diff</a>

Linked issue #2282: Update COSEAlgorithmIdentifier examples and recommendations to prefer fully-specified alg IDs
This is broken out from issue #2276:

## Proposed Changes for WebAuthn L3

~~Update non-normative examples, and update recommendations for RP to prefer the new values. These are not yet implemented by clients and authenticators, but will gracefully fall back to the legacy values until implemented.~~

- ~~[§1.3.1. Registration](https://w3c.github.io/webauthn/#sctn-sample-registration): change example from using -7 (ES256) to -9 (ESP256) and from -8 (EdDSA) to -50 (Ed25519)~~

- ~~[`pubKeyCredParams`](https://w3c.github.io/webauthn/#dom-publickeycredentialcreationoptions-pubkeycredparams): update algoritms recommended to RPS:~~

  >[Relying Parties](https://w3c.github.io/webauthn/#relying-party) that wish to support a wide range of [authenticators](https://w3c.github.io/webauthn/#authenticator) SHOULD include at least the following [COSEAlgorithmIdentifier](https://w3c.github.io/webauthn/#typedefdef-cosealgorithmidentifier) values:
  >
  >- -8 (Ed25519)
  >- -7 (ES256)
  >- -257 (RS256)
  >
  >Additional signature algorithms can be included as needed.

- ~~[§5.8.5. Cryptographic Algorithm Identifier (typedef `COSEAlgorithmIdentifier`)](https://w3c.github.io/webauthn/#sctn-alg-identifier): update examples:~~
  >A [COSEAlgorithmIdentifier](https://w3c.github.io/webauthn/#typedefdef-cosealgorithmidentifier)’s value is a number identifying a cryptographic algorithm. The algorithm identifiers SHOULD be values registered in the IANA COSE Algorithms registry [[IANA-COSE-ALGS-REG]](https://w3c.github.io/webauthn/#biblio-iana-cose-algs-reg), for instance, -7 for "ES256" and -257 for "RS256".

- ~~[§6.5.1.1. Examples of credentialPublicKey Values Encoded in COSE_Key Format](https://w3c.github.io/webauthn/#sctn-encoded-credPubKey-examples): add example(s) using fully-specified ID(s)~~

- ~~[§6.5.5. Signature Formats for Packed Attestation, FIDO U2F Attestation, and Assertion Signatures](https://w3c.github.io/webauthn/#sctn-signature-attestation-types): add -9 (ESP256) in addition to -7 (ES256)~~
Linked issue comments: user: login: emlun
created_at: 2025-05-22T15:43:12Z
body: We decided in the discussion in and around #2283 to not do most of this as originally outlined in the initial post, instead recommending against using the new identifiers (except `Ed448`) and in favour of continuing to use the old identifiers instead.
author_association: MEMBER

Diff:
diff --git a/index.bs b/index.bs
index 4c8c73979..e26bd66b4 100644
--- a/index.bs
+++ b/index.bs
@@ -3485,6 +3485,22 @@ optionally evidence of [=user consent=] to a specific transaction.
 
         Additional signature algorithms can be included as needed.
 
+        The following {{COSEAlgorithmIdentifier}} values are NOT RECOMMENDED
+        in {{PublicKeyCredentialCreationOptions/pubKeyCredParams}}:
+
+        * -9 (ESP256); use ES256 (-7) instead or in addition.
+        * -51 (ESP384); use ES384 (-35) instead or in addition.
+        * -52 (ESP512); use ES512 (-36) instead or in addition.
+        * -19 (Ed25519); use EdDSA (-8) instead or in addition.
+
+        Note: Within WebAuthn, the values -9 (ESP256), -51 (ESP384), -52 (ESP512) and -19 (Ed25519)
+        represent the same thing respectively as -7 (ES256), -35 (ES384), -36 (ES512) and -8 (EdDSA)
+        because of the additional restrictions stated in [[#sctn-alg-identifier]].
+        However, they are not interchangeable in practice
+        since many implementations support the latter identifiers but not the former ones.
+        Therefore the latter identifiers are preferred in {{PublicKeyCredentialCreationOptions/pubKeyCredParams}}
+        for backwards compatibility.
+
     :   <dfn>timeout</dfn>
     ::  This OPTIONAL member specifies a time, in milliseconds, that the [=[RP]=] is willing to wait for the call to complete. This is
         treated as a hint, and MAY be overridden by the [=client=].
@@ -4326,8 +4342,11 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
 
     The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a [=COSE key=]. In order to promote interoperability, this specification makes the following additional guarantees of [=credential public keys=]:
         1. Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP256 (-9) MUST NOT use the compressed point form.
         1. Keys with algorithm ES384 (-35) MUST specify P-384 (2) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP384 (-51) MUST NOT use the compressed point form.
         1. Keys with algorithm ES512 (-36) MUST specify P-521 (3) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP512 (-52) MUST NOT use the compressed point form.
         1. Keys with algorithm EdDSA (-8) MUST specify Ed25519 (6) as the [=crv=] parameter. (These always use a compressed form in COSE.)
 
     These restrictions align with the recommendation in [=Section 2.1=] of [[!RFC9053]].
@@ -9456,39 +9475,76 @@ signature = h'01063d52d7c39b4d432fc7063c5d93e582bdcb16889cd71f888d67d880ea730a42
 </xmp>
 
 
-## Packed Attestation with Ed25519 Credential ## {#sctn-test-vectors-packed-ed25519}
+## Packed Attestation with Ed25519 Credential ## {#sctn-test-vectors-packed-eddsa}
 
 [=registration ceremony|Registration=]:
 <xmp class="example" highlight="cddl">
-challenge = h'560c73a09ce7a1586d61c1d6e41fef149be523e220fc9f385d38ab23702ebf1b'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='packed.Ed25519', L=32)
+challenge = h'a8abf9dabdc6b0df63466b39bda9e8a34a34e185337a59f1c579990676d3b3bd'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='packed.EdDSA', L=32)
 
-private_key = h'c87fce9e9cd283d272a2418d9683366f83661e458ad4451f0f1c95cb83b0f0a8'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='packed.Ed25519', L=32)
-client_data_gen_flags = h'41'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='packed.Ed25519', L=1)
+private_key = h'971f38c0f73aaf0c5a614eb5e26430ae1ea0ed13e4f425d96e9662349340b0b3'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='packed.EdDSA', L=32)
+client_data_gen_flags = h'bd'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='packed.EdDSA', L=1)
 ; extra_client_data is included iff bit 0x01 of client_data_gen_flags is 1
-extra_client_data = h'db7587e24b9187edb77933754331e443'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='packed.Ed25519', L=16)
-aaguid = h'164009ea09faae7c397bc3e2ad0e7ec0'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='packed.Ed25519', L=16)
-credential_id = h'c6cffa01b7fda368a7e0b29c1384a719820246bca894dd12914708743af0cecd'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='packed.Ed25519', L=32)
+extra_client_data = h'07f0d3e60ed90fffbd3932d85f922f11'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='packed.EdDSA', L=16)
+aaguid = h'd5aa33581e8ca478e20fe713f5d32ff2'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='packed.EdDSA', L=16)
+credential_id = h'ce9f840ed96599580cd140fbc7bb3230633f50f61041aff73308ae71caa8a2bd'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='packed.EdDSA', L=32)
 ; auth_data_UV_BE_BS determines the UV, BE and BS bits of the authenticator data flags, but BS is set only if BE is
-auth_data_UV_BE_BS = h'e8'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='packed.Ed25519', L=1)
-attestation_private_key = h'673ee7fd94405de523fd84a088ab082d75b7fceef02a301e2bca0a28537cf243'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='packed.Ed25519', L=32)
-attestation_cert_serial_number = h'6e391f23f57150dc7a12dad18f2b43ad'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='packed.Ed25519', L=16)
+auth_data_UV_BE_BS = h'32'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='packed.EdDSA', L=1)
+attestation_private_key = h'fbe7f950684f23afd045072a8b287ad29528707c662672850ac69733ffe0db85'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='packed.EdDSA', L=32)
+attestation_cert_serial_number = h'b2cfc9ea33c8643b0e1a760463eaf164'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='packed.EdDSA', L=16)
 
-clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a225667787a6f4a7a6e6f5668745963485735425f76464a766c492d49675f4a38345854697249334175767873222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a2032335748346b7552682d323365544e31517a486b51773d3d227d'
-attestationObject = h'a363666d74667061636b65646761747453746d74a363616c672663736967584730450220730a54d4f76cb1f2b7dd4a5a6eee3374e3c8a60fb3c4daa527c9277e365b64aa0221008b31a04a28cc4148b14c42a916548ee7f430bc7629295b42ee93e5d1aaba8ee6637835638159022530820221308201c7a00302010202106e391f23f57150dc7a12dad18f2b43ad300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d03010703420004fb96a581a0b36742a8c45d6ffb5af1ef155524b50339445ec1109874045e0087db77edef91f3dc949927470d84b01627087b72c86b7c9d02e1389cba680ffc36a360305e300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e04160414ef2ce1a86caba85121130a16e8ce82a75d5a6653301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e300a06082a8648ce3d0403020348003045022100ad4fa628cffba5a642a562cbfefe63efecce26d90c80114114d1745383e12f01022028af87ba3b0ff868a34b9458bc6973b27380a328dd87b7436651ffa823280bca6861757468446174615881bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b54900000000164009ea09faae7c397bc3e2ad0e7ec00020c6cffa01b7fda368a7e0b29c1384a719820246bca894dd12914708743af0cecda401010327200621582089f81eba4a1f510cb243ff7fb9e9cf899bf627e49ce1ac3c3eae8adb2a8d7d7b'
+clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a22714b763532723347734e396a526d733576616e6f6f306f303459557a656c6e7878586d5a426e6254733730222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a20425f44543567375a445f2d394f544c595835497645513d3d227d'
+attestationObject = h'a363666d74667061636b65646761747453746d74a363616c67266373696758473045022100adecf9cace851c8bf4adb6b9e9dff8ddfa43092bbe04b5814cdf1c744970a88f02201c1bd55aacdfe2e4442c886132148b80394567018a382ce1fa260adae41e0746637835638159022730820223308201c8a003020102021100b2cfc9ea33c8643b0e1a760463eaf164300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d03010703420004dd2b7a564b73b8c0b81c4c62e521925c4d1198ec9f583dbf1eebe364b65cd9c29a9bdf346aaa81fb6b9507e5249a52fdaf8e39e26b0b7dc45992a7e233b70f70a360305e300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e041604140ae27546bc7eccb1b4b597bd354f0c0b1f1f8f8e301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e300a06082a8648ce3d0403020349003046022100a0d434ecb5fc3bfd7da5f41904517ad2836249f561bd834ba7a438a8ab7a4ce8022100fac845bb7a02513b58e9f319654dbe49b0f02b95835bac568c71f8a18cdde9ab6861757468446174615881bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b54100000000d5aa33581e8ca478e20fe713f5d32ff20020ce9f840ed96599580cd140fbc7bb3230633f50f61041aff73308ae71caa8a2bda401010327200621582044e06ddd331c36a8dc667bab52bcae63486c916aa5e339e6acebaa84934bf832'
 </xmp>
 
 [=authentication ceremony|Authentication=]:
 <xmp class="example" highlight="cddl">
-challenge = h'3790da8b2b72ee8ce19761787ad38cbfaa697eb3ca013a1342988756b98785ab'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='packed.Ed25519', L=32)
+challenge = h'895957e01c633a698348a2d8a31a54b7db27e8c1c43b2080d79ae2190267bfd2'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='packed.EdDSA', L=32)
 
-client_data_gen_flags = h'de'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='packed.Ed25519', L=1)
+client_data_gen_flags = h'8c'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='packed.EdDSA', L=1)
 ; extra_client_data is included iff bit 0x01 of client_data_gen_flags is 1
 ; auth_data_UV_BS sets the UV and BS bits of the authenticator data flags, but BS is set only if BE was set in the registration
-auth_data_UV_BS = h'18'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0b', info='packed.Ed25519', L=1)
+auth_data_UV_BS = h'ab'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0b', info='packed.EdDSA', L=1)
 
-authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b51900000000'
-clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a224e35446169797479376f7a686c32463465744f4d763670706672504b41546f545170694856726d48686173222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
-signature = h'4c873571377ac019f257d6bf07249f63ac2487483c51bc511ce0f0e3266c840cb07a09cdc445a2f963d8603a9f0f6cf9ce709d7fc6a96c7c51ea08d33776010c'
+authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b50100000000'
+clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a2269566c583442786a4f6d6d44534b4c596f7870557439736e364d48454f7943413135726947514a6e763949222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73657d'
+signature = h'f5c59c7e46c34f6f8cc197101ddf9934fa2595f68eb1913a637e8419eb9ba4cfdfc48f85393bc0d40b011f0d6fecb097d6607525713223a0dc0d453993dae00b'
+</xmp>
+
+
+## Packed Attestation with Ed448 Credential ## {#sctn-test-vectors-packed-ed448}
+
+[=registration ceremony|Registration=]:
+<xmp class="example" highlight="cddl">
+challenge = h'2578d0801b5a005b5451e540121788cb01949e187b91db13f58755403efbf337'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'00', info='packed.Ed448', L=32)
+
+private_key = h'ed479eecf63bd89e3898434798bb3c417bfc8284f6f011958bc0e78edbf6a2a640c0e358b1b1452a1f3782c400dabb4134192dee3031869a45'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'01', info='packed.Ed448', L=57)
+client_data_gen_flags = h'e3'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'02', info='packed.Ed448', L=1)
+; extra_client_data is included iff bit 0x01 of client_data_gen_flags is 1
+extra_client_data = h'050a80de27875521cc4c3316c06da42b'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'03', info='packed.Ed448', L=16)
+aaguid = h'41c913aeda925fe02273322e34c2ae67'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'04', info='packed.Ed448', L=16)
+credential_id = h'224fcde324e6b075ede55098a24b9ddce5f5a7c71d23703efd528a38f8a5f33c'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'05', info='packed.Ed448', L=32)
+; auth_data_UV_BE_BS determines the UV, BE and BS bits of the authenticator data flags, but BS is set only if BE is
+auth_data_UV_BE_BS = h'3b'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'06', info='packed.Ed448', L=1)
+attestation_private_key = h'd90faf5cc3f7853456b09124dd870250347f9c9ff66dba363aecd9194c665715'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'07', info='packed.Ed448', L=32)
+attestation_cert_serial_number = h'cff4228697d6e5ac47480b2390677f05'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'08', info='packed.Ed448', L=16)
+
+clientDataJSON = h'7b2274797065223a22776562617574686e2e637265617465222c226368616c6c656e6765223a224a586a5167427461414674555565564145686549797747556e6868376b6473543959645651443737387a63222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a2042517141336965485653484d54444d577747326b4b773d3d227d'
+attestationObject = h'a363666d74667061636b65646761747453746d74a363616c672663736967584730450220315c861030a51b01a3294e11acfeb83ffc2155971e9fb4ab566a25ce6a9e22c50221009fdd06e22c8628071913d176c9e52bf5ff4ab253a76a1aef0c831db4dc8791a1637835638159022730820223308201c8a003020102021100cff4228697d6e5ac47480b2390677f05300a06082a8648ce3d0403023062311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331253023060355040b0c1c41757468656e74696361746f72204174746573746174696f6e204341310b30090603550406130241413020170d3234303130313030303030305a180f33303234303130313030303030305a305f311e301c06035504030c15576562417574686e207465737420766563746f7273310c300a060355040a0c0357334331223020060355040b0c1941757468656e74696361746f72204174746573746174696f6e310b30090603550406130241413059301306072a8648ce3d020106082a8648ce3d03010703420004b85aaf790c824037cfe9fc56ab8d7ce6fbfaff2e3fe7c8d745734c3c6e3c6ce880d505ccdb1e2c3738680e6f49f475e4d8d0b6c29060e6e0d7a6392fb69094cea360305e300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e04160414fa8f81c2dcc0e194ae5034c7e79dcf6d9d8593e2301f0603551d2304183016801445aff715b0dd786741fee996ebc16547a3931b1e300a06082a8648ce3d0403020349003046022100e761f54215ad92f27c2c14b9eea3e39e8c22429e833ecba5be918987aa72e0e6022100d5a714df479c238586b7d9e6684ea84991087038b0fef6a29b57b66b74df05fd686175746844617461589bbfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b5590000000041c913aeda925fe02273322e34c2ae670020224fcde324e6b075ede55098a24b9ddce5f5a7c71d23703efd528a38f8a5f33ca4010103383420072158398051ef4f94670b5abf17da2e9558ba6eba94eb8704363915b4d666de287ad329de9f1f075211aba602dc6e7a5e52b15a8ee1c984a9f8887380'
+</xmp>
+
+[=authentication ceremony|Authentication=]:
+<xmp class="example" highlight="cddl">
+challenge = h'1a942f401d8d8e36fe888c35c22b718217802fc6685bf139c47b311408128693'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'09', info='packed.Ed448', L=32)
+
+client_data_gen_flags = h'2d'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0a', info='packed.Ed448', L=1)
+; extra_client_data is included iff bit 0x01 of client_data_gen_flags is 1
+extra_client_data = h'5ca1e381b5e009e01760db2eb632316f'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0b', info='packed.Ed448', L=16)
+; auth_data_UV_BS sets the UV and BS bits of the authenticator data flags, but BS is set only if BE was set in the registration
+auth_data_UV_BS = h'fc'   ; Derived by: HKDF-SHA-256(IKM='WebAuthn test vectors', salt=h'0c', info='packed.Ed448', L=1)
+
+authenticatorData = h'bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b51d00000000'
+clientDataJSON = h'7b2274797065223a22776562617574686e2e676574222c226368616c6c656e6765223a22477051765142324e6a6a622d6949773177697478676865414c385a6f575f4535784873784641675368704d222c226f726967696e223a2268747470733a2f2f6578616d706c652e6f7267222c2263726f73734f726967696e223a66616c73652c22657874726144617461223a22636c69656e74446174614a534f4e206d617920626520657874656e6465642077697468206164646974696f6e616c206669656c647320696e20746865206675747572652c207375636820617320746869733a20584b486a6762586743654158594e7375746a497862773d3d227d'
+signature = h'971c13fc11f64857ee2b2754b36430397104fa1f68abe103c57a815047c80916e340c9c031b3e7f0b2dbbb31e4de0234e19c273e3532f2fd8072c97e5361a2fe0a7100ab7ea55881b140253312001251088e18b97462173c5e1bb1c6d93cbddbe580b8f32b36d33410f64d89268cc3303b00'
 </xmp>
 
 
diff --git a/test-vectors/poetry.lock b/test-vectors/poetry.lock
index b153b2310..19df0118d 100644
--- a/test-vectors/poetry.lock
+++ b/test-vectors/poetry.lock
@@ -170,18 +170,18 @@ files = [
 
 [[package]]
 name = "fido2"
-version = "1.2.0"
+version = "2.0.0"
 description = "FIDO2/WebAuthn library for implementing clients and servers."
 optional = false
-python-versions = "<4.0,>=3.8"
+python-versions = "<4,>=3.10"
 groups = ["main"]
 files = [
-    {file = "fido2-1.2.0-py3-none-any.whl", hash = "sha256:f7c8ee62e359aa980a45773f9493965bb29ede1b237a9218169dbfe60c80e130"},
-    {file = "fido2-1.2.0.tar.gz", hash = "sha256:e39f95920122d64283fda5e5581d95a206e704fa42846bfa4662f86aa0d3333b"},
+    {file = "fido2-2.0.0-py3-none-any.whl", hash = "sha256:685f54a50a57e019c6156e2dd699802a603e3abf70bab334f26affdd4fb8d4f7"},
+    {file = "fido2-2.0.0.tar.gz", hash = "sha256:3061cd05e73b3a0ef6afc3b803d57c826aa2d6a9732d16abd7277361f58e7964"},
 ]
 
 [package.dependencies]
-cryptography = ">=2.6,<35 || >35,<45"
+cryptography = ">=2.6,<35 || >35,<48"
 
 [package.extras]
 pcsc = ["pyscard (>=1.9,<3)"]
@@ -202,4 +202,4 @@ files = [
 [metadata]
 lock-version = "2.1"
 python-versions = ">=3.10, <4"
-content-hash = "b894169eaec60dc69b076e545d4579839b013e71518e73e18bb87105194e751e"
+content-hash = "82c384fbe6fc3e748cd706aece5157bf0b1de9eaae6e29058a874dc18d8c6b0b"
diff --git a/test-vectors/pyproject.toml b/test-vectors/pyproject.toml
index 796ee38bd..a78d80929 100644
--- a/test-vectors/pyproject.toml
+++ b/test-vectors/pyproject.toml
@@ -9,7 +9,7 @@ package-mode = false
 [tool.poetry.dependencies]
 asn1 = "^3.0.1"
 cryptography = "^44.0.3"
-fido2 = "^1.2.0"
+fido2 = "^2.0.0"
 
 [build-system]
 requires = ["poetry-core>=2.0"]
diff --git a/test-vectors/webauthn-test-vectors.py b/test-vectors/webauthn-test-vectors.py
index 7431dcfe5..2c67f55e8 100644
--- a/test-vectors/webauthn-test-vectors.py
+++ b/test-vectors/webauthn-test-vectors.py
@@ -6,7 +6,7 @@
 from cryptography import x509
 from cryptography.hazmat.backends import default_backend
 from cryptography.hazmat.primitives import hashes, serialization
-from cryptography.hazmat.primitives.asymmetric import ec, ed25519, padding, rsa
+from cryptography.hazmat.primitives.asymmetric import ec, ed25519, ed448, padding, rsa
 from cryptography.hazmat.primitives.kdf.hkdf import HKDF
 from cryptography.x509.oid import NameOID
 
@@ -403,7 +403,7 @@ def gen_packed_self_attestation(gen_rand, challenge, credential_id_length, priva
     auth_data = gen_attestation_auth_data(gen_rand, RP_ID_HASH, 0x41, 0, att_cred_data, None)
 
     att_obj = AttestationObject.create("packed", auth_data, {
-        "alg": -7,
+        "alg": public_key.ALGORITHM,
         "sig": private_key.sign(auth_data + sha256(client_data), ec.ECDSA(hashes.SHA256(), deterministic_signing=True)),
     })
 
@@ -430,7 +430,7 @@ def gen_packed_attestation(gen_rand, challenge, credential_id_length, public_key
 
     att_cert, att_key = gen_att_cert(att_ca_cert, att_ca_key, gen_rand)
     att_obj = AttestationObject.create("packed", auth_data, {
-        "alg": -7,
+        "alg": cose.ES256.ALGORITHM,
         "sig": att_key.sign(auth_data + sha256(client_data), ec.ECDSA(hashes.SHA256(), deterministic_signing=True)),
         "x5c": [att_cert.public_bytes(serialization.Encoding.DER)]
     })
@@ -501,7 +501,7 @@ def gen_tpm_attestation_statement(gen_rand, auth_data: AuthenticatorData, client
     sig = att_key.sign(cert_info, ec.ECDSA(hashes.SHA256(), deterministic_signing=True))
     return {
         "ver": "2.0",
-        "alg": -7,
+        "alg": cose.ES256.ALGORITHM,
         "x5c": [att_cert.public_bytes(serialization.Encoding.DER)],
         "sig": sig,
         "certInfo": cert_info,
@@ -535,7 +535,7 @@ def gen_android_key_attestation(gen_rand, challenge, credential_id_length, priva
 
     att_cert, att_key = gen_android_key_att_cert(att_ca_cert, att_ca_key, sha256(client_data), private_key, gen_rand)
     att_obj = AttestationObject.create("android-key", auth_data, {
-        "alg": -7,
+        "alg": cose.ES256.ALGORITHM,
         "sig": att_key.sign(auth_data + sha256(client_data), ec.ECDSA(hashes.SHA256(), deterministic_signing=True)),
         "x5c": [att_cert.public_bytes(serialization.Encoding.DER)]
     })
@@ -792,6 +792,8 @@ def test_vectors_packed_eddsa(
         description,
         info,
         cose_class,
+        cryptography_prikey_class,
+        private_key_length,
         credential_id_length=32,
         challenge_length=32,
 ):
@@ -806,7 +808,7 @@ def test_vectors_packed_eddsa(
     challenge = next_prand(gen_rand, "challenge", challenge_length)
     print()
 
-    pri_key = ed25519.Ed25519PrivateKey.from_private_bytes(next_prand(gen_rand, "private_key", 32))
+    pri_key = cryptography_prikey_class.from_private_bytes(next_prand(gen_rand, "private_key", private_key_length))
     public_key = cose_class.from_cryptography_key(pri_key.public_key())
     att_obj, client_data = gen_packed_attestation(gen_rand, challenge, credential_id_length, public_key)
 
@@ -1081,9 +1083,18 @@ def test_vectors_apple_ecdsa(
     cose.RS256,
 )
 test_vectors_packed_eddsa(
-    "## Packed Attestation with Ed25519 Credential ## {#sctn-test-vectors-packed-ed25519}",
-    'packed.Ed25519',
+    "## Packed Attestation with Ed25519 Credential ## {#sctn-test-vectors-packed-eddsa}",
+    'packed.EdDSA',
     cose.EdDSA,
+    ed25519.Ed25519PrivateKey,
+    32,
+)
+test_vectors_packed_eddsa(
+    "## Packed Attestation with Ed448 Credential ## {#sctn-test-vectors-packed-ed448}",
+    'packed.Ed448',
+    cose.Ed448,
+    ed448.Ed448PrivateKey,
+    57,
 )
 
 test_vectors_tpm_ecdsa(


Reviews:
user: login: timcappalli
state: APPROVED
author_association: MEMBER
submitted_at: 2025-04-28T08:53:13Z
user: login: MasterKale
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-04-30T19:09:22Z
user: login: selfissued
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-05-01T19:49:19Z
user: login: akshayku
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-07T18:31:55Z
user: login: akshayku
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-07T18:32:30Z
user: login: akshayku
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-07T18:33:37Z
user: login: akshayku
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-07T18:34:22Z
user: login: emlun
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-07T19:10:17Z
user: login: akshayku
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-07T19:48:47Z
user: login: akshayku
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-07T19:54:02Z
user: login: akshayku
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-07T20:05:25Z
user: login: zacknewman
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-07T20:16:33Z
user: login: akshayku
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-07T21:18:41Z
user: login: emlun
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-08T09:11:05Z
user: login: emlun
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-08T09:16:29Z
user: login: emlun
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-08T09:16:32Z
user: login: emlun
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-08T12:10:27Z
user: login: zacknewman
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-08T15:32:41Z
user: login: zacknewman
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-08T17:21:04Z
user: login: emlun
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-20T18:49:25Z
user: login: selfissued
body: This looks ready to merge.
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-05-21T08:28:23Z
user: login: akshayku
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-21T13:07:03Z
user: login: zacknewman
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-21T14:10:24Z
user: login: selfissued
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-21T14:13:32Z
user: login: emlun
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-21T15:04:25Z
user: login: zacknewman
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-21T15:09:49Z
user: login: emlun
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-21T16:55:01Z
user: login: akshayku
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-05-21T19:42:14Z
user: login: selfissued
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-05-21T22:07:46Z

Review comments:
diff_hunk: @@ -3479,7 +3487,9 @@ optionally evidence of [=user consent=] to a specific transaction.
 
         [=[RPS]=] that wish to support a wide range of [=authenticators=] SHOULD include at least the following {{COSEAlgorithmIdentifier}} values:
 
-        * -8 (Ed25519)
+        * -50 (Ed25519)
+        * -8 (EdDSA)
+        * -9 (ESP256)
path: index.bs
user: login: akshayku
body: IANA is showing that it is unassigned as of now. -7 is for ECDSA with P-256 with SHA256. 
created_at: 2025-05-07T18:31:55Z
author_association: CONTRIBUTOR
diff_hunk: @@ -510,10 +510,18 @@ The sample code for generating and registering a new key follows:
       // This Relying Party will accept either an EdDSA, ES256 or RS256 credential, but
       // prefers an EdDSA credential.
       pubKeyCredParams: [
+        {
+          type: "public-key",
+          alg: -50 // "Ed25519" as registered in the IANA COSE Algorithms registry
path: index.bs
user: login: akshayku
body: This is assigned to ML-DSA-87 in IANA https://www.iana.org/assignments/cose/cose.xhtml
created_at: 2025-05-07T18:32:30Z
author_association: CONTRIBUTOR
diff_hunk: @@ -4322,12 +4332,15 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
 <div dfn-type="typedef" dfn-for="COSEAlgorithmIdentifier">
     A {{COSEAlgorithmIdentifier}}'s value is a number identifying a cryptographic algorithm.
     The algorithm identifiers SHOULD be values registered in the IANA COSE Algorithms registry [[!IANA-COSE-ALGS-REG]],
-    for instance, <code>-7</code> for "ES256" and <code>-257</code> for "RS256".
+    for instance, <code>-9</code> for "ESP256" and <code>-257</code> for "RS256".
 
     The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a [=COSE key=]. In order to promote interoperability, this specification makes the following additional guarantees of [=credential public keys=]:
         1. Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP256 (-9) MUST NOT use the compressed point form.
         1. Keys with algorithm ES384 (-35) MUST specify P-384 (2) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP384 (-48) MUST NOT use the compressed point form.
path: index.bs
user: login: akshayku
body: ECDSA with P384 is -35 I think. 
created_at: 2025-05-07T18:33:37Z
author_association: CONTRIBUTOR
diff_hunk: @@ -4322,12 +4332,15 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
 <div dfn-type="typedef" dfn-for="COSEAlgorithmIdentifier">
     A {{COSEAlgorithmIdentifier}}'s value is a number identifying a cryptographic algorithm.
     The algorithm identifiers SHOULD be values registered in the IANA COSE Algorithms registry [[!IANA-COSE-ALGS-REG]],
-    for instance, <code>-7</code> for "ES256" and <code>-257</code> for "RS256".
+    for instance, <code>-9</code> for "ESP256" and <code>-257</code> for "RS256".
 
     The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a [=COSE key=]. In order to promote interoperability, this specification makes the following additional guarantees of [=credential public keys=]:
         1. Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP256 (-9) MUST NOT use the compressed point form.
         1. Keys with algorithm ES384 (-35) MUST specify P-384 (2) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP384 (-48) MUST NOT use the compressed point form.
         1. Keys with algorithm ES512 (-36) MUST specify P-521 (3) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP512 (-49) MUST NOT use the compressed point form.
path: index.bs
user: login: akshayku
body: ECDSA with P521 with SHA512 is -36
created_at: 2025-05-07T18:34:22Z
author_association: CONTRIBUTOR
diff_hunk: @@ -4322,12 +4332,15 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
 <div dfn-type="typedef" dfn-for="COSEAlgorithmIdentifier">
     A {{COSEAlgorithmIdentifier}}'s value is a number identifying a cryptographic algorithm.
     The algorithm identifiers SHOULD be values registered in the IANA COSE Algorithms registry [[!IANA-COSE-ALGS-REG]],
-    for instance, <code>-7</code> for "ES256" and <code>-257</code> for "RS256".
+    for instance, <code>-9</code> for "ESP256" and <code>-257</code> for "RS256".
 
     The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a [=COSE key=]. In order to promote interoperability, this specification makes the following additional guarantees of [=credential public keys=]:
         1. Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP256 (-9) MUST NOT use the compressed point form.
         1. Keys with algorithm ES384 (-35) MUST specify P-384 (2) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP384 (-48) MUST NOT use the compressed point form.
path: index.bs
user: login: emlun
body: -35 is ECDSA with SHA-384 and unspecified curve (this is why WebAuthn adds the restriction to the P-384 curve on line 4340). -48 is the new identifier that fully specifies ECDSA with SHA-384 and curve P-384.
created_at: 2025-05-07T19:10:16Z
author_association: MEMBER
diff_hunk: @@ -4322,12 +4332,15 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
 <div dfn-type="typedef" dfn-for="COSEAlgorithmIdentifier">
     A {{COSEAlgorithmIdentifier}}'s value is a number identifying a cryptographic algorithm.
     The algorithm identifiers SHOULD be values registered in the IANA COSE Algorithms registry [[!IANA-COSE-ALGS-REG]],
-    for instance, <code>-7</code> for "ES256" and <code>-257</code> for "RS256".
+    for instance, <code>-9</code> for "ESP256" and <code>-257</code> for "RS256".
 
     The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a [=COSE key=]. In order to promote interoperability, this specification makes the following additional guarantees of [=credential public keys=]:
         1. Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP256 (-9) MUST NOT use the compressed point form.
         1. Keys with algorithm ES384 (-35) MUST specify P-384 (2) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP384 (-48) MUST NOT use the compressed point form.
path: index.bs
user: login: akshayku
body: If they are logically equivalent, I would actually advice against using these new numbers by the RPs.

Older platforms and Older Authenticators do not understand these numbers and will fail when specified with these numbers.  

These new numbers do not add any value IMO vs specifying existing values and will confuse RPs and add support costs. 
created_at: 2025-05-07T19:48:47Z
author_association: CONTRIBUTOR
diff_hunk: @@ -4322,12 +4332,15 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
 <div dfn-type="typedef" dfn-for="COSEAlgorithmIdentifier">
     A {{COSEAlgorithmIdentifier}}'s value is a number identifying a cryptographic algorithm.
     The algorithm identifiers SHOULD be values registered in the IANA COSE Algorithms registry [[!IANA-COSE-ALGS-REG]],
-    for instance, <code>-7</code> for "ES256" and <code>-257</code> for "RS256".
+    for instance, <code>-9</code> for "ESP256" and <code>-257</code> for "RS256".
 
     The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a [=COSE key=]. In order to promote interoperability, this specification makes the following additional guarantees of [=credential public keys=]:
         1. Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP256 (-9) MUST NOT use the compressed point form.
         1. Keys with algorithm ES384 (-35) MUST specify P-384 (2) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP384 (-48) MUST NOT use the compressed point form.
path: index.bs
user: login: akshayku
body: For example, one such unupgradable security keys shows supporting these algos in their getInfo. [{"alg": -7, "type": "public-key"}, {"alg": -8, "type": "public-key"}, {"alg": -35, "type": "public-key"}]. Newer clients may be able to do the translation to older value from newer values, but not every user agent and OS is upgradable. 

created_at: 2025-05-07T19:54:02Z
author_association: CONTRIBUTOR
diff_hunk: @@ -4322,12 +4332,15 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
 <div dfn-type="typedef" dfn-for="COSEAlgorithmIdentifier">
     A {{COSEAlgorithmIdentifier}}'s value is a number identifying a cryptographic algorithm.
     The algorithm identifiers SHOULD be values registered in the IANA COSE Algorithms registry [[!IANA-COSE-ALGS-REG]],
-    for instance, <code>-7</code> for "ES256" and <code>-257</code> for "RS256".
+    for instance, <code>-9</code> for "ESP256" and <code>-257</code> for "RS256".
 
     The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a [=COSE key=]. In order to promote interoperability, this specification makes the following additional guarantees of [=credential public keys=]:
         1. Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP256 (-9) MUST NOT use the compressed point form.
         1. Keys with algorithm ES384 (-35) MUST specify P-384 (2) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP384 (-48) MUST NOT use the compressed point form.
path: index.bs
user: login: akshayku
body: Looked at earlier discussions in the issue. Fallback mechanism is easy to get it wrong. We have spent years to get these values supported across the ecosystem by every RP, user agent and authenticator. 
created_at: 2025-05-07T20:05:25Z
author_association: CONTRIBUTOR
diff_hunk: @@ -4322,12 +4332,15 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
 <div dfn-type="typedef" dfn-for="COSEAlgorithmIdentifier">
     A {{COSEAlgorithmIdentifier}}'s value is a number identifying a cryptographic algorithm.
     The algorithm identifiers SHOULD be values registered in the IANA COSE Algorithms registry [[!IANA-COSE-ALGS-REG]],
-    for instance, <code>-7</code> for "ES256" and <code>-257</code> for "RS256".
+    for instance, <code>-9</code> for "ESP256" and <code>-257</code> for "RS256".
 
     The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a [=COSE key=]. In order to promote interoperability, this specification makes the following additional guarantees of [=credential public keys=]:
         1. Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP256 (-9) MUST NOT use the compressed point form.
         1. Keys with algorithm ES384 (-35) MUST specify P-384 (2) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP384 (-48) MUST NOT use the compressed point form.
path: index.bs
user: login: zacknewman
body: I also find these new IDs somewhat dubious. One, these new IDs don't prevent WebAuthn from having to still add additional requirements like using the uncompressed point; so not sure what there is to gain. Two, in practice I don't see RPs or authenticators ever _only_ supporting the new IDs. My YubiKey can never get upgraded, and I don't plan on replacing it for years until the next vulnerability is found. RPs would be downright foolish to _only_ support the new ID since such authenticators couldn't be used. I don't see newer/upgradable authenticators _only_ supporting the new IDs since there will likely be many RPs that only handle the "legacy" IDs. This leads to an at-best situation of RPs and authenticators always, or at least for _many_ years, supporting both IDs; at which point, what's to gain? By the time RPs and authenticators would be willing to change to _only_ support the new IDs, the IDs will likely be considered insecure and only post-quantum signatures will be used (e.g, the aforementioned ML-DSA ID).

It seems that this only adds a way to support Ed448, and I think a much smaller draft could be written that adds Ed448 without adding non-polymorphic IDs. There is going to be situations I believe where authenticators inconsistently use the IDs leading to conflicting behavior depending on how strict RPs parse the data (e.g., my library strictly enforces the IDs match _exactly_, but I bet some implementations will not care).

Additionally as previously mentioned, it's weird to have to still encode `crv` when the underlying ID is not polymorphic not to mention some IDs are now one byte larger (e.g., Ed25519).
created_at: 2025-05-07T20:16:33Z
author_association: CONTRIBUTOR
diff_hunk: @@ -4322,12 +4332,15 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
 <div dfn-type="typedef" dfn-for="COSEAlgorithmIdentifier">
     A {{COSEAlgorithmIdentifier}}'s value is a number identifying a cryptographic algorithm.
     The algorithm identifiers SHOULD be values registered in the IANA COSE Algorithms registry [[!IANA-COSE-ALGS-REG]],
-    for instance, <code>-7</code> for "ES256" and <code>-257</code> for "RS256".
+    for instance, <code>-9</code> for "ESP256" and <code>-257</code> for "RS256".
 
     The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a [=COSE key=]. In order to promote interoperability, this specification makes the following additional guarantees of [=credential public keys=]:
         1. Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP256 (-9) MUST NOT use the compressed point form.
         1. Keys with algorithm ES384 (-35) MUST specify P-384 (2) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP384 (-48) MUST NOT use the compressed point form.
path: index.bs
user: login: akshayku
body: Also, let's assume that -7 and -9 are equivalent (ECC-P256/SHA256) and -35 and -1001 (some random number for discussion sake) are equivalent (ECC-P384/SHA384). 

Let's say
- Authenticator-1 supports -7 and -1001. 
- Authenticator-2 supports -7 and -35. 

RPs Algorithm preferred list of (-35, -7, -1001, -9) will result in Authenticator-1 picking up (ECC-P256/SHA256) and Authenticator-2 picking up (ECC-P384/SHA384), although technically both support (ECC-P256/SHA256) and (ECC-P384/SHA384)

Having two different values with same meaning in a priority list can become tricky and RP needs to be careful. 

I am not seeing the benefit of using the newer values. I would recommend that WebAuthn specify that RPs should use older values as we have already reserved curves for those numbers in WebAuthn. 

created_at: 2025-05-07T21:18:41Z
author_association: CONTRIBUTOR
diff_hunk: @@ -510,10 +510,18 @@ The sample code for generating and registering a new key follows:
       // This Relying Party will accept either an EdDSA, ES256 or RS256 credential, but
       // prefers an EdDSA credential.
       pubKeyCredParams: [
+        {
+          type: "public-key",
+          alg: -50 // "Ed25519" as registered in the IANA COSE Algorithms registry
path: index.bs
user: login: emlun
body: Thanks for catching the conflict! [Draft 12](https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-12.html#name-edwards-curve-digital-signa) changed the assignment request to -19. Fixed in c129a055c23e97b01caf513aa130a48d3904afe2.
created_at: 2025-05-08T09:11:05Z
author_association: MEMBER
diff_hunk: @@ -4322,12 +4332,15 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
 <div dfn-type="typedef" dfn-for="COSEAlgorithmIdentifier">
     A {{COSEAlgorithmIdentifier}}'s value is a number identifying a cryptographic algorithm.
     The algorithm identifiers SHOULD be values registered in the IANA COSE Algorithms registry [[!IANA-COSE-ALGS-REG]],
-    for instance, <code>-7</code> for "ES256" and <code>-257</code> for "RS256".
+    for instance, <code>-9</code> for "ESP256" and <code>-257</code> for "RS256".
 
     The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a [=COSE key=]. In order to promote interoperability, this specification makes the following additional guarantees of [=credential public keys=]:
         1. Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP256 (-9) MUST NOT use the compressed point form.
         1. Keys with algorithm ES384 (-35) MUST specify P-384 (2) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP384 (-48) MUST NOT use the compressed point form.
path: index.bs
user: login: emlun
body: Thanks for catching the conflict! [Draft 12](https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-12.html#name-elliptic-curve-digital-sign) changed the assignment request to -51. Fixed in c129a055c23e97b01caf513aa130a48d3904afe2.
created_at: 2025-05-08T09:16:29Z
author_association: MEMBER
diff_hunk: @@ -4322,12 +4332,15 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
 <div dfn-type="typedef" dfn-for="COSEAlgorithmIdentifier">
     A {{COSEAlgorithmIdentifier}}'s value is a number identifying a cryptographic algorithm.
     The algorithm identifiers SHOULD be values registered in the IANA COSE Algorithms registry [[!IANA-COSE-ALGS-REG]],
-    for instance, <code>-7</code> for "ES256" and <code>-257</code> for "RS256".
+    for instance, <code>-9</code> for "ESP256" and <code>-257</code> for "RS256".
 
     The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a [=COSE key=]. In order to promote interoperability, this specification makes the following additional guarantees of [=credential public keys=]:
         1. Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP256 (-9) MUST NOT use the compressed point form.
         1. Keys with algorithm ES384 (-35) MUST specify P-384 (2) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP384 (-48) MUST NOT use the compressed point form.
         1. Keys with algorithm ES512 (-36) MUST specify P-521 (3) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP512 (-49) MUST NOT use the compressed point form.
path: index.bs
user: login: emlun
body: Thanks for catching the conflict! [Draft 12](https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-12.html#name-elliptic-curve-digital-sign) changed the assignment request to -52. Fixed in c129a055c23e97b01caf513aa130a48d3904afe2.
created_at: 2025-05-08T09:16:32Z
author_association: MEMBER
diff_hunk: @@ -4322,12 +4332,15 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
 <div dfn-type="typedef" dfn-for="COSEAlgorithmIdentifier">
     A {{COSEAlgorithmIdentifier}}'s value is a number identifying a cryptographic algorithm.
     The algorithm identifiers SHOULD be values registered in the IANA COSE Algorithms registry [[!IANA-COSE-ALGS-REG]],
-    for instance, <code>-7</code> for "ES256" and <code>-257</code> for "RS256".
+    for instance, <code>-9</code> for "ESP256" and <code>-257</code> for "RS256".
 
     The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a [=COSE key=]. In order to promote interoperability, this specification makes the following additional guarantees of [=credential public keys=]:
         1. Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP256 (-9) MUST NOT use the compressed point form.
         1. Keys with algorithm ES384 (-35) MUST specify P-384 (2) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP384 (-48) MUST NOT use the compressed point form.
path: index.bs
user: login: emlun
body: I agree that there's little value in these particular identifiers (except the addition of Ed448) within the current context of WebAuthn, where we've explicitly patched the ambiguity in the polymorphic identifiers, but these new identifiers are defined for a wider context that covers more than just WebAuthn. In particular, they patch the gap between JOSE and COSE where, for example, the JOSE identifier `"ES256"` _does_ fully specify "ECDSA with SHA-256 on the P-256 curve" but the "equivalent" COSE identifier `-7` _does not_ (evidently to the WebAuthn WG's surprise earlier) specify the curve, only "ECDSA with SHA-256". For other COSE use cases, especially new ones, it makes a lot of sense to be able to fully describe the crypto suite with a single identifier. So the identifiers definitely have merit in the wider context outside WebAuthn.

So in WebAuthn we are faced with a choice, then: should we support these new identifiers, or not?

If we do not, we'll have to declare that our `COSEAlgorithmIdentifier` parameter only supports a subset of `COSEAlgorithmIdentifier` values, and continue updating our exclusion list as new identifiers are added to the registry. And it would need to be an exclusion list rather than an allow list, because with an allow list there'd be no point in referring to an external registry in the first place. I don't think this is a good approach. It's already unfortunate that we add the restrictions against compressed point formats, I don't think we should add even more constraints on our interop with COSE.

If we do support the new identifiers (which WebAuthn L1 and L2 do implicitly!), then I agree that it's unfortunate to have values that are semantically equivalent (in our context) but need to be treated as distinct in order to not confuse implementations. But I think that's a lesser problem. Authenticators are incentivized to support both identifiers in case an RP only requests one (including old RPs that only request the old identifier), and RPs are also incentivized to request both identifiers in case an authenticator only supports one (including existing authenticators that only support the old identifier). But as you say, the old values are likely to continue to dominate for the foreseeable future, so it is unlikely that the new values will disadvantage RPs or authenticators that have not or cannot update to support the new values.

To summarize: the new COSE identifiers apply to a wider context than WebAuthn, and I think that making WebAuthn align more with COSE is better than making WebAuthn diverge further from COSE.
created_at: 2025-05-08T12:10:27Z
author_association: MEMBER
diff_hunk: @@ -4322,12 +4332,15 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
 <div dfn-type="typedef" dfn-for="COSEAlgorithmIdentifier">
     A {{COSEAlgorithmIdentifier}}'s value is a number identifying a cryptographic algorithm.
     The algorithm identifiers SHOULD be values registered in the IANA COSE Algorithms registry [[!IANA-COSE-ALGS-REG]],
-    for instance, <code>-7</code> for "ES256" and <code>-257</code> for "RS256".
+    for instance, <code>-9</code> for "ESP256" and <code>-257</code> for "RS256".
 
     The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a [=COSE key=]. In order to promote interoperability, this specification makes the following additional guarantees of [=credential public keys=]:
         1. Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP256 (-9) MUST NOT use the compressed point form.
         1. Keys with algorithm ES384 (-35) MUST specify P-384 (2) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP384 (-48) MUST NOT use the compressed point form.
path: index.bs
user: login: zacknewman
body: I understand that COSE is separate from WebAuthn; however it appears to me that this new draft is very much tied to WebAuthn hence why it is happening in cohort. Yes, technically every RP needs to review IANA COSE algorithms every day for eternity to decide if newer values have been added that they want to support; but I'm unsure if dedicated IDs would be added without this draft. As much as the math person in me would love if specs and registries were super rigorous, one has to accept the fact they aren't and in particular there will be things like "de facto" requirements.

For example, I don't think it's a coincidence there already is an explicit COSE ID for ECDSA with SHA-256 using curve secp256k1 and _not_ for the much more common P-256. To me this is due to the fact that ES256 has the "de facto" requirement that `crv` is P-256. It's nice for specs to make this clear, like WebAuthn does; but in practice it likely doesn't matter much.

To play the game of hypotheticals, in an alternate universe if COSE never defined the somewhat absurd EdDSA ID but instead ED256 and ED512 IDs where the former were defined as EdDSA using SHAKE256 and the latter were defined as EdDSA using SHA-512; then like ES256 has the "de facto" requirement that `crv` is P-256, these IDs would have also have had "de facto" requirements that `crv` is edwards448 and edwards25519 respectively. WebAuthn then would have simply explicitly added those requirements. In that universe, I don't think this draft would have been written since the actual motive of adding support for Ed448 wouldn't have existed.

It appears to me the motive was originally "how do we add Ed448" which then changed to "well since we're here, let's go ahead and also add specific IDs for P-256 and company", and I don't think that adds value. The only counter I can come up with is to my above claim

> I'm unsure if dedicated IDs would be added without this draft

If one rejects that and is worried a completely separate "process" were to occur that added these more specific IDs, then WebAuthn is in an unfortunate position of not being able to control this which in turn would lead to some indeterminate amount of time between when such IDs were added to IANA and the spec updated to reflect them. By being in control ourselves, we can be sure there is no "gap" between the IANA registry and spec.

I personally don't find that argument _that_ convincing due to the aforementioned "de facto" requirements and the fact that this prophylactic approach seemingly has no end. What if some process were to add ED256 and ED512 as mentioned, shouldn't we add those too just in case? After all, it is inconsistent to have IDs like ES256 which mandate the hashing algorithm but not the curve so shouldn't the same exist for EdDSA? Conversely, perhaps a process adds ECDSA to mirror EdDSA so COSE now has an ID that is both curve and hashing agnostic. Where does this end?

Regardless, my library already supports these new IDs; so it's no skin off my back. I'm simply providing my two cents.
created_at: 2025-05-08T15:32:41Z
author_association: CONTRIBUTOR
diff_hunk: @@ -4322,12 +4332,15 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
 <div dfn-type="typedef" dfn-for="COSEAlgorithmIdentifier">
     A {{COSEAlgorithmIdentifier}}'s value is a number identifying a cryptographic algorithm.
     The algorithm identifiers SHOULD be values registered in the IANA COSE Algorithms registry [[!IANA-COSE-ALGS-REG]],
-    for instance, <code>-7</code> for "ES256" and <code>-257</code> for "RS256".
+    for instance, <code>-9</code> for "ESP256" and <code>-257</code> for "RS256".
 
     The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a [=COSE key=]. In order to promote interoperability, this specification makes the following additional guarantees of [=credential public keys=]:
         1. Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP256 (-9) MUST NOT use the compressed point form.
         1. Keys with algorithm ES384 (-35) MUST specify P-384 (2) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP384 (-48) MUST NOT use the compressed point form.
path: index.bs
user: login: zacknewman
body: > Also, let's assume that -7 and -9 are equivalent (ECC-P256/SHA256) and -35 and -1001 (some random number for discussion sake) are equivalent (ECC-P384/SHA384).
> 
> Let's say
> 
>     * Authenticator-1 supports -7 and -1001.
> 
>     * Authenticator-2 supports -7 and -35.
> 
> 
> RPs Algorithm preferred list of (-35, -7, -1001, -9) will result in Authenticator-1 picking up (ECC-P256/SHA256) and Authenticator-2 picking up (ECC-P384/SHA384), although technically both support (ECC-P256/SHA256) and (ECC-P384/SHA384)
> 
> Having two different values with same meaning in a priority list can become tricky and RP needs to be careful.
> 
> I am not seeing the benefit of using the newer values. I would recommend that WebAuthn specify that RPs should use older values as we have already reserved curves for those numbers in WebAuthn.

[I've made my thoughts clear on this matter](https://github.com/w3c/webauthn/pull/2283#discussion_r2079960867), and I believe this is a solution in search of a problem; however if the committee has determined this is how it is to be, then c'est la vie.

One approach to "solve" this problem is to mandate that user agents _always_ add a legacy ID before/after a "new" ID _and_ add the "new" ID before/after a legacy ID iff the list of supported IDs from the RP contains a "new" ID. Terminology could optionally be added to avoid duplicates that would arise from this; however duplicates have always been a possibility. In addition to this, the spec _requires_ that _if_ an RP supports a "new" ID, then they are obligated to also support the legacy ID potentially also requiring that they be treated interchangeably (e.g., if a self attestation signature uses a legacy ID but the attested credential data uses the "new" ID, RPs are required to accept it—assuming the original list of supported IDs provided by the RP contained the "new" ID). We require that authenticators _don't_ treat the IDs interchangeably in the interest of compatibility.

Here there is consistent behavior, we remove the possibility of "weirdness" from the RP by punting the responsibility to user agents (which already has precedent), and things don't break for RPs that only support the legacy IDs.

As far as terminology is concerned, we should avoid words like "equivalent" since both formally and informally it's not quite correct to say they are equivalent. They're only "equivalent" for RPs that support the new IDs, but they're clearly not equivalent for authenticators nor RPs that don't support the new IDs.

To be clear, user agents perform this "algorithm" for _each_ new ID and not for the mere existence of one (e.g., if an RP passes `[-19, -7]`, then the user agent would modify it such that it becomes `[-19,-8,-7]` (i.e., user agents conservatively add the legacy ID for EdDSA but don't add the "new" ID for ESP256 since the RP only claimed support for the legacy ES256)).
created_at: 2025-05-08T17:21:03Z
author_association: CONTRIBUTOR
diff_hunk: @@ -3479,7 +3487,9 @@ optionally evidence of [=user consent=] to a specific transaction.
 
         [=[RPS]=] that wish to support a wide range of [=authenticators=] SHOULD include at least the following {{COSEAlgorithmIdentifier}} values:
 
-        * -8 (Ed25519)
+        * -50 (Ed25519)
+        * -8 (EdDSA)
+        * -9 (ESP256)
path: index.bs
user: login: emlun
body: -9 and -19 are registered now: https://www.iana.org/assignments/cose/cose.xhtml#algorithms
created_at: 2025-05-20T18:49:25Z
author_association: MEMBER
diff_hunk: @@ -4326,8 +4326,11 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
 
     The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a [=COSE key=]. In order to promote interoperability, this specification makes the following additional guarantees of [=credential public keys=]:
         1. Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP256 (-9) MUST NOT use the compressed point form.
path: index.bs
user: login: akshayku
body: This kind of says that WebAuthn support these newer algorithms. Can we put somewhere in the spec that RPs should use older values instead of new ones? Or atleast should always specify older values first for backwards compatibility.  
created_at: 2025-05-21T13:07:03Z
author_association: CONTRIBUTOR
diff_hunk: @@ -4326,8 +4326,11 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
 
     The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a [=COSE key=]. In order to promote interoperability, this specification makes the following additional guarantees of [=credential public keys=]:
         1. Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP256 (-9) MUST NOT use the compressed point form.
path: index.bs
user: login: zacknewman
body: @akshayku, one of the points @emlun  has been trying to convey this entire time is that WebAuthn _does_ support these new algorithms independent of their mention or recommendation in the spec since WebAuthn supports _all_ algorithms in the COSE registry.

The most recent revision to the PR only recommends `EdDSA`, `ES256`, and `RS256`. He is trying to convey that for RPs that do support the new `ESP*` IDs they are required to represent the keys in the uncompressed form. RPs that support the new `ESP*` IDs do so not because they are recommended by the spec, but because an RP is free to support whatever IDs they want.

It seems as though you feel the spec should not only not recommend these new IDs but more strongly should recommend _against_ using these new IDs which I don't agree with. An RP should be allowed to use these new IDs if they choose.

@emlun, tangential to this; but why don't we require the uncompressed form for COSE IDs like `ES256K`? Would it be better to just require _all_ `EC2` algorithms to have their key encoded in the uncompressed form?
created_at: 2025-05-21T14:10:23Z
author_association: CONTRIBUTOR
diff_hunk: @@ -4326,8 +4326,11 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
 
     The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a [=COSE key=]. In order to promote interoperability, this specification makes the following additional guarantees of [=credential public keys=]:
         1. Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP256 (-9) MUST NOT use the compressed point form.
path: index.bs
user: login: selfissued
body: > This kind of says that WebAuthn support these newer algorithms.

The intent, I think, is to constrain how the new algorithms are used within WebAuthn.

> Can we put somewhere in the spec that RPs should use older values instead of new ones? Or atleast should always specify older values first for backwards compatibility.

I'm OK with us saying that the older algorithms that we constrained the meanings of in WebAuthn continue to have those meanings and continue to be usable.  And that to promote interoperability, where old algorithms exist that we constrained the meanings of, that implementations are encouraged to keep using them with those meanings to enhance interoperability with implementations that were created before the new algorithms came into existence.

created_at: 2025-05-21T14:13:32Z
author_association: CONTRIBUTOR
diff_hunk: @@ -4326,8 +4326,11 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
 
     The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a [=COSE key=]. In order to promote interoperability, this specification makes the following additional guarantees of [=credential public keys=]:
         1. Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP256 (-9) MUST NOT use the compressed point form.
path: index.bs
user: login: emlun
body: @akshayku sure, I'll add a note.

> for RPs that do support the new `ESP*` IDs they are required to represent the keys in the uncompressed form

This requirement applies more to authenticators than RPs. Authenticators are the ones that emit public keys, and RPs are the ones that consume them. WebAuthn does not care how RPs represent keys internally.

> why don't we require the uncompressed form for COSE IDs like `ES256K`?

Good question! Probably because there weren't (and still aren't?) many authenticators that support `ES256K`, so we haven't observed interop problems with its key encoding. (Much to @akshayku's point: even if WebAuthn _theoretically_ supports any applicable COSE alg, in practice only a few are commonly used.) I wouldn't add a restriction for `ES256K` at this point.
created_at: 2025-05-21T15:04:25Z
author_association: MEMBER
diff_hunk: @@ -4326,8 +4326,11 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
 
     The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a [=COSE key=]. In order to promote interoperability, this specification makes the following additional guarantees of [=credential public keys=]:
         1. Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP256 (-9) MUST NOT use the compressed point form.
path: index.bs
user: login: zacknewman
body: > This requirement applies more to authenticators than RPs. Authenticators are the ones that emit public keys, and RPs are the ones that consume them. WebAuthn does not care how RPs represent keys internally.

RPs need to know how to decode the key though, so it very much affects RPs. For example, since only the uncompressed form is supported, my CBOR parser only parses it and not the compressed form.
created_at: 2025-05-21T15:09:48Z
author_association: CONTRIBUTOR
diff_hunk: @@ -4326,8 +4326,11 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
 
     The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a [=COSE key=]. In order to promote interoperability, this specification makes the following additional guarantees of [=credential public keys=]:
         1. Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the [=crv=] parameter and MUST NOT use the compressed point form.
+        1. Keys with algorithm ESP256 (-9) MUST NOT use the compressed point form.
path: index.bs
user: login: emlun
body: It seemed weird to add just a note with no actual recommendation, so I added an actual normative recommendation against the new IDs with a note explaining why. @akshayku what do you think?
created_at: 2025-05-21T16:55:00Z
author_association: MEMBER

PR comments:
user: login: zacknewman
created_at: 2025-04-25T16:32:44Z
body: Changes must be made for ESP384 and ESP512 as well. For example [updating the packed attestations](https://w3c.github.io/webauthn/#sctn-test-vectors-packed-es384) and adding the additional requirement that the compressed point must be used for those algorithms as you have done for ESP256. For example:

> Keys with algorithm ESP384 (-48) MUST NOT use the compressed point form.
author_association: CONTRIBUTOR
user: login: nadalin
created_at: 2025-04-30T19:09:44Z
body: @selfissued can you review ?
author_association: CONTRIBUTOR
user: login: selfissued
created_at: 2025-05-01T20:12:08Z
body: In [16.8 Packed Attestation with ES384 Credential](https://w3c.github.io/webauthn/#sctn-test-vectors-packed-es384), the private key should be changed to use ESP384 (-48) rather than ES384 (-35).

In [16.9 Packed Attestation with ES512 Credential](https://w3c.github.io/webauthn/#sctn-test-vectors-packed-es512), the private key should be changed to use ESP512 (-49) rather than ES512 (-36).

Likewise, the other uses of ES256 should be looked at to change to ESP256, for instance in all the other test vectors in [16 Test Vectors](https://w3c.github.io/webauthn/#sctn-test-vectors).


author_association: CONTRIBUTOR
user: login: emlun
created_at: 2025-05-06T12:18:52Z
body: @selfissued Thanks, this is resolved in meta-PR #2290 which in turn depends on #2289. I'll mark this PR as blocked waiting on #2289 so we can update the test vectors along with the generator script.
author_association: MEMBER
user: login: zacknewman
created_at: 2025-05-06T14:58:09Z
body: [As stated](https://github.com/w3c/webauthn/pull/2283#issuecomment-2830884816), I'm pretty sure we need to add the requirement that the uncompressed points MUST be used for ESP384 and ESP512 just as we have done for ES256, ESP256, ES384, and ES512.
author_association: CONTRIBUTOR
user: login: emlun
created_at: 2025-05-06T20:41:12Z
body: @zacknewman Thanks, I had fixed this (thanks for pointing it out!) but apparently forgot to push it. Fixed now in 928c6684a87c0a1e1efc7c0506009fac3e9a1b76.
author_association: MEMBER
user: login: emlun
created_at: 2025-05-07T19:23:46Z
body: @selfissued As you can see in [Akshay's comments above](https://github.com/w3c/webauthn/pull/2283#pullrequestreview-2822828036), we discovered on today's WG call that some of the COSE algorithm identifiers in https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-11.html have also been requested for assignment in https://www.ietf.org/archive/id/draft-ietf-cose-dilithium-06.html:

* -48 is requested for both ESP384 and ML-DSA-44
* -49 is requested for both ESP512 and ML-DSA-65
* -50 is requested for both Ed25519 and ML-DSA-87

Looks like the ML-DSA ones have already landed in the [COSE registry](https://www.iana.org/assignments/cose/cose.xhtml#algorithms). So I assume jose-fully-specified-algorithms will need to change these assignment requests to other values?
author_association: MEMBER
user: login: emlun
created_at: 2025-05-07T19:44:54Z
body: #2289 is now merged, but I'll keep the "blocked" label until https://github.com/w3c/webauthn/pull/2283#issuecomment-2859975962 is resolved.
author_association: MEMBER
user: login: selfissued
created_at: 2025-05-08T04:08:23Z
body: Thanks for catching the conflict with the new ML-DSA assignments.  I'll update Fully-Specified Algorithms today.

This is particularly timely, because Fully-Specified Algorithms is going to the IESG for approval on their "telechat" in 10 hours.

After the IESG approves the spec, the IANA registrations will be made.
author_association: CONTRIBUTOR
user: login: selfissued
created_at: 2025-05-08T08:08:29Z
body: https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-12.html updates the requested assignments to avoid the conflicts.  It also requests assignment of Ed25519 in the one-byte range, matching the size of EdDSA, per @akshayku's observation.
author_association: CONTRIBUTOR
user: login: selfissued
created_at: 2025-05-13T12:03:15Z
body: FYI, the fully-specified algorithm numbers are now registered at https://www.iana.org/assignments/cose/cose.xhtml#algorithms.
author_association: CONTRIBUTOR
user: login: zacknewman
created_at: 2025-05-13T14:59:51Z
body: > FYI, the fully-specified algorithm numbers are now registered at https://www.iana.org/assignments/cose/cose.xhtml#algorithms.

Seems unfortunate that we have to yet again specify additional requirements _on top of_ what is in the registry. The description and associated draft for Ed25519 is simply "EdDSA using Ed25519 curve". That is _not_ sufficient. Ed25519 is a specific signature scheme defined in [RFC 8032](https://www.rfc-editor.org/rfc/rfc8032) that isn't simply "EdDSA with curve ed25519" but also requires several other conditions (e.g., SHA-512 is used as the hashing function). So like ES256 has the "de facto" requirement that P-256 is used, Ed25519 has the "de facto" requirement that SHA-512 is used, the pre-hash version of Ed25519 is used (not to be conflated with _curve_ ed25519), etc. This further adds to my argument that the WebAuthn spec should not be changed to accommodate these new algorithms with the exception of Ed448 due to no suitable algorithm existing before these additions.
author_association: CONTRIBUTOR
user: login: selfissued
created_at: 2025-05-14T20:03:21Z
body: @zacknewman the descriptions in the Fully-Specified Algorithms draft can still be updated at this point to be more prescriptive.  I'd be glad to do that.  Would these updated descriptions fit the bill, as far as you're concerned?

- Ed25519: EdDSA using Ed25519 curve, as described in Section 5.1 of RFC 8032
- Ed448: EdDSA using Ed448 curve, as described in Section 5.2 of RFC 8032

Of course, that's what was always meant, but it's fine to be more precise.

author_association: CONTRIBUTOR
user: login: zacknewman
created_at: 2025-05-15T14:45:33Z
body: > @zacknewman the descriptions in the Fully-Specified Algorithms draft can still be updated at this point to be more prescriptive. I'd be glad to do that. Would these updated descriptions fit the bill, as far as you're concerned?
> 
>     * Ed25519: EdDSA using Ed25519 curve, as described in Section 5.1 of RFC 8032
> 
>     * Ed448: EdDSA using Ed448 curve, as described in Section 5.2 of RFC 8032
> 
> 
> Of course, that's what was always meant, but it's fine to be more precise.

The biggest "issue" I see is that EdDSA is an 11-parameter algorithm; thus when I read "EdDSA using Ed25519 curve", I think it's now a 10-parameter algorithm since the curve parameter is fixed to be ed25519 which of all the parameters is the least in need of being stated. In other words "curve" should be dropped altogether; thus I think the following is better:

> Ed25519: Ed25519 as defined in RFC 8032 § 5.1.

If you insist for some reason to include "EdDSA" in the description, then something like:

> Ed25519: EdDSA instantiated to be Ed25519 as prescribed in RFC 8032 § 5.1.

Similar descriptions for Ed448 follow. The key is to not phrase "Ed25519" in the context of a _curve_ but instead as the specific signature scheme which of course implies curve ed25519 in addition to 10 other things. For example Ed25519ph is a signature scheme that meets your description since it is an example of EdDSA, it uses curve ed25519, and it's technically described in RFC 8032 § 5.1 (at the bottom of Table 1); however we want the COSE ID Ed25519 to _only_ represent the Ed25519 _signature scheme_.

Since we are here, it would also be nice for algorithms like ESP256 to require the uncompressed form since this would entirely eliminate the need for further refinement in WebAuthn for all of these new IDs.
author_association: CONTRIBUTOR
user: login: selfissued
created_at: 2025-05-15T19:57:59Z
body: OK, I understand and agree with this point you're making:
> Similar descriptions for Ed448 follow. The key is to not phrase "Ed25519" in the context of a _curve_ but instead as the specific signature scheme which of course implies curve ed25519 in addition to 10 other things.

Here, it sounds to me like you are talking about key representations:
> Since we are here, it would also be nice for algorithms like ESP256 to require the uncompressed form since this would entirely eliminate the need for further refinement in WebAuthn for all of these new IDs.

By design, the cryptographic algorithms are independent of the key representations used.  Everything works no matter what key representation is used, provided the implementation understands and correctly interprets the key representation(s) used.  Therefore, if WebAuthn wants to make statements about key representations it needs to do so itself.  I would file an issue about that if you believe that something is missing from WebAuthn.

For example, the equivalence of key representations is discussed in another context at https://www.rfc-editor.org/rfc/rfc7638.html#section-3.5 :
>   Note that a key need not be in JWK format to create a JWK Thumbprint
>   of it.  The only prerequisites are that the JWK representation of the
>   key be defined and the party creating the JWK Thumbprint be in
>   possession of the necessary key material.  These are sufficient to
>   create the hash input from the JWK representation of the key, as
>   described in [Section 3.3](https://www.rfc-editor.org/rfc/rfc7638.html#section-3.3).

It may not be OK for WebAuthn, but for the cryptographic algorithm, it doesn't matter if the key is represented as a JWK, a COSE_Key, in a X.509 certificate, or in an XML data structure, provided the implementation understands and correctly uses it.

cc: @OR13
author_association: CONTRIBUTOR
user: login: zacknewman
created_at: 2025-05-15T21:32:11Z
body: > Here, it sounds to me like you are talking about key representations:

I am indeed.

> It may not be OK for WebAuthn, but for the cryptographic algorithm, it doesn't matter if the key is represented as a JWK, a COSE_Key, in a X.509 certificate, or in an XML data structure, provided the implementation understands and correctly uses it.

That's fine. I'm looking at this entirely from the perspective of WebAuthn since there seems to be a desire to explicitly incorporate these new IDs into the spec despite objections. I'm unsure if the current description for Ed25519 is not sufficient from the wider context of COSE either. I'm "attacking" the description purely from the perspective of WebAuthn. So you may also not want to change the description of it assuming that the current description was the actual intent.

Does Ed25519 only mean _any_ EdDSA that uses curve ed25519 (e.g., Ed25519ph), or is the intent for it to only mean the Ed25519 scheme as defined in RFC 8032 § 5.1? Seeing how incredibly broad a lot of these IDs are, it wouldn't surprise me if Ed25519 were to mean _any_ EdDSA that uses curve ed25519. From the perspective of WebAuthn that would be highly unfortunate though since that would mean 10 additional requirements would need to be added (e.g., SHA-512 is used) in order to ensure Ed25519ph, Ed25519ctx, and infinite other possibilities are excluded.
author_association: CONTRIBUTOR
user: login: selfissued
created_at: 2025-05-15T21:47:40Z
body: > Does Ed25519 only mean any EdDSA that uses curve ed25519 (e.g., Ed25519ph), or is the intent for it to only mean the Ed25519 scheme as defined in RFC 8032 § 5.1?

I'd already clarified that the intent is for these identifiers to refer to the algorithms as specified in RFC 8032.  I will update the Fully-Specified Algorithms draft to say that explicitly during the AUTH48 process.  In the meantime, WebAuthn can count on that.

Thanks again for bringing the possibly ambiguous interpretation of the existing language to our attention.  I will close that ambiguity as part of the process of publishing Fully-Specified Algorithms as an RFC.
author_association: CONTRIBUTOR
user: login: emlun
created_at: 2025-05-19T12:29:42Z
body: Thanks @selfissued!

@zacknewman as for the inline additional requirements for `ESP*`, I'm conflicted. I would prefer not to have the restriction to uncompressed representations, but since we have it for `ES*` I figure the "path of least surprise" is to have them for `ESP*` too. But you'll notice there's no additional requirements like that for `Ed25519` or `Ed448` since none is needed - the only explicit mentions of them are in recommendations, examples and test vectors.

With that I think this is ready to merge as far as I'm concerned, unless we want to debate the restriction to uncompressed `ESP*` key representations.
author_association: MEMBER
user: login: zacknewman
created_at: 2025-05-19T15:11:30Z
body: @emlun,

Not sure how to interpret your comment about Ed25519 and Ed448, but [RFC 8032 § 5.2](https://www.rfc-editor.org/rfc/rfc8032#section-5.1.2) defines exactly how a point on the curve is to be encoded. Encoding it in any other way is wrong.

For curves like P-256, COSE does require at least implicitly that a point is encoded in _some_ form; otherwise anyone could send any format they wanted (e.g., the "Zack" format which is 5 0s followed by the y coordinate followed by 12 0s followed by the x coordinate followed by 18 3s). Specifically, COSE requires a point on the curve to be encoded according to [SEC 1, Version 2.0 § 2.3.3](https://www.secg.org/sec1-v2.pdf). That section describes two formats, and COSE requires the key/point to be encoded in one of the two. WebAuthn goes further and refines it to the much more popular "uncompressed" form.

Regardless, I already don't think these new IDs solve anything since I accept "de facto" requirements are a thing; thus whether or not COSE wants to prescribe how the key is to be encoded, in practice it will be according to SEC 1 and likely further the "uncompressed" form. Encoding it in _any_ other way will cause so many issues that implementors won't have much choice. Fortunately WebAuthn makes these "de facto" requirements explicit though.
author_association: CONTRIBUTOR
user: login: akshayku
created_at: 2025-05-19T15:15:36Z
body: Sorry, but I have objections to the PR itself for existing algorithms (-7, -35, -36, -8). 

It has cons and is a lot of make work for lot of companies without realistically RP/Platform/Authenticator ever being able to deprecate these existing COSE end points. 

From Windows perspective, we can't make changes to older platforms. And we are not planning to make changes for Windows for these newer code points which has existing equivalent. We don't see any benefit. 
From security key perspective, they have unupgradable security keys with existing algorithm code points burned in. 
From our Entra/MSA as an RP perspective, we cannot remove/deprecate  exisiting security keys/platform authenticator. 

I am not commenting about whether these newer code points are beneficial for other specs outside of WebAuthn. But I don't see any benefit out of these new code points. 

I am fine adding new algorithm for Ed448 if you care because that doesn't exist today from WebAuthn perspective. 
author_association: CONTRIBUTOR
user: login: OR13
created_at: 2025-05-19T16:02:04Z
body: I understand the desire not to use the new algorithms if the existing ones are burned into devices.

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?

In other words, in webauthn:

-7 means ECDSA with SHA256 and P-256 ... this now has an official name ESP256
-8 means EdDSA with Ed25519 ... this now has an official name Ed25519
...

Just for my own clarity are there any hardware devices out there that use -7 with a curve other than P-256?

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)



author_association: NONE
user: login: akshayku
created_at: 2025-05-19T16:08:44Z
body: > 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.)
author_association: CONTRIBUTOR
user: login: emlun
created_at: 2025-05-20T12:53:51Z
body: @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.

- Current implementations - of authenticators, of clients and of RPs - that only support/request the old IDs will continue to work with the old identifiers.
- New implementations that support/request both IDs will work with both.
- 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.
  - Consequently, existing authenticator implementations do not need to update (even in new versions) and can continue supporting only the old IDs if they wish.
- 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.
  - Consequently, existing RP implementations do not need to update (even in new versions) and can continue requesting only the old IDs if they wish.

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).

author_association: MEMBER
user: login: emlun
created_at: 2025-05-20T13:02:47Z
body: Hm, maybe I should also include client implementers in the breakdown :slightly_smiling_face: 

- Current client implementations whose [`getPublicKey()`](https://w3c.github.io/webauthn/#dom-authenticatorattestationresponse-getpublickey) supports only the old IDs will continue to work with current RP/authenticator implementations using the old IDs.
- New RP implementations requesting the new IDs will not be able to use `getPublicKey()` for new IDs in clients that do not support them, but that is to be expected when using new features.
  - Consequently, RPs are incentivized to either not use `getPublicKey()` or to continue using the old IDs if they need to use `getPublicKey()`.
  - Consequently, current client implementations do not need to update (even in new versions) to support the new IDs in `getPublicKey()`. (Unless we [make that mandatory in L4](https://github.com/w3c/webauthn/pull/2276), of course.)

Or is this outlook too naive?
author_association: MEMBER
user: login: akshayku
created_at: 2025-05-20T15:08:30Z
body: > @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 using these existing identifiers 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. 
author_association: CONTRIBUTOR
user: login: zacknewman
created_at: 2025-05-20T15:10:30Z
body: @emlun, almost all of the points you made are true without this PR as well. Without this PR, RPs can still add support for these new IDs; so I don't see how there is benefit in mentioning them in the spec. Two, adding these IDs is more work even if they're only "recommendations" for user agents, authenticators, and RPs. That is not even debatable in WebAuthn Level 4 if they were to become required. So if we accept that the legacy IDs will always need to be supported and RPs are always allowed to support IDs in the registry even if they're not explicitly mentioned in the spec (e.g., the new ones mentioned here)—in fact the spec permits IDs outside of the registry—then what's to be gained other than a more complex spec that doesn't actually add anything useful?

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. Fortunately, this "choice" doesn't require any changes to the spec; but if desired, one could add a note about why this "choice" is made. WebAuthn shouldn't make the list of recommended IDs too long; otherwise let's just add the entire registry to the list of recommendations. WebAuthn already "arbitrarily" makes choices (e.g., using the uncompressed P-256 point form), so there is nothing "weird" about the list of recommended IDs.

_If_ this were to go in, then you make a great point 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? Fortunately the SPKI data itself is not affected by these new IDs since it only concerns itself with the public key data, but that doesn't change the fact that the user agent still needs to be updated to recognize the new ID.
author_association: CONTRIBUTOR
user: login: emlun
created_at: 2025-05-20T18:47:17Z
body: @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).
author_association: MEMBER
user: login: zacknewman
created_at: 2025-05-20T19:52:47Z
body: > 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.

There is no need to tell RPs that request the new IDs that they SHOULD also request the old one since the old IDs are _always_ recommended (i.e., regardless if an RP requests the new IDs, they SHOULD request the old IDs); as a result, I think the PR should be changed to remove the recommendation in `pubKeyCredParams` for the new IDs.

There _is_ harm in adding the new IDs. It adds complexity to the spec that doesn't need to be there. There is a reason that only 3 IDs are recommended for `pubKeyCredParams`. Why is `ES512` not in the recommended list of `pubKeyCredParams`? I claim the answer to that question is the same answer to "why is `Ed25519` not in the recommended list of `pubKeyCredParams`?" We already have an ID, `EdDSA`, that represents Ed25519; and we don't want that list to be larger than necessary.

I will say that removing the restriction for `ESP*` IDs to allow them to be encoded as octet-key pairs (OKPs) does make them quantitatively different than their legacy counterparts; and further allowing them to be compressed aligns better with the _concise_ nature of CBOR; _however_ encoding  points on the curve in anything other than the uncompressed form is highly unusual not only because the legacy version requires the uncompressed form but so many standards (e.g., RFC 5480) require support for the uncompressed form and neither require nor recommend support for the compressed form. This is further validated by your initial requirement that such IDs be encoded in the uncompressed form.

There is no such difference between `EdDSA` and `Ed25519`, however; as both seemingly require to be encoded as OKPs since I haven't seen any standard that defines an "uncompressed" encoding unlike curves like P-256. As a result, I'm still not convinced that adding them to the list of recommended `pubKeyCredParams` makes sense.

Last, I think it's _worse_ to remove the test vectors and examples for the new IDs but keep the recommended `pubKeyCredParams` since having test vectors and examples make it less likely for implementations to be wrong.
author_association: CONTRIBUTOR
user: login: emlun
created_at: 2025-05-21T10:13:50Z
body: > I will say that removing the restriction for `ESP*` IDs to allow them to be encoded as octet-key pairs (OKPs) [...]

COSE does not allow encoding `ESP*` keys with the OKP type. ECDSA public keys are required to use the EC2 key type; see [RFC 9053 §7.1. Elliptic Curve Keys](https://www.rfc-editor.org/rfc/rfc9053.html#name-elliptic-curve-keys) and [RFC 9053 §2.1. ECDSA](https://www.rfc-editor.org/rfc/rfc9053.html#section-2.1):

>When using a COSE key for this algorithm , the following checks are made:
>- The "kty" field MUST be present, and it MUST be "EC2".
>[...]

Only Edwards curve keys (currently) are allowed (and indeed required) to use OKP, and yes, [RFC 8032](https://www.rfc-editor.org/rfc/rfc8032.html) defines a single canonical encoding for EdDSA keys.

Rather, it's the EC2 key type that has two variants: compressed or uncompressed y coordinate.
author_association: MEMBER
user: login: emlun
created_at: 2025-05-21T11:53:54Z
body: I've now also reverted adding the new algs to recommendations and examples, per @akshayku's argument that if RPs should continue using the old values anyway, we should not recommend using the new ones.

I've still kept the restriction against point compression for `ESP*`, for consistency with `ES*`.
author_association: MEMBER
user: login: zacknewman
created_at: 2025-05-21T14:03:03Z
body: > COSE does not allow encoding ESP* keys with the OKP type. ECDSA public keys are required to use the EC2 key type

Indeed. Thanks for the correction. I assumed the reason the OKP parameter for the public key was called `x` was for curves like P-256 since the compressed point is represented as the x-coordinate with the y-coordinate parity bit in contrast to curves like ed25519 whose points are encoded as the y-coordinate with the x-coordinate parity bit thus `y` would be the more appropriate parameter name. That's what I get for not re-reading RFC 9053.
author_association: CONTRIBUTOR