Dynamic client registration accepts form encoded data but parses it incorrectly

Commencez par la ligne indiquée dans src/handlers/AuthenticationRequest.js, où les données client mal formées provoquent ensuite une exception, puis suivez la manière dont l’enregistrement dynamique analyse les requêtes form-encoded. Le travail est terminé lorsque les types de contenu ou les structures incorrects sont rejetés avec HTTP 400, tandis qu’un enregistrement valide en application/json continue de préserver ses champs de tableau.

I'm writing a python library to perform webid-oidc, according to the guide at https://github.com/solid/webid-oidc-spec/blob/master/application-user-workflow.md

At step 9 (Dynamic client registration), there is a link to https://openid.net/specs/openid-connect-registration-1_0.html
The spec says in section 3.1:

The Client sends an HTTP POST to the Client Registration Endpoint with a content type of application/json

I was initially sending form encoded data to this endpoint, but node-solid-server accepted the request:

A python request of:

    data = {
        "grant_types": ["implicit"],
        "issuer": "https://localhost:8443",
        "redirect_uris": ["https://localhost:8443/redirect"],
        "response_types": ["id_token token"],
        "scope": "openid profile"
    }
r = requests.post("https://localhost:8443", data=data, verify=False)

results in an HTTP request of:

POST / HTTP/1.1
Host: localhost:8899
User-Agent: python-requests/2.25.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-Length: 164
Content-Type: application/x-www-form-urlencoded

grant_types=implicit&issuer=https%3A%2F%2Flocalhost%3A8443&redirect_uris=http%3A%2F%2Flocalhost%3A8888%2Fredirect&response_types=id_token+token&scope=openid+profile

node-solid-server accepts this request and adds to db/oidc/op/clients a file with the contents

{
  "redirect_uris": "http://localhost:8888/redirect",
  "client_id": "a1b6275fa73f653a7392f5440851356b",
  "client_secret": "bdc6c73d1f6f4de3ded9f43a730a7d86",
  "response_types": "id_token token",
  "grant_types": "implicit",
  "application_type": "web",
  "id_token_signed_response_alg": "RS256",
  "token_endpoint_auth_method": "client_secret_basic"
}

Note that it no longer includes the lists in the original request for grant_types, redirect_urls or response_types.

If I send the data as a json body with the correct content-type, the data is accepted correctly and generates the following client file:

{
  "redirect_uris": [
    "http://localhost:8888/redirect"
  ],
  "client_id": "805187586c656faad7ad21e05c7d08b8",
  "response_types": [
    "id_token token"
  ],
  "grant_types": [
    "implicit"
  ],
  "application_type": "web",
  "id_token_signed_response_alg": "RS256",
  "token_endpoint_auth_method": "client_secret_basic"
}

The incorrect data in the clients file results in an exception when trying to access the authorize url, because a list is expected when looking at the redirect_urls field: https://github.com/solid/oidc-op/blob/72e4cfa7870aab7913314cbbe5277d0bb559dcf8/src/handlers/AuthenticationRequest.js#L511

It's clear that I was submitting data in the wrong format, but node-solid-server still accepted it, even though the specification says that the content-type should be application/json (I see that it doesn't make a MAY/SHOULD/MUST claim here though...). Perhaps it makes sense for node-solid-server to return HTTP400 if the data format is incorrect?