Differences in error handling between Tech Specs and Conformance Test Document

[schuur]

Feedback from @raimundo-henriques (SINE): Working on our automated conformance testing tool, we noticed a couple of things in the Conformance Testing Checklist that you might want to look into. These concern Test Case 001 and Test Case 002.

Test Case 001
The expected response, currently reads:

400 Bad Request and a JSON body containing an error, as specified in [PACT Tech Specs V2.2 § api-error-responses](https://wbcsd.github.io/data-exchange-protocol/v2/#api-error-responses In this case, the testing party must execute the test case [§ 6.3 Test Case 016: OpenId Connect-based Authentication Flow](https://wbcsd.github.io/pact-conformance-testing/checklist.html#tc016

But this conflicts with the description of Action Authenticate, where the only error response admitted is one conformant with RFC6749:

AuthResponseBody
A JSON Object conforming to either RFC 6749 Section 4.4 in case of successful authentication (containing an access token), or RFC 6749 Section 5.2 otherwise. See [§ 8.3 Authentication Flow](https://wbcsd.github.io/data-exchange-protocol/v2/#api-auth for further details

Thus, currently, Test Case 001 allows the API's Action Authenticate to respond in a manner that would violate Tech Specs.
This issue was introduced when [this line was changed](https://github.com/wbcsd/pact-conformance-testing/pull/27/files#diff-ce705bbc271caed559aa36436d397dd810027cbfa2f664677734d2a8249e4253L112 as part of a bigger PR. Therefore, a simple fix would be to revert it to the previous version, having it read:

400 Bad Request and a JSON body containing an error, as specified in [PACT Tech Specs V2.2 § action-api-auth-reponse](https://wbcsd.github.io/data-exchange-protocol/v2/#api-action-auth-response In this case, the testing party must execute the test case [§ 6.3 Test Case 016: OpenId Connect-based Authentication Flow](https://wbcsd.github.io/pact-conformance-testing/checklist.html#tc016

[Test Case 002](https://wbcsd.github.io/pact-conformance-testing/checklist.html#tc002
As of right now, this test case covers only "incorrect credentials (i.e. the client id and/or client secret are unknown to the [target host system](https://wbcsd.github.io/pact-conformance-testing/checklist.html#target-host-system This means that the following scenarios are covered: (i) unknown client, known secret; (ii) known client, unknown secret; (iii) unknown client, unknown secret.

We would like to propose the two additional scenarios to your consideration:
(iv) malformed credentials, i.e., the credentials do not follow the BasicAuth formatting (e.g., are not base64-encoded; grant_type is not set to client_credentials, etc.);
(v) no headers, i.e., the post request is made with no headers whatsoever (making authentication impossible).

These cases follow from the requirements of the Tech Specs and would guarantee that the system under test is able to deal with them in an adequate fashion.

[raimundo-henriques]

Thank you!