This could be that the document contains invalid JSON, or at one point did. ESS caches public client identifiers for up to 2 hours, so you may be seeing the result of that.
I’ve just checked your public client identifier document, and it looks well formed, though.
Okay, I’ve an update: it may be because github serves the document as text/plain potentially. The document looked fine though, so I’d suggest storing it in a pod.
Oh! It might be good to update the documentation to state that it needs to be served with a particular content type ( application/ld+json?), as that might’ve been my problem either.
(I did consider uploading it to a Pod, but stopped short of doing that because I’d need to write a script to upload it with the right content type, without knowing whether that was the issue. A Client ID uploader/creator app might be a fun little app for someone at Inrupt to create I might find some time to do some yak shaving and do it myself at some point, but not in the super short term.)
Thank you @ThisIsMissEm that fixed the issue. Is there someplace I can file a request for more informative error messages? It looks like I hit two problems with my client id document
The content-type of the response was text/plain and not application/json
The client_id in the document didn’t match the URI I was hosting it on (after I moved it to solid storage).
Both of these seem like errors the OIDC server could easily detect and provide actionable error messages for.
Having content-negotiated errors which can render to HTML and contain more information is on the roadmap of ESS already, and I’ll share your feedback with the team so that they have this specific case in mind.
In general, feedback about proprietary Inrupt products can be sent to Jira Service Management