# Solid Authorization Panel July 29th, 2020 # Attendees - Justin B - Jackson M - Dmitri Z - e Pavlik - Henry S # Agenda - Mechanism for publishing draft (netlify vs. github actions) - Next steps for Use Cases and Requirements - Use case issues - https://github.com/solid/authorization-panel/issues/86 - https://github.com/solid/authorization-panel/issues/86 - https://github.com/solid/authorization-panel/issues/88 - https://github.com/solid/authorization-panel/issues/89 - Inheritance approaches - https://github.com/solid/authorization-panel/issues/91 - Negation - https://github.com/solid/authorization-panel/issues/92 # Minutes ## Mechanism for publishing draft - Netlify needs a Solid Administrator for open source submission - Github action alternative - Justin to look at ## Next steps for Use Cases and Requirements JB: Proposing we start writing Requirements - HS+1, JM+0, DZ+1, HS: +1 - Would be good to start some requirements to see how they come out and inform approach. EP: Feel that read/write/inherited may fit better in requirements. Current use cases are focused on a single requirement. JB: Aim was to provide very focused distilled use cases, but also agree we benefit from more complex ones too. ## Append-only access - https://github.com/solid/authorization-panel/issues/86 HS: Helps to have a use case where there aren't so many different ways to accomplish it. Logging / notifications could be good alternatives. Write a post on someone else's blog but you'd like to be notified when someone adds a comment. Also we can always improve use cases over time. ACTION ITEM: JB to update this use case to be more practical ## Read-write access to a collection - https://github.com/solid/authorization-panel/issues/86 HS: Structure of access control can mean there are possibilities that don't have use cases. ACTION ITEM: JB to update this use case to be more practical DZ: Highlight from Pavlik's description - append-only doesn't let the user edit what they already commented. In comment example, users should be able to edit or delete their comment, which append-only doesn't allow. Additional Issue for Use Cases - If you have append-only access to a container, and are able to create things, you would need write access on the container to delete them. No way to provide conditional authorization based on whether or not that agent created the resource. Ensure we have appropriate use cases for removal documented. ## https://github.com/solid/authorization-panel/issues/88 DZ: First use case on read-append access was a comment thread (you can see all the comments and you can add one). However, once you make a comment you can't delete it. If we had author override logic, comments would be a perfect use case for read-append access. DZ: Can imagine genuine read-append - if you submitted something you can't go back and edit it. HS: Twitter is read-append. DZ: Agree but you also can delete (i.e. Read-Append-Delete), and it is also universally complained against. Mastodon / Fediverse you're allowed to both edit and delete a comment, but warns that things have already gone out. HS: It would be silly to be able to delete but not see what you wrote. ## https://github.com/solid/authorization-panel/issues/89 Have already agreed to change the use case that is the subject of this issue. ## Inheritance - https://github.com/solid/authorization-panel/issues/91 DZ: +1 on inheritance. In Ruben's use case there wasn't a direct lifecycle binding, so maybe that should also be considered. JM: +1 on addressing inheritance HS: Should be important to be able to be able to following links from one acl to another. Henry to propose a use case. On the web everything needs to be explicit. Should avoid implicit. DZ: Explicitly specifying inheritance seems more Webby than the legacy inheritance algorithm.