If we're introducing error libraries - as per #41, we shouldn't have separate libraries for domain/model/handler. A single error library might be more useful to call from across the auth-service.
As per discussion with @lewisdaly

@Lewis Daly @kevin Leyow @sam @michael Richards @JJ Geewax
I am preparing some changes in PISP API to be compatible for webauthn based assertion (attestation for credential registration in linking flow is already done)

Starting from client webauthn api https://webauthn.guide/#authentication

The problem which I see is that there is a need to pass allowCredentials structure in navigator.credentials.get call. From docs it comes out that server should be responsible to generate allowCredentials entries to enforce using already registered credential and transports

Are we expecting auth-service will do it or pisp-demo/client -> but still credentialId should be used as part of payload for POST /thirdpartyRequests/authorization ? I suggest to add credentialId and transports fields as a part of payload: https://github.com/mojaloop/api-snippets/blob/master/thirdparty/openapi3/components/schemas/ThirdpartyRequestsAuthorizationsPostRequest.yaml

2. Passing assertion for verification to auth-service via PUT /thirdpartyRequests/authorizations/ID Assertion has structure PublicKeyCredential which is quite complex and differs a lot from U2FPinValue we already have defined: https://github.com/mojaloop/api-snippets/blob/master/thirdparty/openapi3/components/schemas/U2FPinValue.yaml

I suggest replacing U2FPinValue with PublicKeyCredential so all necessary for assertion parameters can be delivered to auth-service.

In config.ts, there is no way to configure the endpoints that get passed through to the sdk-standard-components (see here).

We need to expose these configuration options so that the auth-service can talk to the switch.

@MichaelJBRichards @jgeewax @lewisdaly @bushjames @elnyry-sam-k

We need to agree on the pattern of how we should return HTTP status codes when doing validation of complex requests. For example in POST /thirdpartyRequests/transactions/{ID}/authorizations we have request payload body defined as

export interface AuthPayload {
  consentId: string;
  sourceAccountId: string;
  status: 'PENDING' | 'VERIFIED';
  challenge: string;
  value: string;
}

the code: https://github.com/mojaloop/auth-service/pull/22/files#diff-7da2816b4c61411199493eb4e1667117

we already have payload validated according open-api specification and if needed 400 (Bad Request) status code is return
and we are doing some domain-specific semantic validations, like

• if Consent for givenconsentId has the proper status
• if there are matching Scopes for Consent

here the question arises: should we return 404 (Not Found) if there is nothing in our store or 400 (Bad Request),
or maybe 422 (Unprocessable entity) because we have valid request body - open-api schema validation is successful, so Bad Request is not applicable because there is no syntax error.
404 is also not applicable - it should be used when the server has not found anything matching the Request-URI - and the URI is valid.

PROPOSED Pattern:
400 (BadReqeust) only for request syntax errors
404 (Not Found) when the Request-URI is invalid and also if any resource referenced by URL parameter can't be found in store
422 (Unprocessable entity) when semantic validation fails: any resource referenced in payload body can't be found or can't be used to fulfill the request (not enough data properties, not expected internal state not found related entities and so on)

I am assigning the issue to @MichaelJBRichards because he is a member of the API control board and I believe this decision should get approval from the board.

There is a need to improve test readability across auth-service to make it more clear.
Additionally, more tests are needed for the following cases:

• Where generatePatchConsentRequest is called with ACTIVE Consent argument
• Where revokeConsentStatus is called with REVOKED Consent argument
• Seed with data with REVOKED consent status + add tests for revoke related logic'

Furthermore, we want to create a central data file for all mocked resources used in unit tests.