-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Authorizing clients (apps) #517
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue acts as a follow-up to the conversation from the CG meeting on 2023-03-22 around #504
One of the main aspects relates to deciding who and when has the authority for authorizing the client. I will discuss it based on: Use Cases and Requirements for Authorization in Solid: 2.5.2. Limiting application access while not acting as resource controller
We have two actors Alice and ACME, sometimes called SocialAgents [SAI] and one application - PerformChart. Colored boxes mark distinct security domains:
In mentioned use case 2.5.2, ACME (the Resource Owner) grants Alice (the End user) read-write access to selected projects. ACME gives Alice full freedom to access those projects using whatever application they choose. Alice decides to access them using two different applications, one of them - Performchart - only does analysis and visualization so Alice only delegates read-only access, based on read-write access granted to her by ACME.
In SAI we have it specified and implemented using Authorization Agent, where an Application (here PerformChart) redirects Alice to her Authorization Agent where based on the read-write grant from ACME, Alice can create a delegated read-only grant to PerformChart. To be specific Alice can also further narrow down access to which projects she delegates.
During the meeting, @timbl brought up a different use case (which I recall he mentioned already some years ago). If we use a variant of the use case above, ACME would not leave Alice full freedom to choose with which application they will access the projects ACME granted them access to. Instead, ACME will take the authority to specify which applications are allowed.
I agree that in some situations authority for authorizing the client could be claimed by the Resource Owner, while in others left to the End user. When it comes to enforcing Resource Owner restrictions on clients we should keep a few things in mind.
In Solid-OIDC, the OpenID Provider verifies the identity of the client and sets it as
azp
claim in the issued ID Token. Commonly the End user has the freedom to choose (sometimes fully control) the OpenID Provider. In that case, they always have at least the potential to set the client's identity to whatever they want. This makes enforcement of restrictions set by the Resource Owner unreliable. I think there are a few variants of this scenario:acp:client
andacp:issuer
matchers.In the real world, they will be even more diversity of scenarios, for example, both the Resource Owners and the End user define their trust on a level of some certification authority (or federation), as long as the client is certified (federated) in at least one common authority it can be used.
This topic was already discussed on various occasions in the last few years, here are just some relevant references:
The text was updated successfully, but these errors were encountered: