# 2021-08-11 Solid Authorization

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

## Agenda

* Minutes 2021-07-28 - https://github.com/solid/authorization-panel/pull/245
* Effective ACR discovery - https://github.com/solid/authorization-panel/pull/244

## Present

* Barath Raghavan
* Sarven Capadisli
* Henry Story
* Elf Pavlik

## Minutes

### Welcome Barath

Barath: There is some interesting material on https://lamport.azurewebsites.net/tla/tla.html.
Someone used it to model an access control system https://arxiv.org/pdf/1806.09848.pdf.

### Effective ACR

Henry: If you have to use the default ACL, the client will have to make 1 request per container to go all the way to the default.

Sarven: You can't pick a random number of depth in container hierarchy. You can have a simple solution where 1 access control is on the default directory and you have 1 level deep.

Henry: I asked how it is meant to be done and this is what the process costs in terms of requests.

Sarven: What is the criteria for fixing it? Is it the number of requests?

Henry: Having a default is not a bad idea. It is a complicated process to get there.

Sarven: To be clear, there is nothing that the WAC spec prohibits having each their ACR.

Henry: I'm following the process that has to be followed and writing it to a wiki.
It's not unworkable, it just has a lot of requests and is a bit inefficient.
Do you disagree that this is inefficient or have I missed something?

Sarven: I agree that this could be more efficient, but what are you going to adjust?

Henry: My idea is to address it with the minimum changes to WAC.
Here I can think of for example the rel link having a mime type `application/trig` which would be a quad representation. In which case, the server could return a graph with no content in the graph of the resource but tell you what the default graph is. With one get, you get the default ACL.

Sarven: I think I'm a bit confused. There is a slight difference between the spec describing how the default works and allowing implementations to work their own implementations. 1 GET to the ACL would give you everything you need to know. As long as the server generates default authorization rules when a resource is created.
The change that could be on the spec level would be if it prohibits that possibility from happening (ommit a representation from an ACL).
The spec can say all references to an ACL must have a representation.
Currently, that the thing we don't enforce.

Henry: There are two answers: with the trig or n3 serialisation would allow us to have the graph of the resource marked empty and the graph of the default thrown in.

Sarven: What you're describing is for the client, because the server already knows which is the effective ACR.
So how would you update the ACL that includes the trig.
I'm assuming that when you update.

Henry: Trig is a named graph, so you need to do a put on the named graph. If each named graph has a name. You do a put on the URL of the named graph.

Sarven: What it is really cutting down is the worst case scenario.

Elf: If you have a named graph, you cut the requests. You don't have to do the extra requests.

Matthieu: I don't think the relation between a named graph and a resource has been properly specified yet. So where should we specify it in the specification?

Henry: There is a way to specify where all the named graphs are true and all the statements in each named graph are in the default graph. We would need to check whether it is sound technically.

Sarven: I get that the recommendation could be to go directly to the source.
It is a bit convoluted. Grabbing data from a resource and putting it into that resource could be tricky.

Henry: The other optimisation I had in mind is for the server to use an import of the default. Then you don't need to deal with the trig.

Sarven: I feel like the use case we're trying to improve is maybe not grounded in how people actually organise their data. Not to reject the possibility of optimising that part, but I'm not sure the energy put into that question is required.

Elf: As a user, I would have one authorization agent running on the server. There would be no applications ever writing to my authorization. Are we assuming that there are random apps that would write to my access control resources?

Sarven: How would you give access to someone?

Elf: I would delegate to my authorization agent.
It would be similar to IdP, a server side app that would record authorizations in my storage.
All applications would need to gain knowledge of existence of a resource first.
Then I don't want too many applications managing access.
I would have one that I fully trust and has access to my address book and all the other apps would interface with that one authorization agent.
From my perspective, I would never want more than 1 application to write to my access control policies.

Henry: If you go on the SSI technologies vocabulary, your agent would have access to a wallet. You'd follow links arrive on a server find the ACL and find out what you need to present in order to access.

Elf: I'm talking about writing the rules, not reading them.

Henry: Of course you want your trusted agent to do the writing but also the reading.
Whether a client needs to read or write, they need to follow their nose to the ACRs.
You want to have your credentials in very tight control.
You're just putting that wallet on the server, I want to also have the possibility of having it in the client.

Henry: I think Elf is asking who is the client?

Elf: I try to look at it not in the abstract but how human beings would use it.
I think everyone wants a uniform interface to define my ACRs.
1 app I trust and that will be setting the policies in a responsible way.
I would feel incomfortable with 10 different interfaces.
I'd let an app like dokieli discover my access control but only set access through my authoriztion agent.

Sarven: I think it's an arbitrary restriction. What is the difference between an authorization app setting the rules vs another one?

Elf: In that case, my dedicated app would have the level of access I have. As a user, I never need to choose whether to give "control" to any other app.

Sarven: Who tells the difference between an authorization app and a not authorization app?

Henry: That sounds like my launchar app. Only app you want to use in a new frame in the browser. And whenever for example my calendar app wants to access a resource, it goes through the launcher app to find out whether to give that to the client. Once the launcher app signed an http header.
Unless you have a proxy for all your apps.
There are many options.

Elf: Also, we have to be careful, for example, if there are 5 or 6 requests, how often does it get used and how important is the overhead? I'm not sure it is very significant.

Henry: Looking at this question it seems to be obvious.
I've already implemented trig on my server and also owl:imports and trying to implement groups now.
It's interesting because we started off with monads and named graphs so I think we've already covered quite a lot of ground.

## Actions

* Matthieu to polish and make ready for review https://github.com/solid/authorization-panel/pull/183