How does a user revoke a PoP Token for all resource servers

[jaxoncreed]

This issue has similar concert to the one @zenomt raised here #1 but from a different perspective.

It's true that the resource server can ignore a token it finds unsavory, but what if the following happens:

Alice logs into shadyapp.com and shadyapp.com receives a token so it can query Alice and Alice's friends Pods. Later Alice sees an article that says shadyapp.com is not to be trusted. So, she wants to globally revoke the token.

In a traditional oidc environment this is possible because we're only dealing with one resource server, but in a world where this token could represent Alice for every resource server in existence, it becomes harder.

One possible way to handle this is to replace step 8 here (https://github.com/solid/webid-oidc-spec/blob/master/application-user-workflow.md#8-requests-public-keys) with a different route that allows the resource server to send the token for the authorization server to confirm. However, this solution negates any efficiency improvements through caching.

[zenomt]

typically this is handled by the tokens (the id_token for the POP token scheme and my scheme) having short lifetimes, on the order of minutes to hours, rather than days to weeks. by not using the app anymore, logging out, revoking any refresh_tokens (or not even issuing refresh_tokens) or revoking consent for shadyapp.com, any in-use tokens will eventually expire, and shadyapp.com won't be able to get any new ones.

[jaxoncreed]

That makes sense

[elf-pavlik]

Alice logs into shadyapp.com and shadyapp.com receives a token so it can query Alice and Alice's friends Pods. Later Alice sees an article that says shadyapp.com is not to be trusted. So, she wants to globally revoke the token.

It sounds to me like app authoriaztion concern. Recently I've created issue about revoking app authorizations: solid/authorization-panel#24