elf Pavlik
> I trust my brother to see my photos, but not with that darn XXYYZZ app he was tricked into installing on his phone I think we can make it...
Considering case of same user with multiple devices. For Confidential Client we have just one OAuth client so User authorizations could stay assigned to that specific client. In case of...
> For Confidential Client we have just one OAuth client so User authorizations could stay assigned to that specific client. Actually it looks more like one OAuth Client per Authorization...
@dmitrizagidulin could you please clarify the difference you see between on device instance of a client running in web browser (Public Client on diagram above https://github.com/solid/authorization-and-access-control-panel/issues/30#issuecomment-537168286) and on device instance...
Today on authentication panel call we touched [OAuth 2.0 Device Authorization Grant](https://tools.ietf.org/html/rfc8628) which doesn't use `redirect_url`, I think we should document identifying clients which use that grant and who and...
We could probably adopt terminology from https://tools.ietf.org/html/rfc7591#section-1.2 >Client Software > Software implementing an OAuth 2.0 client. > > Client Instance > A deployed instance of a piece of client software....
> I agree. I think that some kind of system like `acl:origin` (probably a modified version of `acl:origin` so that we can expand its use case beyond just web apps)...
Thank you @michielbdejong I does indeed! In general I think that ACL should only stay responsible for giving permissions to agents. Agents need to stay responsible for managing their trust...
Can we transfer this issue to app-authorization-panel repo?
I'll make PR with one or two use cases where person gives some global trust to specific app. Maybe you can make PR with use case for that: > I...