Open awoie opened 5 months ago
Hi @awoie ,
I believe that proof_signing_alg_values_supported
should be defined, as needed, for each proof type (jwt, cwt & ld_vp), The general section is confusing (since a reader could miss paragraph 7) and perhaps should be removed.
Similarly, credential_signing_alg_values_supported
should be format specific.
Hi @awoie ,
I believe that
proof_signing_alg_values_supported
should be defined, as needed, for each proof type (jwt, cwt & ld_vp), The general section is confusing (since a reader could miss paragraph 7) and perhaps should be removed.Similarly,
credential_signing_alg_values_supported
should be format specific.
Fully agree.
Consensus on today's WG call that we would have only the name defined in the credential-format-independent part of the spec (i.e. we would no longer say they are strings), and the credential formats would define credential_signing_alg_values_supported
type and values, and the proof formats section would do the same for proof_signing_alg_values_supported
.
I believe we also got consensus that COSE algorithms should be described by integers, because even though there are string names defined as per https://www.rfc-editor.org/rfc/rfc8152#section-16.4 the integer values as per https://www.iana.org/assignments/cose/cose.xhtml#algorithms are the thing that should be used.
Both
credential_signing_alg_values_supported
andproof_signing_alg_values_supported
are defined in the general section of OID4VCI Issuer Metadata and are currently defined as array of String values. While this is possible for JOSE algorithms, it is not possible for COSE algorithms.Either make both polymorphic with the type depending on the format, or just make them format-specific parameters.