Define responsibilities of Authorization Server

elf-pavlik commented 2 years ago

Today we discussed it during the call. I will write down high-level overview of how I see it. Later I will add how it may tie together to #222

Authorization Agent

associated with End-user, sometimes also acting as Resource Owner

Records Access Authorizations (with Data Authorizations etc.)
From above generates Access Grants (with Data Grants etc.)

Authorization Server

associated with Resource Server

From Access Grants (with Data Grants) generates ACRs (ACP) / ACLs (WAC)

Resource Server

associated with Authorization Server (owned by a Resource Owner)

enforces access based on ACRs (ACP) / ACLs (WAC) set by AS

We were also discussing how AS can access relevant Data Grants, including an option where AA would push that information to AS. We should elaborate more on that aspects. Data Grants are stored in Agent Registrations of grantees, I would like to consider that each AS gets Agent Registration as well and AA creates some specialized ??? Grants which grant AS access to Data Grants related to Data Registrations falling under the control of that AS. In that case, it would be a matter of using Solid Notifications for AS to subscribe to its agent registration. Other options should be evaluated as well.

woutermont commented 2 years ago

Thanks @elf-pavlik! I think no one who was in the call disagrees on these entities/roles, and the most important question now is indeed how the AS gets the necessary info (i.e. grants).

Another question, which I did not get wiser on during the call, is why the UMA AS described in Solid-OIDC should be the same server as the AS described here. Even if for some reason, the UMA server needs resource-level authorization info, it could check the ACRs of the RS. [The only scenario we discussed (that I know of) is the one where no access token would be returned if a user+client combination would have access to nothing anyway; and I'm not convinced this is a valuable case: it drops a redundant request, but at a point where the client would only get to if it expected to get access to at least some resource, based on the grants it has in its application registration.] I would therefore argue for a decent separation of responsibilities between those two roles of the AS (and probably find a new name for one of them).

elf-pavlik commented 2 years ago

I see your point @woutermont

I need to make some progress on #222 which should feed into this issue. One of the reasons for UMA style claims pushing in Solid-OIDC was an opportunity to push other claims besides OIDC ID Token. For example, AA could provide signed Data Grants to the client (app), then the client could push that Data Grant to AS as one of the UMA claims. This way AS could set all client-based restrictions on RS before giving it an access token. With this approach separating those wouldn't work that well.

The approach above seems fine for common single-step delegation. In #222 we look at longer delegation chains that seem to require a 'push upstream the chain' mechanism.

woutermont commented 2 years ago

I took a quick look at #222, but would like to go into it more during the panel meeting. Specifically, I do not immediately see why the AA on one end can not be the one to push those grants to the (non-UMA) AS. Then the UMA server would still only have to read the ACRs for an incoming token request. But I am probably missing something.

solid / data-interoperability-panel