# 2021-15-08 Solid Authorization

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

## Agenda

* Previous meeting minutes https://github.com/solid/authorization-panel/pull/254
* **no access** by default for apps (clients)
* which use case is this related to?
* [Access Modes](https://github.com/solid/authorization-panel/issues/253)

## Present

* Justin
* Pavlik
* Aaron
* Henry
* Sarven

## Minutes

### Previous meeting minutes

Henry: I made PR but there were some unclear and missing parts. I asked few questions inline.
Sarven: I can add commit to that PR

### No access by default for apps

PAVLIK: perception that apps always have all of the access a given authenticated end-user has, but using client-id it is possible to restrict access except for allowed clients. should be default to block any clients but permitted ones. Related conversation https://github.com/solid/data-interoperability-panel/issues/139#issuecomment-915102197

Sarven: Maybe we should create issue first.
In WAC: https://github.com/solid/web-access-control-spec/issues/81

Henry: I think we could/should be using discussions [Thinking in terms of proofs and Origins](
https://github.com/solid/authorization-panel/discussions/223)
Henry: I don't think this applies to HTTPSig. If the wallet is signing every request with the
key of the user. The wallet is authorizing access to the resource independent of the client app. The wallet is responsible
for enforcing user authorization on the client. Here server sees user making the request.

Justin: We have 2 dimensions to consider. Who's the social entity (eg. me) and the application which I use. Should we discuss it here? Do I want to restrict access to only subset of application which I use,
I would say yes, there is benefit.
Already work on Solid-OIDC provides us with `client_id`. HTTPSig can deal with this issue in a different way.
There seems to be notion that as soon as app gets token, it can access anything that user can access.
We don't want to create such perception. As soon as we review draft for ACP or WAC+ or something else.
We will evaluate it on how it gives restrictions on clients.

Henry: Note with HttpSig the Wallet can have policies about which apps it gives signtatures to for what sets of resources, so that this does not need to be done in server ACRs.
There seems to be a requirement for Solid-OIDC that requires servers to be authorizing clients.
This is not the case for HTTPSig.
I am ok to support the Solid OIDC use case.

Aaron: I see authorizing user vs clients as different dimensions. One would be authorizing users
/ social agents. The other one is authorizing clients. As soon as authorization system can
identify both it can do its job. I know that ACP allows that.

Pavlik: I would like to propose using GNAP terminology of End-user, client (instance), Resource Owner.

### [Access Modes](https://github.com/solid/authorization-panel/issues/253)

Justin: https://solid.github.io/authorization-panel/authorization-ucr/#collection-readcreatedelete

Justin: We have modes which are overloaded. Given write one can delete, create, update.
This leads to over permissioning agents. I think this should be more urgent issue to resolve.
I think aligning it around CRUD is not a radical proposition. Kjetilk has done really good job
describing the issue. I recall Matthieu suggesting to put it in separate document.

Pavlik: I'm not sure if protocol spec has to define both operations and access modes. Also how do we imagine mapping between those two?

Henry:
It is a great discussion. But it is branching a lot should we move it over to the discussions area, which also has threading.
I am trying to find mathematical backing for the decisions we could make. I think we have clearly Read/Write and there could be subsets under Write for Create Update Delete.
Delete is an interesting question: does it need permissions on the container?

Justin: I don't forsee coming back 6 months later or 6 years later and saying - i need another mode.
There has been some arguments that we will add some later, I think that our current set needs improvement
but after that they should possibly last forever.

Barath: I agree, that well chosen modes will last for long time. Even substandard modes serve in existing systems.

Justin: I think delete is good example, it can be set on the level of container and on individual resources. I don't see argument that there could be delete without implicit update of containment triples.
Argument that something else gets changed doesn't sound for me like recipe for good authorization system.

Pavlik: I think create and delete without allowing updating client managed triples in the
container is a good scenario that is needed to be addressed.

Sarven: If you look at access modes in a vacum there may be all kind of modes that can be discussed.
If we have protocol which has hierarchical containment ...
Protocol usually starts with read and write. When you interacting - making a request against specific
type of resource eg. container. It is processing operation, where protocol defines what happens.
In WAC in order to delete something, one needs to have write on the resource and write on container
containing it.

Another thing that seems to be conflated is resource level and content level.

towards framework.. https://github.com/solid/authorization-panel/issues/121
We still haven't solved that issue, it can help us clarify where each use case fits in.
I think we are ripping this issue apart instead of tackling it directly.
I see operations in the protocol territory. I don't think solution needs to demand some particular
access modes.

If we look at PUT, from HTTP perspective you either create issue first or in subsequent requests
you replace / update it.

Henry: I've been looking for some math that could solve this problem. We should try to reduce the space
We could assume that server has rights to do what it needs to do. I was mentioning lenses, java beans
had getters and setters. They steam from category theory, having getters and setters one can do CRUD.
I'm looking for papers on those topics. Clearly control isn't part of it. It seems to be a
different concept. We could remove control and focus how CRUD can be modeled.
I'm trying to understand why do you need access to the container. I don't think one needs write
on the container to delete resource. We can see if there are any potential security holes.

Justin: I'm able to delete comment in a container of comments. I should be able to delete mine but
not anyone's else. Delete on the container, meaning that it applies to all the comment would allow
deleting all the comments.

Sarven: Delete on the container doesn't imply delete on all the contained resources.

Henry: We can take your example and do our evaluation process on it. For example Sarven
could should how WAC can do it.

Sarven: Only the agent who has write on the resource can delete this resource.

Justin: Write includes delete but it gives another access as well.

## Actions

Pavlik: create issue proposing GNAP terminology

Henry: Propose using WAC to limit wallets to sign requests for apps.