Improve logging around /register endpoint methods

[BohoCode]

We have had a few customer issues where it has been impossible to determine why TPPs were having trouble with these endpoints. Logging needs to be sufficient to allow us to determine why a specific call resulted in an OBErrorReponseException is called.

We aslo need to make sure that there is sufficient granularity and information in the OBErrorResponseExceptions to make sure that TPPs can easily diagnose why a call failed. This will reduce support effort for our customers, and also the support load on our team from our customers.

[BohoCode]

From the OB DCR 3.3 spec (https://openbankinguk.github.io/dcr-docs-pub/v3.3/dynamic-client-registration.html#error-structure)

In the case where the ASPSP makes a negative determination and refuses to create a client, the ASPSP MUST return a client registration error response to the TPP conforming to Section 3.2.2 of RFC7591.

From section 3.2.2 of RFC7591

3.2.2. Client Registration Error Response

When an OAuth 2.0 error condition occurs, such as the client presenting an invalid initial access token, the authorization server returns an error response appropriate to the OAuth 2.0 token type.

When a registration error condition occurs, the authorization server returns an HTTP 400 status code (unless otherwise specified) with content type "application/json" consisting of a JSON object [RFC7159] describing the error in the response body.

Two members are defined for inclusion in the JSON object:

error REQUIRED. Single ASCII error code string.

error_description OPTIONAL. Human-readable ASCII text description of the error used for debugging.

Other members MAY also be included and, if they are not understood, they MUST be ignored.

This specification defines the following error codes:

invalid_redirect_uri The value of one or more redirection URIs is invalid.

invalid_client_metadata The value of one of the client metadata fields is invalid and the server has rejected this request. Note that an authorization server MAY choose to substitute a valid value for any requested parameter of a client's metadata.

invalid_software_statement The software statement presented is invalid.

unapproved_software_statement The software statement presented is not approved for use by this authorization server.

The following is a non-normative example of an error response resulting from a redirection URI that has been blacklisted by the authorization server (with line breaks within values for display purposes only):

 HTTP/1.1 400 Bad Request
 Content-Type: application/json
 Cache-Control: no-store
 Pragma: no-cache

 {
  "error": "invalid_redirect_uri",
  "error_description": "The redirection URI
    http://sketchy.example.com is not allowed by this server."
 }

The following is a non-normative example of an error response resulting from an inconsistent combination of "response_types" and "grant_types" values (with line breaks within values for display purposes only):

 HTTP/1.1 400 Bad Request
 Content-Type: application/json
 Cache-Control: no-store
 Pragma: no-cache

 {
  "error": "invalid_client_metadata",
  "error_description": "The grant type 'authorization_code' must be
    registered along with the response type 'code' but found only
   'implicit' instead."
 }

[BohoCode]

Swagger spec for OB DCR 3.3;

https://github.com/OpenBankingUK/client-registration-api-specs/releases/tag/v3.3

[BohoCode]

From RFC 7591 above;

When an OAuth 2.0 error condition occurs, such as the client presenting an invalid initial access token, the authorization server returns an error response appropriate to the OAuth 2.0 token type.

The OAuth2 Spec has this to say about error handling for the authenication header field and error codes

3. The WWW-Authenticate Response Header Field

   If the protected resource request does not include authentication credentials or does not contain an access token that enables access to the protected resource, the resource server MUST include the HTTP "WWW-Authenticate" response header field; it MAY include it in response to other conditions as well. The "WWW-Authenticate" header field uses the framework defined by HTTP/1.1 [RFC2617].

   All challenges defined by this specification MUST use the auth-scheme value "Bearer". This scheme MUST be followed by one or more auth-param values. The auth-param attributes used or defined by this specification are as follows. Other auth-param attributes MAY be used as well.

   A "realm" attribute MAY be included to indicate the scope of protection in the manner described in HTTP/1.1 [RFC2617]. The "realm" attribute MUST NOT appear more than once.

   The "scope" attribute is defined in Section 3.3 of [RFC6749]. The "scope" attribute is a space-delimited list of case-sensitive scope values indicating the required scope of the access token for accessing the requested resource. "scope" values are implementation defined; there is no centralized registry for them; allowed values are defined by the authorization server. The order of "scope" values is not significant. In some cases, the "scope" value will be used when requesting a new access token with sufficient scope of access to utilize the protected resource. Use of the "scope" attribute is OPTIONAL. The "scope" attribute MUST NOT appear more than once. The "scope" value is intended for programmatic use and is not meant to be displayed to end-users.

   Two example scope values follow; these are taken from the OpenID Connect [OpenID.Messages] and the Open Authentication Technology Committee (OATC) Online Multimedia Authorization Protocol [OMAP] OAuth 2.0 use cases, respectively:

   scope="openid profile email" scope="urn:example:channel=HBO&urn:example:rating=G,PG-13"

   If the protected resource request included an access token and failed authentication, the resource server SHOULD include the "error" attribute to provide the client with the reason why the access request was declined. The parameter value is described in Section 3.1. In addition, the resource server MAY include the "error_description" attribute to provide developers a human-readable explanation that is not meant to be displayed to end-users. It also MAY include the "error_uri" attribute with an absolute URI identifying a human-readable web page explaining the error. The "error", "error_description", and "error_uri" attributes MUST NOT appear more than once.

   Values for the "scope" attribute (specified in Appendix A.4 of [RFC6749]) MUST NOT include characters outside the set %x21 / %x23-5B / %x5D-7E for representing scope values and %x20 for delimiters between scope values. Values for the "error" and "error_description" attributes (specified in Appendixes A.7 and A.8 of [RFC6749]) MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E. Values for the "error_uri" attribute (specified in Appendix A.9 of [RFC6749]) MUST conform to the URI-reference syntax and thus MUST NOT include characters outside the set %x21 / %x23-5B / %x5D-7E.

   For example, in response to a protected resource request without authentication:

   HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm="example" And in response to a protected resource request with an authentication attempt using an expired access token:

   HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm="example", error="invalid_token", error_description="The access token expired"

3.1. Error Codes

When a request fails, the resource server responds using the appropriate HTTP status code (typically, 400, 401, 403, or 405) and includes one of the following error codes in the response:

invalid_request The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats the same parameter, uses more than one method for including an access token, or is otherwise malformed. The resource server SHOULD respond with the HTTP 400 (Bad Request) status code.

invalid_token The access token provided is expired, revoked, malformed, or invalid for other reasons. The resource SHOULD respond with the HTTP 401 (Unauthorized) status code. The client MAY request a new access token and retry the protected resource request.

insufficient_scope The request requires higher privileges than provided by the access token. The resource server SHOULD respond with the HTTP 403 (Forbidden) status code and MAY include the "scope" attribute with the scope necessary to access the protected resource.

If the request lacks any authentication information (e.g., the client was unaware that authentication is necessary or attempted using an unsupported authentication method), the resource server SHOULD NOT include an error code or other error information.

For example:

 HTTP/1.1 401 Unauthorized
 WWW-Authenticate: Bearer realm="example"

[jsanhc]

done