Wouter Termont

If that is the way the panel wants to go, then you can close this issue. Just seems like a waste of good functionality if we extend OIDC and then...

@justinwb, there's no specific use case underlying this issue; rather a worry about the user's access token still being needed in the application's flow, and thus still not closing all...

@elf-pavlik, I'm not sure, since I do not entirely comprehend which way the authentication panel wants to go without global access tokens. This issue dates from before that intention was...

Unless I'm missing something, the application must be able to send _some_ form of credential to access the application registry. For example, in [this access request diagram](https://raw.githubusercontent.com/solid/data-interoperability-panel/main/proposals/specification/diagrams/authz-sequence-app-requests-access.svg) the ACME project...

If the issue indeed stems from a discrepancy between the panels, my bad (although it can be good to leave the issue open untill that discrepancy is solved). While quite...

> Do you see any other cases where there would be no client acting on End-user's behalf? Of course: when I send an HTTP/LDP command via the terminal, or even...

@acoburn, I'm not contending there are different ways to get an access token, but rather how that access token will limit access to a limited set of resources. If I'm...

> you may choose to have no client identifier in that case [...] you can simply define the access rules such that any client can access a resource. But there...

Thanks, @elf-pavlik! > I think making exception could lead to a security hole where client tries to act as 'no client'. This was exactly what I was trying to point...

Currently, at [use.id](https://use.id) we're using the OIDC Dynamic Client Registration metadata values `policy_uri` (policies) and `tos_uri` (terms of service) to provide users with links to those documents. Towards the future,...