# 2021-07-14 Solid Authorization

https://meet.jit.si/solid-authorization

## Agenda

* Minutes - https://github.com/solid/authorization-panel/pull/238
* UC1 - https://github.com/solid/authorization-panel/pull/215
* UC3 - https://github.com/solid/authorization-panel/pull/216
* Closing outdated UCR issues?
* #87 - https://github.com/solid/authorization-panel/issues/87
* #89 - https://github.com/solid/authorization-panel/issues/89
* Transfer of issue 191 - https://github.com/solid/authorization-panel/issues/191

## Present

* Henry Story
* Justin Bingham
* Elf Pavlik
* Matthieu B

## Minutes

### ACP UC3

Henry: I don't think there is a way to build what we're trying to build without allowing global read to ACRs. There has to be some document that tells you how to authenticate. There is a privacy problem with people putting all access control statements in one ACL. But that problem goes away if you are doing it correctly. And there is no other way of doing it that doesn't require inventing a whole new system. This is why it is important to go through those Use Cases.
I don't think we want to go through all Use Cases. They were developped before we went through this process. It might not be coherent to go throuhg them all.
I don't see that the [latest comment on UC3](https://github.com/solid/authorization-panel/pull/216#discussion_r673945084) is a problem, it is up to Elf to put a proposition forward to deal with credentials requirement discovery.
The default is that you have to read the access control.
This is the only way to do Solid.
That is the right default and what happens if you don't get access? You don't know how to authenticate, therefore, you don't have access.
If you can't access the ACL, you don't know how to authenticate, you're left with guessing which is not acceptable.

Matthieu: But it is a security issue to have ACRs readable publicly by default.

Henry: In my view it is going to be the majority of cases.

Justin: I think we're inflating a real problem that needs to be solved which is understanding what a given agent has access to with an access control system which should just be understand whether you have access to something or not. But there are other out of band ways to give agents a list of what they have access to.
There aren't patterns to tell an agent what they have access to.
I personally don't believe that the best way to deliver that information is through the ACL resources. I'm happy to be proven wrong.
I see it as a separate type of flow.
In other areas which aren't SOlid specific but if your control rules are setup (OAuth/Firewalls...).
I'm wondering what is the minimum amount that people need to know.
We have precedent with WAC-ALLOW in Solid.
But we need to be able to follow your nose through resources would be pretty problematic. Because you don't want to leak stuff you don't want to.

Matthieu: There are two problems here:
1. how does an agent know all the resources it has access to
2. how does one knows which credentials to present to access a resource

Justin: Absolutely, application workflows are much more richer that access to this or that. Pavlik and I specifically worked on it a lot with the interop work we've been doing. So we might have a more accute feeling for what is required.

Elf: We have to make a pragmatic approach towards how to approach those UCs. For ACP my understanding is that the access control resource is not accessible unless there is an access control.

Matthieu: It was also my understanding for WAC (not readable by default).
Maybe raise one more issue to make it explicit whether WAC resources are accessible by default.

Elf: Even though ACP could make it accessible to the public. Why is it required for this use case?
Let's not make it required for this use case.

Matthieu: I see here three questions that I would like

Henry: Unless the ACL states that it is publicly readable, it should not be readable.
That is a limitation of WAC currently that doesn't allow just public read to ACLs.

Matthieu: There is a proposal to extend access control modes including `ControlRead`.

Henry: Link me to it. ACP does something.

Matthieu: I think I agree and if we were to adopt extended access modes, maybe we wouldn't have to use so many different predicates to apply policies in ACP.

Henry: I'll try to review that for next week.
We have a use case for shopping and buying music. It seems that in that case everybody should know the price and clearly that would be an access control rule saying on proof of payment you can download this music.

Matthieu: You mean that the access control would allow you to infer that in order to read the music, you need to show that you need to pay for something.

Henry: That is the same thing for say being a university member.
Just have the Group Bob and Alice being private but you know you need to be part of the group.

Matthieu: This sounds like a classic verifiable credential/key based access where you just need to prove what set you pertain to.

### PR Workflow

Pavlik: There is a bit of problem on who works on pull requests and who has to approve them. But it's pretty clear that ACP would be Matthieu, WAC Sarven, WAC+ Henry, but it would be good to have 1 person leading the proposal.

