How does an issuer decide which alg from`credential_signing_alg_values_supported` to use

[nemqe]

If we publish Issuer Metadata that contains a credential configuration with the following:

"credential_signing_alg_values_supported": [
                "ES256", "ES256K", "RS256"
            ]

how do we know which signature alg to use when signing the credential for a particular wallet?

Is there a mechanism where the wallet chooses one of the supported values that I am missing in the spec, or is this out of scope and should be handled on some other level?

Thank you

[babisRoutis]

Hi @nempat

In the absence of a relevant parameter from issuance request, I don't see a way that would allow wallet to peek a specific algorithm.

To my understanding, credential_signing_alg_values_supported attribute can be used by a wallet before issuance, to check whether it (the wallet) would be able to verify issuer's signature on a issued credential.

[tplooker]

Hi @nempat essentially it's at the issuers discretion which algorithm it uses in the credential, this metadata is only used to indicate to a wallet what the issuer supports.

[nemqe]

@tplooker @babisRoutis thank you for the answers!

Just a follow up, do we expect this to change in the future where a client will be the one choosing a particular value from the list?

[babisRoutis]

Just a follow up, do we expect this to change in the future where a client will be the one choosing a particular value from the list?

Hi @nempat
Personally, I cannot provide an answer to this question 😄

May I ask though we you think it should?

A wallet should be prepared to interact (in general) with multiple issuers (perhaps not known beforehand) and each of those issuers may have its own selection of supported algs. To address this, wallet can have a similar configuration/policy with regards to which algs supports and stop early the issuance if there isn't a common ground (wallet-to-issuer policy).

[nemqe]

@babisRoutis

Can't say I have a strong opinion regarding weather the wallet should be able to choose, but at the same time I am not sure how much sense it makes for an issuer to list multiple options it supports only to randomly pick one or the other (or always use the same one) in the end.

If there is a list of options I would expect some mechanism of being able to pick a particular one. So I would say that the semantics of this structure do not match my expectations.

I will try to give an artificial example below for a scenario where this might be useful, but I have to preface this that the reality of things might be a bit different as it is a cross ecosystem (cross interop) scenario.

Maybe we have an Issuer that supports issuing JWT credentials and can sign them using any of the JOSE supported algs, but on the other side we have a Wallet that wants to present this credential to a Verifier that only supports ES256.

[babisRoutis]

@babisRoutis

I am not sure how much sense it makes for an issuer to list multiple options it supports

Neither am I.

Maybe we have an Issuer that supports issuing JWT credentials and can sign them using any of the JOSE supported algs, but on the other side we have a Wallet that wants to present this credential to a Verifier that only supports ES256.

Sounds reasonable. On the other hand, I guess that verifiers should support a broad range of algorithms to be "attractive" for wallets

[nikosft]

Hi,
In my opinion it does not make sense just to enumerate algorithms there without allowing wallets to indicate which algorithms they support. This will become even more obvious when PQ signing algorithms will be added in this list. OIDC dynamic client registration has this option id_token_signed_response_alg In my opinion something similar should be added in section 12.1