Update handling of `MsoMdocCredential.credentialSigningAlgorithmsSupported`

[dzarras]

When the library parses an MSO MDoc Credential Configuration and converts it to a domain object, it tries to convert the COSE Algorithm Identifiers in credential_signing_alg_values_supported to COSE Algorithm names (reference). Whenever an unknown COSE Algorithm Identifier is encountered it is simply discarded.

Currently the library supports only:

• -7 (ES256)
• -35 (ES384)
• -36 (ES512)

and support for additional COSE Algorithm Identifiers must be explicitly added in the code.

For Credential Configuration of other Credential Formats, the library simply passes through the identifiers present in credential_signing_alg_values_supported as is. The same behavior should apply to MSO MDoc Credential Configurations as well.

To that end, the following is proposed:

• Remove credentialSigningAlgorithmsSupported from CredentialConfiguration
• Define credentialSigningAlgorithmsSupported in MsoMdocCredential as List<CoseAlgorithm>
• Define credentialSigningAlgorithmsSupported in SdJwtVcCredential as List<JwsAlgorithm>
• Define credentialSigningAlgorithmsSupported in W3CSignedJwtCredential as List<JwsAlgorithm>
• Define credentialSigningAlgorithmsSupported in W3CJsonLdDataIntegrityCredential as List<LinkedDataAlgorithm>
• Define credentialSigningAlgorithmsSupported in W3CJsonLdSignedJwtCredential as List<LinkedDataAlgorithm>

where:

data class CoseAlgorithm(val value: Int)
data class JwsAlgorithm(val name: String)
data class LinkedDataAlgorithm(val id: String)

and wrap the values as needed without performing any filtering or conversion.

[dzarras]

@babisRoutis , @vafeini , @gdimtsas What do you think?

[babisRoutis]

@dzarras That's a nice improvement.

The attribute credentialSigningAlgorithmsSupported is common across credential configuration of different formats, but its content is not. Thus there is no good reason to keep to the parent CredentialConfiguration

In theory, we could make CredentialConfiguration parameterized to the signing algorithm type, but it doesn't add any value compared to your proposal

Let's proceed with your proposal

[dzarras]

Alternatively, we can introduce the following:

sealed interface Algorithm
value class CoseAlgorithm(val value: Int) : Algorithm
value class JwsAlgorithm(val name: String) : Algorithm
value class LinkedDataAlgorithm(val identifier: String) : Algorithm

and update as follows:

• Define credentialSigningAlgorithmsSupported in CredentialConfiguration as List<Algorithm>
• Define credentialSigningAlgorithmsSupported in MsoMdocCredential as List<CoseAlgorithm>
• Define credentialSigningAlgorithmsSupported in SdJwtVcCredential as List<JwsAlgorithm>
• Define credentialSigningAlgorithmsSupported in W3CSignedJwtCredential as List<JwsAlgorithm>
• Define credentialSigningAlgorithmsSupported in W3CJsonLdDataIntegrityCredential as List<LinkedDataAlgorithm>
• Define credentialSigningAlgorithmsSupported in W3CJsonLdSignedJwtCredential as List<LinkedDataAlgorithm>

This way, we enforce that each CredentialConfiguration implementation has credentialSigningAlgorithmsSupported, each implementation specializes the type of Algorithm it uses, and we don't have to introduce generics into the mix.

Check the update PR #490

[babisRoutis]

@dzarras Please don't introduce this sealed interface.