[keycloak - OID4VCI] Make signature-algorithm selectable

[francis-pouatcha]

This is a proxy of:

• [OID4VCI] Make signature-algorithm selectable keycloak/keycloak#32958

[IngridPuppet]

The description on the source ticket reads:

OpenID4VCI supports several signature algorithms. By default we should use the active key of keycloak to sign credentials, but we should also allow to override the key-usage in the ClientScopes configuration model by referencing another available key in Keycloak that is then used instead of the active key.

Let us break it down:

1. OpenID4VCI supports several signature algorithms.
2. By default we should use the active key of keycloak to sign credentials.
3. But we should also allow to override the key-usage in the ClientScopes configuration model by referencing another available key in Keycloak.

OpenID4VCI makes indeed a case for a credential issuer to support several signature algorithms, which should be communicated by the credential_signing_alg_values_supported entry on the Credential Issuer Metadata endpoint.

On point 2, the current state of Keycloak's implementation already uses the active key "by default" for signing.

https://github.com/keycloak/keycloak/blob/aaade6caab70cc0f461e2062b7cb2d7817359226/services/src/main/java/org/keycloak/protocol/oid4vc/issuance/signing/SigningService.java#L61-L75

    /**
     * Returns the key stored under kid, or the active key for the given jws algorithm,
     *
     * @param kid
     * @param algorithm
     * @return
     */
    protected KeyWrapper getKey(String kid, String algorithm) {
        // Allow the service to work with the active key if keyId is null
        // And we still have to figure out how to proceed with key rotation
        if (keyId == null) {
            return keycloakSession.keys().getActiveKey(keycloakSession.getContext().getRealm(), KeyUse.SIG, algorithm);
        }
        return keycloakSession.keys().getKey(keycloakSession.getContext().getRealm(), kid, KeyUse.SIG, algorithm);
    }

That takes us to Point 3 about overriding this default key for signing.

• Isn't that already covered by the signing services having the possibility to be configured with an alternative key ID?
• How different is the current overriding mechanism from the "ClientScopes configuration model" suggested?
• Is the mention of overriding the "key-usage" in the description meaning to consider keys not annotated with KeyUse.SIG?

CC: @francis-pouatcha

[IngridPuppet]

Sync conclusions:

• The ticket is dependent on [OID4VCI] Create CredentialSignerProvider interface keycloak/keycloak#32953, which will likely make it necessary again to re-approach how we override signing keys.
• The best placement for the keyID config is as part of the CredentialBuildConfig associated with each credential.

[IngridPuppet]

This ticket is likely to be closed with the changes of #9.