Allowing a user to change their identity claim is very dangerous and not something that should be part of Solid-OIDC

I don't see why it would be more dangerous than allowing a user to create an identity in the first place. Can you elaborate, @acoburn?

One could envision, for example, a scenario where one uses an ID Token of IdP A to prove to IdP B that one has a certain WebID, upon which IdP B also starts to issue tokens with that identification. Do I miss a glaring vulnerability in there?

If so, we should really brainstorm about alternatives, since this issue constitutes a real-world blocker for clients we're actively developing for.

Assume I have a WebID at https://id.example/user1.
Let's say I have another WebID at https://id.example/user2
Let's also say that another, separate user has a WebID at https://id.example/user3

These are three different identities. If I allow user1 to change their WebID to user3, now I have allowed that user to impersonate another user and the identity model of Solid no longer works. If user1 wishes instead to login as user2, that user can easily do so. There are plenty of examples of this: e.g., multiple accounts on Google. If I want to be logged in as user1 but act as user2, that is delegation, and there are mechanisms for supporting delegation.

One could envision, for example, a scenario where one uses an ID Token of IdP A to prove to IdP B that one has a certain WebID, upon which IdP B also starts to issue tokens with that identification.

That is delegation. You can build a delegation system on top of OAuth2 (and by extension Solid-OIDC), but that doesn't mean changing Solid-OIDC.

If I allow user1 to change their WebID to user3, now I have allowed that user to impersonate another user and the identity model of Solid no longer works.

Given my scenario and you example data, that would be impossible, since user1 would not be able to log in as user3 (viz. they are indeed separate users), and therefore would not be able to present his Identity Provider with an ID Token claiming to be user3.

If user1 wishes instead to login as user2, that user can easily do so. There are plenty of examples of this: e.g., multiple accounts on Google.

That does not quite address the use-cases we are struggling with. In the example of Google, it is not possible to link two accounts (e.g. A and B) in such a way that logging in using the credentials of A suffices to prove that you are also B, or link those accounts to a Facebook account F such that logging in with F suffices to prove that you are both A and B.

If you are wondering about real world applications of such links, one of them would be to enable identification data of one form/provider to be used with the credential type/security of another provider. Suppose I have a WebID id1 registered at provider P1, which uses simple username and password credentials, and a WebID id2 registered at provider P2, which requires a more secure kind of credentials (e.g. TFA, biometric data ...). With my id1 identity, I have some authorization to some resources, which my id2 identity has not. Now I want to access those resources with an app which only trusts a select number of highly secure identity providers, including P2 but not P1. (*) How do we make this work? The most obvious and UX friendly solution to me would be to be able to let the app detect this descrepancy, point the user to an endpoint which let's the user add id1 to P2, and then get a id1 (or [id1,id2]) ID Token from P2.

If I want to be logged in as user1 but act as user2, that is delegation, and there are mechanisms for supporting delegation.

If you think delegation can solve the above use-case, then by all means tell me how.

(*) Note that this is not a fictive story, but a real world use case we are currently trying to implement on request of a client.

If you think delegation can solve the above use-case, then by all means tell me how.

• Token Exchange: https://datatracker.ietf.org/doc/html/rfc8693
• UMA claims pushing: https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html

Those are some standardized mechanisms. Other mechanisms are also possible, but that is where I would start.

Now I want to access those resources with an app which only trusts a select number of highly secure identity providers, including P2 but not P1

Access Control Policies support identity provider-based controls: https://solid.github.io/authorization-panel/acp-specification/#issuer-matcher

@acoburn Thanks again for the pointers, they were very interesting. However, UMA requires an integration with the resource server (to deliver permission tickets) which is not provided by Solid.

OAuth2.0 Token Exchange, while definitely useable, does not get to the core of this issue, viz. how one would set the possible delegations/impersonations in a secure and preferably standardized way, i.e. how would a a user/identity indicate to the STS that e.g. its Access Token token can be exchanged for one with a different webid?

For future reference, this might also be interesting: OIDC Claims Aggregation (draft)