# Solid Authorization Panel
February 10th, 2021

## Present

Henry Story
Justin Bingham
Elf Pavlik
Eric Prudh'ommeaux

## Agenda

* Announcements
* Updated schedule for Credentials Group presentation
* Review Minutes
* Accept [prior minutes](https://github.com/solid/authorization-panel/pull/165/files?short_path=77842b3#diff-77842b35acf47a1c2030c48d0b1e6d626b9dc3c9e07d168d265815b1fdbd41f2) (2m)
* Accept [minutes for Monday's special session](https://github.com/solid/authorization-panel/pull/167/files?short_path=e66d5b0#diff-e66d5b08e777fcb77d751f43b35a40f779e28776d19fde98601f334c1105e56a) (4 min)
* Pull Requests
* https://github.com/solid/authorization-panel/pull/166 - Add create and delete modes
* https://github.com/solid/authorization-panel/pull/152 - Add functional requirements
* Topic Items
* Use cases and requirements target - 2/17 (Next Weds)
* Discuss outstanding items / #166 and #152 to get there

## Minutes

Justin: Looking to see if we can finish the UCR for next week.

Action Item: Any remaining reviews must be complete by Friday

Elf: wondering for background of #166 to help review by Friday.

Justin: One of the problem is that it bundles the ability to create and delete into write and append and creation of a resource. So one can overpermission. One could add triples to container.

Henry: I'd just add: speaking in terms of delete and create makes the UCR easier to read.

Pavlik: Consider adjusting "write" to "update"

Pavlik: does append really make sense?

Justin: for logging yes. Perhaps we need a use case for that.

Justin: Proposing to rename document "Use Cases and Requirements for Authorization in Solid"

Justin: Will also change path to "authz-ucr"

min 30:
Just leaves early for personal commitment.

## Discussion on Credentials

Henry: CSarven [announced on gitter](https://gitter.im/solid/specification?at=6022bab5063b6c68d54c658c) that
> Meeting with the CredentialsCG is fixed to March 10 at 15:00 UTC and 18:00 UTC (two ~1h sessions) - seems to work for most. CCG presents to SocialCG in the first session, and the other way around in the second session.

Henry: as Credentials are part of my EU funded [Solid Control Project](https://nlnet.nl/project/SolidControl/) I found this to be a great opportunity to learn more about it.

Henry: Having gone over the UCR I have now time to dedicate to Credentials. So I opened an issue [Web Credentials Wallet questions](https://github.com/solid/authentication-panel/issues/126) on authN panel, but it could have just as well have been here. It was very helpful to watch Drummond Reed's talk from 4 months ago on the Self-Sovereign project, as it puts a lot of pieces into context. This lead me to download the Manning book [Self Sovereign Identity](https://www.manning.com/books/self-sovereign-identity) that is nearly finished. I think this is invaluable, as it helps put a lot of the different players, technologies and arguments in that space into context. This would be nearly impossible to get an overview of by just reading specifications. So I highly recommend it.

Henry: I will go through the book, and try to see how this applies to us.

Eric P: What are some of the new features this could bring?

Henry: One thing would be Zero Knowledge Proofs. There is a part in the book on that, but I have not yet read it yet, and it looks like it is still very fresh.

Eric P: would be interesting to have a demo of how that works.

Henry: yes, I am not sure how much all of these technologies are applicable to us, as we are building decentralised social networks by linking. So in the book there is sometimes (depending on the author perhaps) an emphasis on non linkeability (especially when discussing zero knowledge proofs of course). But it does make a nice distinction between intentional and unintentional correlation. The difficult thing we will need to express is that we gain privacy by linking small bubbles (Pods) of information together over having all data in one giant data store.

Elf: started was wondering how Capabilities could be related to the authz work in interop panel (henry: I can't fully summarise his point here, as my understanding of that work is too partial at the moment)

Henry: I think a Solid Pod is well placed to act as a Credential Storage device, as we can store them there with POST, PUT and DELETE. They could be access controlled there (perhaps with private keys in some cases?) and used across devices.

Elf: I have a problem with clients editing WAC access control rules. How could one guarantee that they don't mess it up?

Henry: That requires on the client something like [cowl](http://cowl.ws) a confinement system for the web. With such a system the remote JS could be forced to go through a TCP/Wallet guard that would do all the authentication to every resource and only pass on the info the app without passing in credentials. This app could also then be trusted to edit ACLs.

Elf: But why not do that on the server? What is the advantage of running it on a client?

EricP: We started off building such an editor on the client, but the idea is then to move it to the server when the specs have stabilised, where I think it would fit better.

Henry: Funny I would have started on the server where I think confinement is easier to control. I am not sure how far it is possible on the client, but there are so many new JS APIs coming out in the browser it is difficult to tell. One would need to research that.

EricP: it would be good to have a review of your (Henry) research results on Credentials.

Henry: Sure I'll be writing to [Web Credentials Wallet questions](https://github.com/solid/authentication-panel/issues/126) as I read through the book and also elswhere if it does not fit there.

EricP: we are one minute over. Got to go.

Elf: Bye

Henry: Bye