Open elf-pavlik opened 2 years ago
+1 on introducing the Authorization Server explicitly in the registration/grant structure.
Having an entry point towards applicable data grants for an RS/AS seems like a great added value in terms of efficiency of evaluating authorization. Also it enables a clearer separation of concerns between AS and AA.
Right now it is fuzzy how the AS gets access to the registrations and grants.
We do need to improve terminology I think, but this is a good starting point.
The problem you are highlighting cfr. AS discovery is something we’ve also been discussing within our team as a challenge. I think this should be introduced in a Solid well-known discovery at the very least.
We've been discussing how the Authorization Server gets access to Data Grants which are relevant to the Resource Servers associated with it. I would like to consider introducing Authorization Server Registration.
I see this issue related to #187 since we are talking about granting access to specific data grants.
Authorization Server Registration just as any Agent Registration would have and Access Grant. This Access Grant in turn would link to any number of Grant Grant (TODO: rename) instead of Data Grant.
Grant Grant could reference each of the Data Grants with something like hasDataGrant (instead of hasDataInstance). If we see a need to use scopes we could define a new one or reuse SelectedFromRegistry.
I see at least one change that could align Grant Grant more closely with how Data Grant works.
Instead of storing Data Grant in an Agent Registration, they could be stored in a Grant Registry. This way each Access Grant would still be stored in Agent Registration of the grantee, but it would like to Data Grant (same for the Grant Grant) in the Grant Registry. I don't think this change is necessary but it would move us further from relying on a containment hierarchy.
I also see one challenge. Based on Data Grants (specifical value of
hasDataRegistration
) we can find the Resource Server to which the grant is applicable. Currently, the Authorization Server can be discovered from theas_uri
parameter in theWWW-Authenticate
header of 401 Unauthorized. I see it as unreliable for 2 reasons:1) Knowledge of IRI denoting a protected resource is needed to get 401 response 2) There is no resource for which notifications subscription could be established. AS associated with RS could possibly change at any time.
I think RS (Solid Storage) should advertise its AS in server metadata resource and allow subscribing to it. This way an AA, which manages Authorization Server Registrations, could subscribe to metadata resources of all Resource Servers that it has Data Grants for and keep up-to-date GrantGrants for their corresponding Authorization Servers.
/cc @justinwb @laurensdeb @woutermont