Distinct aspects of Trusted App replacements about authorization-panel HOT 7 CLOSED

I don't understand how acl:trustedApp, as currently implemented, impacts the need to fetch user's profile document.

acl:trustedApp as currently defined (i'm not sure about implemented in NSS) potentially requires fetching (or examining a cached copy of) the profiles of the controllers of a resource (which could be the members of large groups) to see whether any of them (which might not be the user requesting the access) trust the app the user is using for the attempted mode.

from authorization-panel.

as it is already a problem for a few reasons, notably the annoying requirement to fetch the user's profile document in the authorization algorithm itself

@kjetilk could you please explain it in more depth? AFAIK authorization algorithm needs to fetch user's profile document anyways to verify solid:oidcIssuer delegation. I don't understand how acl:trustedApp, as currently implemented, impacts the need to fetch user's profile document.

Right, my negative opinion might well be influenced of how it was implemented, it should be possible to reuse the previous response instead of fetching it again.

My concern is the general one, that when a request for a resource is made, any requests that the RS needs to make to respond has to be kept to an absolute minimum to ensure proper performance. If the RS has to make requests, then strategies, including various ways to cache, needs to be considered in the design phase to alleviate the impact on performance from making that request.

from authorization-panel.

Thanks for the overview, @elf-pavlik ! I guess it is good to just let you know what we communicated to @jaxoncreed when I came by the Editor's meeting on Friday: I think it is urgent that we find a concrete replacement for the very concrete acl:trustedApp, before it becomes a legacy problem, as it is already a problem for a few reasons, notably the annoying requirement to fetch the user's profile document in the authorization algorithm itself.

There are many interesting things that are considered here, and I absolutely encourage this work, just so you all know that in the very short term, we are encouraging the focus to make sure we can remove acl:trustedApp ASAP.

from authorization-panel.

@kjetilk we have discussed a week ago to start Client constraints model with what currently acl:trustedApp supports - only access mode. It would still allow to extend it later with tags, shapes, secrets etc.
In this issue I try to make point that we can consider all the distinct aspects with high level of independence.

as it is already a problem for a few reasons, notably the annoying requirement to fetch the user's profile document in the authorization algorithm itself

This sounds related to last two aspects - Client presenting Client Authorization and Resource server veryfing Client Authorization. Even with differences between approaches proposed in both PRs it seems that client will only pass IRI reference to the Client Authorization which server should apply. When it comes to caching, it may rely on JWT exp clime or just leave it to HTTP caching, either way I don't think we will remove need to perform fetch in authorization algorithm. @zenomt's proposal to my understanding doesn't allow passing Client Authorization by value, Verifiable Credentials approach could provide option to use either IRI reference or pass the VC as value. While later would eliminate need for RS to fetch Client Authorization it would add quite some overhead to HTTP header size of every request.

from authorization-panel.

@zenomt's proposal to my understanding doesn't allow passing Client Authorization by value,

correct, in my proposal app authorizations are passed by URI. in my preferred embodiment (that is, obtain an access token from the resource server's authorization server), the user's profile and app authorizations, along with issuer info, would be retrieved once by the authorization server, which would verify and then encode/bind everything it needs to know into (or remember keyed to) the access token. any per-resource access control decisions can then be made with information on hand just with the access token (not counting groups of course). my auth server remembers relevant identity and app auth info in database tables and issues a pseudorandom access token that is a key to those records.

from authorization-panel.

as it is already a problem for a few reasons, notably the annoying requirement to fetch the user's profile document in the authorization algorithm itself

@kjetilk could you please explain it in more depth? AFAIK authorization algorithm needs to fetch user's profile document anyways to verify solid:oidcIssuer delegation. I don't understand how acl:trustedApp, as currently implemented, impacts the need to fetch user's profile document.

from authorization-panel.

https://solid.github.io/data-interoperability-panel/specification/ provides an elegant way to authorize applications (clients).

from authorization-panel.