The commit df2e9253c615f3e3a38b168dd86641d47f5bead7 contains the following changes:

• Included outbound interceptor flow call for error messages

• Refactored outbound interceptor flow to be run after response message has been built but before encoding

  • Previously the outbound interceptor flow was run before the response message was built: the new position in the flow makes more sense and is similar to SAML. This needs to be highlighted in the release-notes though.

• Refactored the end-session flow to inherit outbound interceptor flow states from the abstract oidc flow

The map values are ErrorObjects, so also descriptions can be customised. The default behaviour for non-mapped events is to use the error event string as description, so you probably mixed with that.

Ok. What I believe I noticed about the error mapping is that it allowed customzing the status code for the responses, but not the desciption, that appeared to be set to the error event string.

Is there really a significant sort of “message” in the error case?

Not really, at least in the usual cases. The error + description customisation can already be achieved via endpoint-specific error-mapping beans, such as shibboleth.oidc.authorize.MappedErrors.

The customer that reported about this problem was using the outbound interceptor -hook for wiring a custom code that reports the current state of PRC and the event that led to the error. The same code works for success/error SAML and success OIDC cases, and they'd like to use it for error OIDC cases too.

The messageHandler (https://shibboleth.atlassian.net/browse/JOIDC-211 ) offers probably a simpler hook for the same purpose, but they still use IdP4 and corresponding OP plugin.

Is there really a significant sort of “message” in the error case?

With SAML, a full response is generated (sometimes), so that’s a lot of XML to potentially manipulate.

If this is about customizing the error itself, I think this is probably better viewed as a RFE to be able to modify the description that goes out. From what I could tell, it puts the error event into the description field. Possibly we should support running that through the Sring message layer to access a description value to use.