[Federation] Specify resolve error responses

Giuseppe De Marco

yes, we need a section like “Resolve Response Errors“ and my proposal would be simply return an HTTP status code 404 with nothing in the body, enabling the possibility to serve the resolve responses as a static content and at the same time without giving any kind of information gathering about the resolution processes behind the endpoint.

I don’t want to exclude the possibility to have instead an application/json object if the blank body wouldn’t seem a correct approach in the OAuth2 ecosystem, so the discussion is open

‌

2022-10-10T17:56:52+00:00

Vladimir Dzhuvinov reporter

I noticed that section 7.5 defines a “generic error response” format, but it is referenced only by the fetch entity response section and by no other of the API calls:

https://openid.net/specs/openid-connect-federation-1_0.html#section-7.5

A static 404 page for the resolve endpoint could still include a body, e.g. with a JSON object (provided the underlying web framework supports such static web pages to be defined). Sometimes developers find this useful to assure them they are hitting the right endpoint. But we also have to bear in mind that not all errors can be caught, so for the “the response body MUST be a JSON object”, I would prefer the more practical SHOULD.

2022-10-11T07:06:53+00:00

Giuseppe De Marco

Probably you’re suggesting to have a specialized section dedicated to the federation errors, as made for rfc6749
https://www.rfc-editor.org/rfc/rfc6749#section-5.2

2022-10-13T00:28:20+00:00

Vladimir Dzhuvinov reporter

I think Roland had the 7.5 section added because he liked the std OAuth 2.0 error format so much (I also do) and it can be a good aid to developers and client software in some cases (as opposed to returning an HTTP status code with no body).

I wasn’t suggesting a list that defines std error codes. I’m unsure this will benefit us much, unless we have error states where the software can perform some reasonable action to recover. What do you think, based on the impl work that you’ve done?

2022-10-13T06:27:30+00:00

Michael Jones

I agree that we should use the Generic Error Response (the OAuth 2 error pattern) wherever applicable.

2022-10-14T05:20:25+00:00

Giuseppe De Marco

We made some improvements in the text with the PR below, that defines better the responses content types and http status codes, including a ref to the generic error response section:
https://bitbucket.org/openid/connect/pull-requests/323

in relation of this specific issue, here the text:
https://bitbucket.org/openid/connect/pull-requests/323#Lopenid-connect-federation-1_0.xmlF2604T2607

considering the work made in the previous pull request and if I understand your suggestion, should we add more detailed error_codes for the federation error responses?

I mean a concrete mapping of the federation errors with the following and well known oauth2 errors: