Aaron Coburn

>> Please first implement this feature yourself and provide implementation experience. > This is exactly what we will do. Excellent. We will be interested in learning about your implementation experience.

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

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...

> 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...

> 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...

When using OpenID Connect, an identity provider should be authoritative for a single identity and therefore a single `webid` claim. Merging multiple identities along these lines is out of scope...

Solid-OIDC also establishes the `webid` claim and corresponding `webid` scope. In addition, Solid-OIDC defines a mechanism for defining public client identifiers for app identification

This issue has been open for nearly two years. It seems that the general consensus is that we would like to represent agent identity as some form of an identifier...

> your argument @acoburn, is built on the use case that people have trouble deploying WebID because they are using github to publish their code which makes content-negotiation difficult or...

>> Another problem is that the WebID draft is just a draft. > Well so is Solid-OIDC Indeed. Solid-OIDC is also actively moving toward a more stable form. We do...