Wouter Termont

Makes sense. The reason I think it is advantageous to turn this around, is that you can make a distinction in authorative data between social data, that is not sensitive...

Thanks to @laurensdeb for pointing this out, and @RubenVerborgh for providing the opportunity for interaction 🙏

_I'm picking up this thread in light of the linked issue._ While I get the reactions that this is an unnecessary or at most optional feature, the recurring issues stuck...

Of course, current classic OIDC providers could perfectly implement the create prompt, but have not (yet). I fail to see, however, how that prevents Solid-OIDC from adopting it. After all,...

> > No provider currently supports checking ClientID documents > > I can think of two that currently support this. Which ones? I'm talking about classic OIDC providers, of course,...

> ClientIDs are defined specifically for Solid-OIDC. A server that doesn't implement Solid-OIDC would not, _ipso facto_, implement a Solid-OIDC specific feature. Aiming for a growing Solid ecosystem, I would...

_Picking up this thread with regards to the linked issues._ Would there be advantages to having only a single _claim_ that has to incorporate all possible ways of identifying in...

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

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

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