[has-PR] Missing Error Responses

[David W Chadwick]

The current OIDC4VCI protocol does not contain a full list of error responses. PR#299 adds them.

[Kristina Yasuda]

David, please delete a PR and first list proposed error responses in this issue so that the WG can discuss and agree on them first.

We will be declining PRs that come without issues in the future. PRs are for when we believe we have a concrete proposal how to resolve an issue, and issues are to discuss issues, and it may or may not lead to a PR depending whether there is an agreement or not. thank you.

[David W Chadwick]

I think this issue is pretty uncontroversial as the current text says “to do”. We are currently writing POSTMAN conformance tests and we need to define appropriate error responses for testing implementations. The proposed error codes in the PR are as follows.

• invalid_request - the credential request was malformed
• invalid_token - the access_token was invalid
• unsupported_type - the requested type is not supported
• unsupported_format - the requested format is not supported
• invalid_credential - the requested credential did not match any of the credentials to be issued
• invalid_or_missing_proof - see next section

I would have thought that discussions on refinement of this list could take place equally well in the issue or the PR, so deleting the PR sounds like a bit of administrative overkill to me

[Thomas Bellebaum]

Should we have a registry for these to allow for future extensions?

[David W Chadwick]

We have now written a set of Postman tests for the issuer and below are the error responses that we propose. Some of the errors can utilise the existing OAuth2 errors, but it might be helpful to add some explanatory notes for these, particularly concerning the use of the PIN with the pre-authz flow (which currently is not specifically covered by the OAuth2 spec).

Requests to Token Endpoint for Pre-Authz code

Test 1. Pre-authz flow initialised without a PIN  - authentication server does not expect PIN but client provides a PIN. The result could either be 200 OK (assuming everything else is OK and the authz server ignores the PIN) or it could be 400 Bad request with   "error": "invalid_request". What do people suggest?

Test 2. Pre-authz flow initialised with a PIN - user provides the wrong PIN. This could be 400 Bad request with   "error": "invalid_request" or “invalid_grant”

Test 3. Pre-authz flow initialised with a PIN - user does not provide a PIN. This could be 400 Bad request with   "error": "invalid_request"

Test 4. Pre-authz flow - user provides the wrong pre-authz code or correct code which has expired. This could be 400 Bad request with   "error": “invalid_grant”

Request to Resource server (credentials endpoint)

Test 5. The client provides the wrong credential type. This could be 400 Bad request with   "error": "unsupported_type"

Test 6. The client does not provide the credential type and/or the format and/or the proof.  This could be 400 Bad request with "error": "invalid_request".

Test 7. The client provides the wrong or unsupported format. This could be 400 Bad request with "error": "unsupported_format"

Test 8. Missing or wrong access_token. This could be 401 Unauthorized

Test 9. The client provides the wrong proof (signature does not compute). This could be 400 Bad request with    "error": invalid_or_missing_proof"

[Torsten Lodderstedt]

Test 1. Pre-authz flow initialised without a PIN  - authentication server does not expect PIN but client provides a PIN. The result could either be 200 OK (assuming everything else is OK and the authz server ignores the PIN) or it could be 400 Bad request with   "error": "invalid_request". What do people suggest?

I would lean towards 200. However, there might be security reasons to refuse processing. @Daniel Fett what do you think?

Test 2. Pre-authz flow initialised with a PIN - user provides the wrong PIN. This could be 400 Bad request with   "error": "invalid_request" or “invalid_grant”

I guess RFC 6749 limits us to 400 (even though I would lean towards 401 ;-)).

Test 3. Pre-authz flow initialised with a PIN - user does not provide a PIN. This could be 400 Bad request with   "error": "invalid_request"

see above

Test 4. Pre-authz flow - user provides the wrong pre-authz code or correct code which has expired. This could be 400 Bad request with   "error": “invalid_grant”

yep

Request to Resource server (credentials endpoint)

Test 5. The client provides the wrong credential type. This could be 400 Bad request with   "error": "unsupported_type"

agree

Test 6. The client does not provide the credential type and/or the format and/or the proof.  This could be 400 Bad request with "error": "invalid_request".

yep

Test 7. The client provides the wrong or unsupported format. This could be 400 Bad request with "error": "unsupported_format"

I agree for unsupported format.

what does wrong format mean?

Test 8. Missing or wrong access_token. This could be 401 Unauthorized

yep

Test 9. The client provides the wrong proof (signature does not compute). This could be 400 Bad request with    "error": invalid_or_missing_proof"

same as client does not provide proof of possession at all

‌

[David W Chadwick]

Thanks for these. This makes it much easier now to update the PR

[Kristina Yasuda]

in general +1 to Torsten’s responses with few comments.

Test 2. Pre-authz flow initialised with a PIN - user provides the wrong PIN. This could be 400 Bad request with   "error": "invalid_request" or “invalid_grant”

invalid_request sounds right.

Test 5. The client provides the wrong credential type. This could be 400 Bad request with   "error": "unsupported_type"

I would prefer a more explicit unsupported_credential_type .

Test 7. The client provides the wrong or unsupported format. This could be 400 Bad request with "error": "unsupported_format"

I would prefer a more explicit unsupported_credential_format .

guess wrong format is when format string is malformed? which should probably be invalid_request ?

‌

‌

‌

[Daniel Fett]

I would recommend to send an error when a PIN was provided but not requested. There’s no need to be lenient here - this might indicate that an attacker is messing with the flow.

[Kristina Yasuda]

agreement was around `invalid_or_missing_proof`, David introduced `invalid_or_missing_nonce. I reverted to `invalid_or_missing_nonce`, but if we agree we want to add `invalid_or_missing_nonce` too, we can do so in another PR

[David W Chadwick]

I have created issue#1699 so that we can discuss this issue and decide what to do

[Kristina Yasuda]

PR merged

[Kristina Yasuda]

was PR #299