.well-known-config compliance with system capabilities

[emswbandara]

In the current implementation, the data available in the .well-known config does not comply with the system's actual capabilities. We currently provide some hard-coded values in the response. E.g for token_endpoint_auth_methods_supported element we provide the following values in the response.

values:
"token_endpoint_auth_methods_supported": [
        "client_secret_basic",
        "client_secret_post"
    ] 

However we have the capability to plug in additional auth methods such as private-key-jwt, tls-client-auth. Since in the above response, as the auth-methods are hard-coded, it does not provide the updated values if we plug in additional handlers.

Furthermore, as per the OB security spec [1] , request_object_signing_alg_values_supported should be configurable. It should be possible to restrict the usage of specific algorithms. Currently it is not possible to configure/restrict the signing algorithms. Aslo in the .well-known response we provide these as hard-coded values.

Therefore we need to provide a solution to configure these values from an external config file. The APIs that consume these configurable values should publish them to a config registry which will hold the data as key- value pairs indicating the system capabilities. Then, when generating the .well-known config, it should read the values from the config registry and generate the response data.

[1] https://openbanking.atlassian.net/wiki/spaces/DZ/pages/83919096/Open+Banking+Security+Profile+-+Implementer+s+Draft+v1.1.2

[boardbloke]

The values that I have spotted are as follows:

request_uri_parameter_supported Currently is not returned by .well-known-config. The default value according to OIDC RFC (https://openid.net/specs/openid-connect-discovery-1_0.html) is "true", but IS doc for 5.7 indicates it is not supported (https://docs.wso2.com/display/IS570/Request+Object+Support), so false should be returned

request_object_signing_alg_values_supported As documented above the well-known config values are hard-coded by need to be driven from configuration of the signing values that are allowed - PS256 and RS256 are mandated by OB

token_endpoint_auth_methods_supported Similarly

token_endpoint_auth_signing_alg_values_supported Not required by OIDC, but it would be good if IS returned the allowed values.

Validation Note I do not believe the best solution to this problem is to have a separate config file that drives what is returned for .well-known-config. Ideally the values in .well-known-config should be emergent based on what is algorithms and capabilities are configured in identity.xml. That is, it should not be possible for IS to publish capabilities in .well-known-config that are not actually available. It should also be the case that if a client attempts to use a capability NOT published in the .well-known-config then they get a validation error (to reflect the fact that the capability is not available)