LGTM, but are you sure deviceAuth.deviceSignature.algName is an appropriate default? I couldn’t find any reference to it in the ISO doc.

After taking a second look and going though the spec, it might not be appropriate default. I am not sure if newer versions of cose-kit and jose are able to handle the missing alg value. Maybe updating these would make sense?

Another alternative is maybe to create a derive function for alg based on other key parameters:

1. If kty is EC (Elliptic Curve):
   • If crv specifies P-256 or brainpoolP256r1, the corresponding signature algorithm is ES256.
   • If crv specifies P-384, brainpoolP320r1, or brainpoolP384r1, the corresponding signature algorithm is ES384.
   • If crv specifies P-521 or brainpoolP512r1, the corresponding signature algorithm is ES512.
2. If kty is OKP (Octet Key Pair):
   • If crv specifies Ed25519/X25519 or Curve448/X448, the corresponding signature algorithm is EdDSA.

WDYT?

The thing is, the alg param is optional, we shouldn't use a default value. From RFC 8152:

alg:  This parameter is used to restrict the algorithm that is used
      with the key.  If this parameter is present in the key structure,
      the application MUST verify that this algorithm matches the
      algorithm for which the key is being used.  If the algorithms do
      not match, then this key object MUST NOT be used to perform the
      cryptographic operation.  Note that the same key can be in a
      different key structure with a different or no algorithm
      specified; however, this is considered to be a poor security
      practice.

I think the problem is that we are trying to convert the COSE key to JWK, and that’s where the jose library is failing. We should find a way to perform "ECDSA/EdDSA authentication" without that intermediate step.

That is true but it does not mean the cose and jose implementations are incorrect and should be replaced.

In the ISO 18013-5 under section 9.1.2.4, there is clarification:

The issuing authority infrastructure shall use one of the following signature algorithms for calculating
the signature over the MSO: “ES256” (ECDSA with SHA-256), “ES384” (ECDSA with SHA-384),
“ES512” (ECDSA with SHA-512) or “EdDSA” (EdDSA). ”ES256” shall be used with curves P-256 and
brainpoolP256r1. “ES384” shall be used with curves P-384, brainpoolP320r1 and brainpoolP384r1.
“ES512” shall be used with curves P-521 and brainpoolP512r1. “EdDSA” shall be used with curves
Ed25519 and Ed448. For verifying the signature, the mdoc reader shall support all of these signature
algorithms and curves.

The explicit omission of the 'alg' property is because the 'alg' property is to be derived by the 'crv' property.

I have update the implementation to depend on mapping. @siacomuzzi please re-review. Because the setup of the project is bit legacy, i was not able to setup the tests to run in browser env with jsdom. Maybe this is something worth exploring for you as most of the projects that will use this library will be ESM modules (see #34)

This could be valid way forwards, there the 'alg' is being adopted from the COSE_Sign1 and cross-checked with the 'crv' that is being supported.

Just keep in mind that the new validation will involve a breaking change in the library. Additionally, we should perform a similar validation in other parts of the lib.

To make things simpler and less back-and-forth, would it make more sense for you to make the final changes to the library?

I can introduce the fix for the default alg value to unblock you, but unfortunately, we currently don’t have the proper resources and time for the other change. It requires proper review, implementation, testing, etc.

#64