# W3C Solid Community Group: Authorization Panel

* Date: 2022-05-18T14:00:00Z
* Call: https://meet.jit.si/solid-authorization
* Chat: https://gitter.im/solid/authorization-panel
* Repository: https://github.com/solid/authorization-panel

## Present

* Matthieu
* Laurens
* Jasper
* Angel
* Pavlik

---

## Announcements

### Meeting Recordings and Transcripts

* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
* Use panel chat and repository. Queue in call to talk.

### Participation and Code of Conduct

* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/)
* [Solid Code of Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/)
* If this is your first time, welcome! please introduce yourself.

### Scribes

* Pavlik
* Laurens

### Introductions

* name: Jasper
* Jasper: I work with [Digita](https://www.digita.ai/)

---

## Topics

* UMA AS demo (CSS) by Laurens
* [Solid Roles](https://github.com/solid/authorization-panel/discussions/296)

## Minutes

### UMA AS demo (CSS) by Laurens

* Laurens: I'm working on this project for my thesis: https://github.com/laurensdeb/interoperability/
* ...: Those modules work orthogonal to Solid-OIDC and WAC, they can be enabled without disabling the other two.
* ...: README explains all the architectural choices. Sai-UMA is based on componentsjs and uses Digita's handlersjs. Using those two allows defining configuration and plug in authorizers of one's choice.
* ...: If you have ACP implementation one could also plug it in using componentjs configuration.
* ...: We will also see sai-aa which is an authorization agent.
* ...: repos allows to just `npm install` and `npm start`. I will start with Authorization Agent which is main actor in SAI spec. I will demostrate it using my Postman project.
* ...: The discovery of Agent Registration works by making authenticated HEAD request to Authorization Agent. I'm using dummy tokens in the demo but one can enable solid-oidc via componentsjs config.
* ...: To access my Agent Reigstration I need to use authenticated request. For unauthenticated request I get 401 with UMA `ticket` and `as_uri`.
* ...: I can get access token by exchanging my dpop-bound id-token.
* ...: Now I can request my Agent Registration using the Access Token. And get my Access Grant with all Data Grants which I, as Social Agent have been granted by Alice.
* ...: From Data Grant I can follow to Data Registration and Data Instances.
* ...: This also works with other access modes. Demonstrating Create and Delete.
* ...: Authorization Agent has it's own WebID and acts as agent in solid ecosystem.
* ...: Authorization Agent is authenticating with Solid-OIDC to get access to user's solid pod.
* Pavlik: Usually we deal with End-user (`webid`) and the Client/Application (`client-id`).
* Laurens: Authorizer gets the principle which defines `webid` and `client_id` so one can also get Application Registration.
* ...: I've changed webid to storage owner's one and set `client_id` and now I get Application Registration
* Pavlik: I just always try to emphasise the interplay of End-user `webid` and Client/Application `client_id`.

### Solid Roles

https://github.com/solid/authorization-panel/discussions/296

* Pavlik: Shows discussion 296, diagram was expanded from previous version with more end-users and context.
* ...: On the left we have an end-user, on the right a resource owner (RO). They are typically different social agents from one another (cfr. vision of Solid ecosystem).
* ...: On the bottom the diagram shows a client application.
* ...: End-user uses Projectron to use resource owned by RO. Both RO and end-user have WebID, and their own Authorization Agent and OpenID Provider (OP).
* ...: For clarity the OP of RO was abstracted away.
* ...: Resource server of End-User contains application registration of end-user. So the end-user is RO of application registration (different context).
* ...: If we focus on client, it authenticates with an ID Token from the OP. To authorize it uses the end-user's Authorization Agent.
* ...: Then, if Projectron wants to access a resource on the RS of the RO, upon an unauthenticated request it will get the AS URI and a Permission Ticket. With the AS of the RO it will obtain an access token for the RS.
* ...: For the Authorization purpose, both the WebID of the end-user and the Client Id of the Projectron application.
* ...: Tree in the middle refers to the use of ShapeTrees.
* ...: Suppose it is the first time Alice uses Projectron for the first time. Often we've omitted the discovery towards data, cfr. follow-your-nose.
* ...: In order to follow least privilege principle, if the client doesn't have authorization it should not know it exists. Even discovery is behind authorization. In my opinion both cannot be separated.
* ...: If Alice starts using Projectron, it needs a way to ask for authorization. For this it uses the access needs of Projectron that are specified in terms of Shape Trees with some access modes (e.g. read/write).
* ...: Within their respective Pods, both Alice and Bob use same shape tree IRIs to refer to common types of data.
* ...: When the client wants to get authorized, the AA will take the access needs group and show to Alice an authorization screen.
* ...: Alice's Authorization Agent can use data registrations from registry set, as well as all data that was shared by others in her social graph.
* ...: Alice should be able to authorize for data that was shared with her, not only the data that she owns but also what was granted to her. This way clients can access this data on her behalf.
* ...: There will be multiple data registries concerning multiple resource servers (storages).
* ...: Alice will be able to delegate a grant she has received from Bob and allow Projectron to allow all or a subset of what Alice can access by Bob.
* ...: The case of delegating access to data that one doesn't own is very interesting. The RO shouldn't care whom Alice delegates access to. However, then how can Bob's resource server take these authorizations into consideration?
* ...: One of the problems we must solve: What if Alice delegates access to resources how can the authorization service in the security realm of Bob take this into account?
* ...: If a Verifiable Credential were made available to the application, the VC can be presented through UMA claims pushing. Both ID token and VC of Delegated Data grant would have to be presented. This VC would have been signed by the authorization agent of Alice.
* ...: When the authorizer is validating what access modes are available for Projectron, it would take into account the Data Grant of Bob to Alice as well as the Delegated Data grant, which could be a subset of what was granted to Alice.
* Laurens: Very explicit mechanism for delegation through the use of VCs is a plus.
* Pavlik: With longer delegation chains some problems could occur, what do we expose and how do we handle chained signatures. However, the current proposal is what we should support as a minimum to have an end-user share a resource to which they were granted access but which they do not own.
* ...: Discovery is also very important, as it is intertwined with authorization. It is a prerequisite for discovery.
* ...: Shows [discussion #203](https://github.com/solid/authorization-panel/discussions/203), with diagrams of an Access Matrix. Where different views on authorization rules are visualized, i.e. by column, by row.
* ...: Data grants are similar to the collapse by row, i.e. per-agent.
* ...: By saying what can be accessed the agent (through the data grant), it gets a discovery path that could be a replacement of the WAC-Allow header.
* ...: Discovery starting from the resources (collapse by column) makes less sense as a discovery mechanism.
* Mathieu: Agrees that discoverability is important.
* Pavlik: Do we have consensus that authorization is prerequisite to discovery? (Public resources are a separate case.)
* Mathieu: Yes.
* Laurens: Agreed.
* Pavlik: This is something that I have not seen addressed up until now. In the Solid Application Interoperability specification the guiding principle has been that of least-privilege.
* ...: Without any consent or trust chain the existence of data shouldn't be discoverable.
* ...: To conclude we should look at (1) reconciling the work of ACP and Interop and (2) define a generalized view of the Access Matrix, where data grants give a collapse by agent and ACP gets a collapsed view by resource. I believe this will make more sense for discovery.
* Laurens: I see work item of defining how Delegated Data Grants represented as VCs can be pushed to UMA Authorization Server. For example the format of VCs representing DDGs.
* ...: We also should consider revocation and how to model it.
* Laurens: The [Revocation List 2020](https://w3c-ccg.github.io/vc-status-rl-2020/) specification provides some affordances for revocation.
* Pavlik: ZCAP-LD https://w3c-ccg.github.io/zcap-spec/ https://kyledenhartog.com/comparing-VCs-with-zcaps/