Federation operations errors

[Giuseppe De Marco]

We have enabled the unsupported_parameter error in the PR below
https://bitbucket.org/openid/connect/pull-requests/348

Federation operations like entity discovery, trust chain validation, metadata policy application, may throws errors and exceptions.

An entity discovery process may be unexpectedly terminated for several reasons:
1. connection timeout
2. entity statements schema validation errors
3. exceeding of max_path_length or failure of any other costraints

A trust chain validation may incur in signature verification errors, a metadata policy may fail (and the final metadata couldn’t be acquired if a metadata policy produces an error or an exception).

For the previous reasons, as discussed in the previous editor’s call, we have decided to define some specialized errors for Federation operations.

[Michael Jones]

We discussed this on the 3-Nov-22 call. George cautioned against providing too much information about the parties in the errors.

George suggested the HTTP 504 Gateway Timeout error for connection timeout. But the party receiving the timeout may not be the party receiving the error.

George distinguished between errors made by the caller and other errors.

We requested specific error proposals be added to the issue.

[Giuseppe De Marco]

In which federation api endpoints an error may occur and of which nature the error can be?

authorization endpoint

• federation entity discovery http connection error → 302 redirect_uri with error type:

  • temporarily_unavailable if entity configuration OR federation api endpoint, at least one, is not reachable
  • invalid_request if the authz request is not valid

• trust chain validation → 401:

  • invalid_client if the validation fails

• metadata policy error (unable to get the final metadata) → 409 (Conflict)

  • invalid_client

explicit client registration endpoint

• the same of authorization endpoint without redirect_uri, this would be

  • federation entity discovery http connection error → temporarily_unavailable 503 or invalid_request 400

resolve endpoint

• subject not found → 404
• subject’s trust chain expired → 404

trust mark status

• subject not found → not_found 404
• subject’s trust chain expired → not_found 404

list endpoint (already covered)

• unsupported_param → if entity_type is not supported (400)

fetch endpoint

• lookup failed → not_found 404

‌

[Roland Hedberg]

Under authorisation endpoint if automatic registration the client authentication/proof-of-possesion may fail. → 401

During automatic or explicit registration - no common TA → 400 ??

I agree with George in that the error codes should not be too detailed.

[Vladimir Dzhuvinov]

Just a note that the authorization_endpoint, if approached with a request with an invalid client_id (what a trust chain validation or metadata policy error essentially means) MUST NOT redirect / return back to the client:

https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2.1

‌

‌

[Michael Jones]

I agree with Roland that we should not be overly specific with error codes. A way to think about this is conformance/certification tests.

There are times when the test code will look for a specific error code and fail the test if a different error code is used. When do we want/need to be that specific? Versus, when would it be better to say something like “An error code will be returned. Possibilities include x, y, and z.”?

[Giuseppe De Marco]

using specific status codes for errors would give a strategy to do automated tests, this reduces the human work
we’re looking for a good compromise to get some useful codes without giving to much information

[Michael Jones]

As discussed on the 13-Jan-23 Federation Editors' call, Giuseppe has been reaching out to those who had asked for additional error codes for specific recommendations. If he continues getting no responses, we’ll close this in a week.

[Giuseppe De Marco]

I did a check on the current status of the draft, I can say that:

1. The endpoints explicit client registration, fetch, listing, resolve, tm status do not present interpretative weaknesses, the interpretation of the errors for each endpoint is made intelligible by their specific sections and also by section “7.6. Generic Error Response”

2. The errors related to authorization endpoint, considering the automatic client registration, are addressed in the section 10.1.2. Authentication Error Response , that defines two specific error codes

If we agree this issue is ready to be closed if there are no further points or contributions by the middle of next week

[Michael Jones]

Giuseppe checked in with colleagues about this. Based on that, we believe that it’s fine to close this. Closing on the 20-Jan-23 Federation Editors' call.