# 2020-08-12 Authorization Panel August 12th, 2020 ## Present - Justin B - Henry S - Dmitri Z - Jackson M - e Pavlik - Sarven C ## Agenda - High confidentiality - https://github.com/solid/authorization-panel/pull/96 - Discuss Inheritance - https://github.com/solid/authorization-panel/issues/91 - Nontrivial scenarios - [Client-Server symmetry](https://github.com/solid/authorization-panel/issues/73) had a lot of discussion this week. - new PRs: + [Public Commenting](https://github.com/solid/authorization-panel/pull/98) + [Access Until Action](https://github.com/solid/authorization-panel/pull/97) ## Minutes ### High confidentiality https://github.com/solid/authorization-panel/pull/96 HS: URLs should be opaque and we shouldn't be putting semantics into them. But we also need to support Directory like access. The Use Case points out that both are needed (security and public facing). EP: Pointing out that google drive uses flat naming and UUIDs. EP: Changing access should not require changing the URI of the resource. ### Discuss Inheritance https://github.com/solid/authorization-panel/issues/91 EP: Strong +1 for explicit inheritance HS: +1 for explicity. It's just a follow your nose principle. Still need to think about potential implementation. EP: Need to explain how default permissions are assigned for created resource. This is quite connected to explicit inheritance. DZ: Strong +1 on the proposal, and it's an important issue that we should address. JB: Strong +1 on proposal and getting to next level of detail. I JM: +1 JB: Propose action item to draft more detailed approach in line with this train of thought from Ruben. SC: What is the priority of this vs. other work? Is anyone currently implementing this kind of inheritance right now? JB: Should probably look at inheritance in parallel with other UC/Reqs work. HS: I'll point to my rww-play code and explain what I did there and what I think needs improving. EP: Aspect of what has to be answered - how to deal with "imported" ACLs that may not be hosted in same storage instance? Is it allowed? How would it be done? ### Nontrivial scenarios ![](https://i.imgur.com/kn6GnmS.png) EP: Need to consider more complex / complicated scenarios. This diagram can help support several more involved use cases. * Alice and bob have multiple personal storage instances * Multiple storages for different organizations * Alice and Bob have access to various resources on their respective storages * Applications are being used to operate over those resources in different storages * Purple hexagons are storages * PX = Discrete Projects (for example - could change) * NX = Discrete Notes (for example - could change) * Note that this diagram doesn't include applications (clients, services) ACTION ITEM: Add complex/multi-faceted scenario section to use cases (Pavlik will take action on this) - JB +1, HS +1 # Client / Server https://github.com/solid/authorization-panel/issues/73 HS: Challenging whether it's appropriate to restrict access to any ACLs unless control access is available DZ: Is it a technical solution to a social problem HS: Example - you can have access to my song for a price of $.99 DZ: Disagree that it's a problem for the ACL system because we don't express these conditions in WAC or Solid HS: Example - can't access this resource until you're 18. There can be cases where public ACLs are acceptable. DZ: Fundamentally disagree that WAC needs to handle payment, age limits, etc. Those are for different subsystems. JB: Verifiable credentials to my understanding would only require you to present specific type of credential. DZ: Excellent example, re verifiable credentials. The VC system _does_ present the reason (and credential type) to the user. DZ: VC is a different sub-system, and you do communicate the type of credential and why it is needed. Age verification is a great example. VC sub-system tells the user what kind of proof is required. It is not handled on the ACL level. VC level provides that, but won't be solved by making ACLs public. HS: @Dmitri can you provide some links and references into the issue (#73)