Why doesn't the Vuejectron app host its own Client ID Document?

[michielbdejong]

In the development setup of this repo, there is an app called Vuejectron which runs on http://localhost:4500
but its client ID is http://localhost:3000/acme/projectron/vue which is on the pod server domain.

This results in the following confusing consent question, with localhost:3000 asking you if you want it to trust localhost:3000 - so basically your pod server asks you "Should I trust myself?" which feels like a silly question:

[michielbdejong]

Another thing that is confusing about this consent question is that "read and write data on your behalf" is very vague. Can we improve that wording here, maybe say a bit more about the app's data needs and the access it will get when you click Authorize? Prosumably it will not get permission to read and write any data anywhere on your behalf, right?

[elf-pavlik]

When it comes to the authentication screen served by CSS, we could customize it in sai-js, but this would only work for developers using this local instance of CSS. We should work with CSS to improve some of the experience. There is already an open issue related to layout breaking on mobile devices.

I believe that we should work on integrating the SAI Authorization Agent with the CSS OIDC Provider, which would provide a smooth experience with a single redirect.

---

Client ID documents can be hosted anywhere on the web. The OP will verify that the redirect_uri used in the Authorization Code flow is listed in the Client ID document. An issue (solid/solid-oidc#207) and a draft PR are evaluating adopting the OIDC Federation. This would allow us to have federations of clients/RPs, where users would have more trust in some federations, and apps whose IDs prove to be part of that federation would have some hint assuring the user. I think of it as non-monopolistic 'app stores', which provide curation; for example, https://tosdr.org/ could run one of such federations.

Coming back to the dev setup, since the app's origin and the client ID document don't have to match directly anyway, hosting the client ID on the local dev instance of the storage was just a convenient thing to do.