Matthieu: That sounds good, but what do you think would be necessary to make things clearer?

Henry: I think that's more or less what we've been doing.

Pavlik: We could have separate PRs for separate proposals.

Matthieu: I would prefer keeping a PR per use case. I think the current flow does work well to compare the implementation details.

Justin: +1 Pavlik's point or the spirit of it.
I feel like we needed the specs yesterday and I can't build what I want with the current state of WAC.
We need to optimise our workflow to get to proposal state, we need to get there fast.
The ecosystem needs us to get to a better more robust access control system sooner rather than later.

Henry: I agree that WAC got stuck where it was for 5 to 6 years.
At least now, the simple Use Cases help us show the limitations of WAC and get feedback for example from Sarven.
Comparing it to ACP is helping us tweak things a little bit.
We write out detail by detail the things and figure out problems as we go along.
We might have a problem with ACP and WAC both to do with copying data and figuring out what the problems and disavantages are and end up with one system.
We're just not putting enough time in it, which is why it's very slow.
I suggest we commit this and continue with new PRs to continue on what we've done.
Matthieu suggested that we've already agreed 2 weeks ago to merge and incrementally improve before you joined.
We have a use case that is dealing with privacy on the WAC side.
Matthieu can do the same and we can ask Sarven how that would be done.
It is a good way to see the advantages.
WAC is very easy to implement which is good at the begining and it's been advertised as a good decentralised access control solution, we need to tackle a few issues so that it meets expectations.

Justin: It is a way and beneficial.
But the best way is to have something in the field and get it used in the field.
We need value from real; "in the field"; implementations and use.
We need to see value from there.
That's an essential part of maturing specs and getting them to completion to have something out there that is close to completion.
I wanna ideally try to get there.

Henry: That's what I was doing 5/6 years ago, then it took a long time because something got stuck at MIT.
If you look at this report UC3, then you can see that WAC+ import solves a lot of issues.
And it might help solve things on the ACP side too.
It helps you avoid copying lots of data around.
And answers many questions, such as "If you change the root ACR do changes get effected everywhere else?...

Matthieu: I agree with Henry. I think it is problematic that some fundamental issues have not been formulated clearly in the past and that the fact that we're doing it proves that we're doing something right.

Justin: Yes. More than anything, I just want to understand how do we optimise what we have left to do?
How do we get back from implementation?

Henry: Maybe we need 1 or 1.5 days a week for Matthieu and I to move along.
These UC cases are very much like an implementation. It is backed by experience.
I agree we need to move faster on this.

Matthieu: I agree with Henry's assessment that we need more time aside mostly. There was also a problem of fluency and getting up to speed with the entire Solid ecosystem and state of the discussion on my side as well. But with my current understanding of WAC and Solid, we seem to move along much faster. I also agree that we want to get to implementation feedback as early as possible, but that the use cases are adequatly filling a bit of that space for now.

Justin: Absolutely.

Pavlik: Yes. Another part of my suggestion is not expecting someone else from commenting on your PRs to make progress.

Matthieu: Yes, you're perfectly right, that has been problematic in the past, I'll try to adjust to make faster progress and focus on important issues and questions during the panel.

Henry: Adjusting expectations of comments to move along faster sounds good. We'll keep it in check so that it doesn't get out of control.
Let's not lose the benefit of questions and feedback.

Matthieu: +1

### Closing outdated UCR issues

Justin: +1

Henry: I'll follow up on it on GitHub

### Transfer of issue 191

Justin: I might have permission to do it.

Matthieu: I'll ask Sarven otherwise.

## Actions

* Matthieu to submit UC0 on effective access control resource discovery.
* Matthieu to create issues:
* How does an agent know all the resources it has access to?
* How are required credentials to present to access a resource advertised?
* Using extending access modes instead of to many apply policy predicates in ACP.
* Matthieu to clarify whether WAC's ACLs are private by default.
* Matthieu to point Henry to the extended access control modes issue/proposal and Henry to review it.
* Henry and Matthieu to bootstrap the use case on privacy.
* Henry to follow up on GitHub on outdated issues #87 and #89
* Matthieu to follow up on transfet of https://github.com/solid/authorization-panel/issues/191