Ruben Verborgh

Just to make sure we're on the same page: - this issue currently has a label "blocked" - that label means "depends on another piece of work being performed first"...

I renamed the label to "has dependency" to remove the confusion (originally seen at https://gitter.im/solid/specification?at=5f77b16d717f8e4eb5f67494).

@gibsonf1 kindly [pointed out](https://gitter.im/solid/specification?at=5f78632e66ee4e44a87ce68c) that the necessary API already exists. For instance, https://drive.verborgh.org/.well-known/openid-configuration shows https://drive.verborgh.org/register. Hence, there is no blocker indeed.

Mhm, turns out that both of my suggestions are actually needed by `oidc-rp`. Might be not much we can do here.

@rubensworks Is this a `JSONLDResolver` matter?

Can we just fix it in `webid-oidc.js` by replacing ``` ...(options && options.headers ? options.headers : {}), ``` with ``` ...toObject(options && options.headers), ``` where ``` function toObject(headers = {})...

Would you be able to post the contents of the `.acl` file? We don't have permission to view it (which is a good thing, so don't change that 🙂).

The permissions look fine to me. Are you doing cross-host requests by any chance? Because there are special settings required for doing so. Or is it really an app running...

> The app is running on localhost. Then I suspect this will help you: https://github.com/solid/web-access-control-spec#adding-trusted-web-apps > A cookie associated with a cross-site resource at https://inrupt.net/ was set without the `SameSite`...

> Should this be automated or should the user manually allow the app access? It should be automated; maybe something went wrong there or was overwritten.