I am not 100% sure this is a bug or an error with the provider implementation (OpenAM 13.0).

Using the mitre simple web app, I can see it generates a registration request as follows:

{"redirect_uris":["http://localhost:8080/simple-web-app/openid_connect_login"],"client_name":"Simple Web App","token_endpoint_auth_method":"client_secret_basic","scope":"openid email address profile phone","grant_types":[],"response_types":[],"jwks_uri":"http://localhost:8080/simple-web-app/jwk","request_object_signing_alg":"RS256"}"

Note the grant_types and response_types are zero length lists. The spec says these fields are OPTIONAL.
The error that I see on OpenAM is that it creates the client but has no values for response_type, so subsequent requests fail.

Another dynamic reg client that I tested omits the response_types all together - and it "works" in the sense that OpenAM fills in default values. I think the OpenAM does not like the fact that a value is being supplied - but is empty. It should probably reject the request.

I suppose this comes down to a spec interpretation thing. Should an empty list be treated the same as not being present at all.