At some point @inrupt/solid-client-authn-browser had a bug where it normalized the redirect URL, and that caused some issue because it introduced a trailing slash where some users weren't expecting it: https://github.com/inrupt/solid-client-authn-js/commit/baac030d33163ba08dadebabdaf676450be7fa88. However, Penny must have relied on this behavior initially (so that the Client Id worked), and it being fixed being a breaking change from that perspective.

document.location.origin (which is used as a redirect URL) doesn't include the trailing slash, so I think that's the cause of the issue.

When trying to log in, I experience an issue at the OpenID Provider complaining about mismatching redirect URIs. In particular, the request to the authorization point is as follows:

https://login.inrupt.com/authorization?client_id=https://solidweb.me/vincent/public/workaround/clientid.jsonld&redirect_uri=https://penny.vincenttunru.com&response_type=code&scope=openid offline_access webid&state=44a6b0e8cb3e42d8947eea8f7e2bfd51&code_challenge=PifiJz26uuyM46cFeG3zGT6K_XXalhEWeRjX5VkW2Mw&code_challenge_method=S256&prompt=consent&response_mode=query

and the Client ID dereferences to

{"@context":"https://www.w3.org/ns/solid/oidc-context.jsonld","client_id":"https://solidweb.me/vincent/public/workaround/clientid.jsonld","redirect_uris":["https://penny.vincenttunru.com/"],"client_name":"Penny","token_endpoint_auth_method":"none","grant_types":["refresh_token","authorization_code"],"response_types":["code"],"scope":"openid webid offline_access"}

You'll notice that the redirect URL in the authorization request doesn't include a trailing slash, and the one in the Client ID document does. I think that's the cause of the issue.

The issue flagged in #48 is happening again today. I would say it is caused by the reliance on a third-party host for the Client ID Document, which may be down when the app is up. If the Client ID Document was served by the app, its availability would match the app's, which would probably cause less confusion when this kind of issues happen.

Are there reasons no to serve the client ID from the /api/ pages of Next, so that penny's Client ID would be something like https://penny.vincenttunru.com/api/client-id? If that's something you think could be acceptable, I'm happy to open a PR :)

That makes sense! I don't think the spec says anything specific about it, but I would have expected a resource stored on a Solid storage with the Content-Type header set to application/ld+json to be able to serve back that same resource with a similar serialization. However, there are subtleties around dealing with JSON-LD contexts, so that may not be as straightforward as one could hope for ^^.

A Client ID is indeed not required for ESS, although it is recommended: it allows the OpenID Provider to keep track of clients that have been allowed by the user, and to not re-prompt the user for their consent on each new login as it happens with Dynamic Client Registration.

I'll close this issue then, thanks for the quick response 😄

The issue flagged in #48 is happening again today. I would say it is caused by the reliance on a third-party host for the Client ID Document, which may be down when the app is up. If the Client ID Document was served by the app, its availability would match the app's, which would probably cause less confusion when this kind of issues happen.

Are there reasons no to serve the client ID from the /api/ pages of Next, so that penny's Client ID would be something like https://penny.vincenttunru.com/api/client-id? If that's something you think could be acceptable, I'm happy to open a PR :)

Visiting any Pod Root returns a 502 Bad Gateway error response. I experienced this on both https://solidweb.me/ewingson/ and https://solidweb.me/vincent/, so I assumed this was a more general issue, although I haven't tested any further.

To reproduce, go to https://solidweb.me/ewingson/ with an unauthenticated browser window.

I mistakingly entered https://pod.inrupt.com instead of https://broker.pod.inrupt.com as my IdP, and that resulted in an uncaught error thrown by @inrupt/solid-client-authn-browser regarding the DCR endpoint not being available (because https://pod.inrupt.com/.well-known/openid-configuration does not exist). I think this could be solved by waiting on the login promise and catching errors there. I'm also wondering whether such an error should be thrown by the underlying library anyways, instead of simply not redirecting the user to the (invalid) IdP, and returning an unauthenticated session, or null.

Considering the description provided http://rdf.js.org/stream-spec/#store-interface, it seems to make more sense that the Document implements the RDFJS/Dataset (https://rdf.js.org/dataset-spec/) interface. There should be no dependency from Tripledoc to Store anymore after completion.