Consider using application/json rather than application/x-www-form-urlencoded in the id_assertion_endpoint

[samuelgoto]

Forking something orthogonal from this thread w3c-fedid/custom-requests#2 so that we can look in isolation, rather than in conjunction with the original issue

[panva]

@samuelgoto I believe the registered JSON content-type would be application/json?

[bc-pi]

As is often the case, @panva is correct*.

* my assessment of correctness is based on my own research at https://www.iana.org/assignments/media-types/media-types.xhtml

[elf-pavlik]

For completeness, I'll copy the response from @cbiesinger

It is possible, although there are two/three downsides to that proposal:

• Sending the body as JSON means we trigger a CORS preflight (this isn't necessarily a problem, but makes things a bit more complicated and adds latency)
• There's a few IDPs who already adopted FedCM which would need to update their code
• JSON post bodies are relatively unusual

But yeah we could go that route. The easiest way to do that might be to require IDPs to opt in to that when they are ready and eventually remove support for urlencoded.

I believe @gffletch mentioned OIDC - Passing Request Parameters as JWTs, where the Request Object is compatible with OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request.

Looking at OAuth 2.0 Pushed Authorization Requests the POST also uses application/x-www-form-urlencoded, so using application/json would indeed be diverging from OAuth.

The expired OAuth 2.0 JSON Request draft also seems to confirm that.

This issue could be resolved by simply leaving the request as application/x-www-form-urlencoded since it follows OAuth practice.

It might be worth looking at the OIDC Request Object, JAR, and PAR usage of JWT compared to the simple JSON string proposed in w3c-fedid/custom-requests#2. Any potential discussion would probably belong to that issue.