Required certification behaviour for request and request_uri parameters

[Joseph Heenan]

I’m unclear how to interpret this section of https://openid.net/wordpress-content/uploads/2018/06/OpenID-Connect-Conformance-Profiles.pdf :

In particular what “no err” means, given this text in the standard:

Support for the request parameter is OPTIONAL. The request_parameter_supported Discovery result indicates whether the OP supports this parameter. Should an OP not support this parameter and an RP uses it, the OP MUST return the request_not_supported error.

The possible interpretations (for a server that doesn’t support request objects) seem to be:

1. The server can ignore anything in the request object and continue with the request
2. The server must return an error if it’s not going to process the request object

The current certification requests appear to allow ‘1' for this case, but I’m not sure why. It appears to directly conflict with the text in the standard. I’m not clear what “no err” in the certification profile was intended to mean though.

It seems that in the wild some currently certified implementations do follow '1'.

[Joseph Heenan]

This was discussed on today’s call and it was agreed that the java tests should follow what the specification says, and this will mean some existing certified implementations (that do not follow the spec and ignore the request/request uri parameter) will fail.

[Joseph Heenan]

Extra text was added to test descriptions here: https://gitlab.com/openid/conformance-suite/-/merge_requests/908 and that was made live this morning.

[Michael Jones]

This is done in the Java certification suite