# 2021-07-28 Solid Authorization

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

## Agenda

* Minutes - https://github.com/solid/authorization-panel/pull/240
* UC0 - https://github.com/solid/authorization-panel/pull/244
* UC3 - https://github.com/solid/authorization-panel/pull/241
* ACL on ACL - https://github.com/solid/authorization-panel/issues/189
* Mode range: https://github.com/solid/authorization-panel/issues/187

## Present

* Elf Pavlik
* Sarven Capadisli
* Henry Story
* Matthieu Bosquet

## Minutes

## UC0

Sarven: What happens when you get a 403 on ACR?

Matthieu: I don't think we have a good required credentials discovery mechanism. That's what we need defining.

Sarven: You have foo and foo.acl. If I get a 404 on foo.acl, it tells me that foo potentially exists. It emphasises on the authorise. If you know that foo exists but don't have access to it, getting a 403 (or 404) is fine.

Elf: Go to foo, get a header to the acl, how do you know?

Sarven: Whether you know or not that foo.acl exists. It's fine, but if you don't know it exists, what should happen?

Elf: Without knowing that foo exists, you don't get to know that the acl exists.

Sarven: If you don't know that foo exists you should get a 403.

Elf: How do you get a response you don't get a response.

Sarven: Just guessing URLs. If I look at the resource directly, I can see that file exists.
But let's say I don't have read access to the container but I'm guessing the filename "work-on-the-weekend.txt" and then I'm getting to the acl.
If you don't know the existence of a resource you get a 403.

Henry: How would the server know what you know?

Sarven: Because you're authorized (or not).

Henry: I think we need to go at it from an unauthenticated perspective.
The first thing we have to do is how to build apps that work accross pods?
Everyone is using social networks because it's easy to use.
If we can get everybody to be working on decentralised apps, we're solving a real problem. Not how does the CIA deals with it?
For the moment, the problem is how does an app following links knows how to authenticate?
Currently with WAC, it can't find out.
Because right now, you follow a link and the only person that follows the link and wants to read the ACL is the controller. There is no other way of saying it.
If I am a friend of yours and follow links and want to read something, I have no idea what identity to use in order to access resources.
This is not a decentralised network, it is 1990s PC.
There are a ton of experiments that put a user at the center of using a cloud based system.
That is not decentralisation.
We can't make the same mistake.
The question is how do I comming accross a link what the access control rules are.
There is a simple answer, which would be making the ACLs more readable than the resources.

Sarven: We can introduce a new access mode like ControlRead. Or using problem details eg. on 403, payload indicating required credentials (over 18), we can describe the structure/semantics as well on the Protocol level.

Henry: We need the access control rules to be readable by the client.

Elf: I don't think that's correct. I strongly disagree with the statement you make that it is holding in all cases.

Henry: OK, but even me with my client that is open source, I should be able to edit my own content that I want to see.

Elf: I login to my application and the application will use the identity I use for logging in.

Henry: It's a very simple answer, all IDs are currently local to the server you're on. Your IDs are tied to a domain. and the browser vendors don't have the imagination to address that.

Elf: What we're discussing in the interop panel is that you would notify agents that they have access to x. So applications have a discovery mechanism and the agent would know which identity is tied to access to specific resources.

Matthieu: Is it a centralised cross identities notification system?

Elf: At the moment we don't define how to keep track of all your identities.
But each identity would have an associated inbox where they receive the notification about what they have access to.
The authorization agent of Alice would have access to specific grants and not all applications would have access to all grants.

Matthieu: I don't understand why the default from a security perspective is not 404.

Sarven: First of all, 403 is defined and has meaning. If you can read the container and see that foo is linked to it, you already know that the resource exists. If you get that resource, you can get a 403, but since you know the resource exists 404 doesn't make sense. But the RFC also says you can use 404 to hide information.
You're describing the purpose of hiding information.
But you're capable of finding out on the request that a resource exists. So you're not hiding.

Henry: Sorry it's boring me, we can't discuss some issues like that, it's wasting my time. Let's open an issue for it.

Sarven: The first thing I said is whether the evaluation should take this into account.

Henry: If you put up this question, we can put up a Use Case and have a user story where this is an issue and show how the different systems work. But out of the blue like that, we don't have anything that can be constructively discussed. We could make it so through a use case. It seems overly paranoid to me as a UC. We could put that in the Thor UC which doesn't allow information leakage through slash semantics. You're gonna have to put things behind Thor if you really want to be secure but it requires a lot of other things to be secure.

Sarven: Just know that it comes up in the community group as a discussion we're trying to figure out. The more input we have, the better.
Not only is it a security threat, but it's also valuable to answer.

Henry: Yes, but we need priorities. Not everyone being on centralised systems is the first one. We can't start with security perfection.
If I were to pay people to tink about decentralised networks, I wouldn't start with things that are almost unimportant for now, at this stage, I think it comes later. There are leaks and security issues everywhere.
Are we writing software that is so well written that we're looking at marginal security use cases? Probably not yet.
For me it's really important to have the Thor example (Solid behind Tor) and that's when the security people will come in and fix things.

### UC3

Elf: I think we should focus on inheritance.

Matthieu: Let's merge as is and dedicate a whole conversation and proper Use Cases to required credentials discovery since it is a strong thread and you too Henry have pointed that the question has not been answered previously in similar experiments.

### ACL Control

Henry: In a way Control gives you access to not the resource but the control of that resource. Instead of having control, you could get read and write over an acl. That makes me think you could deprecate Control where the Read and Write.

Sarven: I don't see even right now how the WAC spec prevents you from having an ACL resource over an ACL resource. It could indeed advertise its own ACL resource. Indeed I think we could have an implementation that is spec conforming that uses ACLs on ACLs.

Matthieu: See also https://github.com/solid/specification/issues/14#issuecomment-683480525

Henry: The way would be to have a self referencing header if the ACL resource is its own ACL (that could be the default). But how do you make it so that the user can tune it? You could point the ACL to other documents that have their own rights. But how does one edit headers.

Sarven: There is a draft solution link and unlink headers ( https://tools.ietf.org/id/draft-snell-link-method-01.html ) - see also https://gitter.im/solid/specification?at=5ec2c02e7da13f3a0ac0141c , https://github.com/solid/web-access-control-spec/issues/91#issuecomment-562169309 . That could have been used to change the interaction models in LDP. If we picked that spec up, we could do it.

Henry: 10 Years ago when there was only a meta header, you could edit the link headers there.
It gets complicated but it would be good to explore.
Different levels and complicated for ACLs. It would be interesting to know whether it's possible.

## Actions

* Henry to look at UC0 and merge.
* Matthieu to look at UC3 and add acp:access
* Matthieu to finish answering the range of acl:mode
* Matthieu to comment on the HTTP 404 vs 403 issue