# W3C Solid Community Group: Authorization Panel

* Date: 2021-11-17T14:00:00Z
* Call: https://meet.jit.si/solid-authorization
* Chat: https://gitter.im/solid/authorization-panel
* Repository: https://github.com/solid/authorization-panel

## Present
* e Pavlik
* Aaron Coburn
* Justin B
* Henry S
* Matthieu B
*

## Regrets
*

---

## Announcements

### Meeting Recordings and Transcripts
* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
* Use panel chat and repository. Queue in call to talk.

### Participation and Code of Conduct
* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/)
* [Solid Code of Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/)
* If this is your first time, welcome! please introduce yourself.

### Scribes
* Henry S
* e Pavlik

### Introductions
* name: text
*

---

## Topics

### Questions about graphMetrix implementation

Frederick Gibson (Fred): I am the ceo of Graphmetrix.
We have been around for a couple of years and provide Solid Pod server and App.s
Out apps is a productivity app suite (similar to Zoho(?))
We have a digital twin system inside the pod service.
We of course try to be 100% compatible with Solid to interoperability.
Elf: We discussed authz related topics yesterday and your implementation came up.
JustinB: The main question that myself and Barath were interested in was:
Barath was under the impression that you don't have / URI semantics, ie containers end in `/`.
Frederick Gibson: We fully support the solid spec.
Every container in our system has permanent URI, so that the same resource can be in multiple containers.
JustinB: ah, that is good to know.
The context of the discussion was not just about this, and about authorization and how you deal with access control and inheritance and containment.
Fred:
The current system would not work with us.
We move the agent check inside the loop.
...
The problem is copying the data around.
Henry: Which issue are you talking about? Can you put link in our notes.
Fred: https://github.com/solid/web-access-control-spec/issues/102
Pavlik: Based on what do you apply inheritance?
The URI / paths or ldp:contains statements.
Fred: ...
* Henry: We discussed this in issue 102 a bit, I'm all for changing WAC where we can to fix problems, rather than re-inventing the whole thing.
* ...: I definitely see that having a default rule is very useful, as it avoids copying rules all over the place.
* ...: I see a problem with requiring the user to be logged before the server can determine if you the app can see something an ACL or what part of the ACL it can see.
* Fred: There is no change how WAC works now, just getting ACL first and checking the user in the loop. Instead of returning all ACLs it returns only relevant ACLs to whoever gets access.
* Henry: I believe that you can't build decentralized system if the client needs to the access rules first. I want client to know the access rules for the client to know which credentials it should present.
* Fred: I'm little confused now, in our server user has a token. If it's public we would only return permissions for the public. If there is token we know who the user is.
* Henry: We have set of use cases that try to go beyond the current capabilities of Solid. Solid started with very simple use cases. In order to avoid complex problems of privacy of access rules, Solid led people to limit the ability to see the rules. But that also limits the systems that can be deployed. See [minimal credentials disclosure use case](https://solid.github.io/authorization-panel/authorization-ucr/#uc-minimalcredentials) to see the problem that we want to be able to deal with. Where either resources are private to owner of the box or need to be public. I want it to be possible where people have different WebID, different Credentials etc.
* Fred: Even today I can have 100 email addresses, I can use them to authenticate to different systems. I never assume that my personal will use when I need my work.
* ...: For authentication purposes I will just have one WebID to make my life simple. If I have 5 i need to decide which one I use where.
* Justin: I think it would be useful to have your (Henry's) approach written down. This is good discussion which should be captured.
* Fred: You could make group of WebIDs and use that to grant access. With that you wold just use group to that access.
* Henry: yes, that works on systems we use today. When you go to Twitter you know what ids you have used there, but on open systems like we want to build people could create rules that allow people access under Identities or credentials that the user's App does not know about in advance.
* Matthieu: I find an idea of virtual hierarchies interesting. Do you have them documented
* Fred: In issue 102 I have it documented.
* Matthieu: I refer how do you map containment to uri paths.
* Fred: Each user has their own named graph. For each resource which needs URI path we include tag predicate. Our system looks at path uri and looks for the resource using that tag.
* Matthieu: It would be interesting to fill it back in the solid protocol. Solid is very undescriptive how to deal with containment.
* Fred: Are you suggesting that we propose it to solid spec?
* Matthieu: I think this would be great. I see this problem very important.
* Fred: Where I should explain it?
* Matthieu: solid-specification repo
* Justin: +1
* Pavlik: If resource is in many containers, how do you do inheritance of access rules?
* Fred: We deal with that by doing union to define ACL if one of them gives them than they get it.
* Matthieu: So ALC is still linked to the resource not it virtual hierarchy?
* Fred: ACL can be on the resource or on the container.
* Matthieu: There is ACL for one URI
* Fred: We have ACL object and we don't limit how many ACLs you can apply to a single resource, we just put them together. They are applied to the permanent URI. Paths are just public facing phenomena. Those are dynamically generated on the fly. Even if you move container the permissions would stay with it since they are connected to permanent uri.

### Commit previous meeting notes

https://github.com/solid/authorization-panel/pull/272
Meeting notes merged

### Next steps for ACP draft

URL: https://solid.github.io/authorization-panel/acp-specification/

* Justin: I haven't been driving spec writing or implementing. I know others were actively involved in doing it. I believe that draft is at a point where it can go through the next steps. Where it would be evaluated for the protocol. I don't think we can accomplish more here before we have that debate. We should also have implementations like CSS which wait for ACP. We have community looking for resolutions for problems that ACP addresses. I don't think we need to determine that nothing else is possible before we evaluate ACP further.
* ...: Can we start it now or we still need to wait.
* Matthieu: I have identified one major design spec which not makes it orthogonal to solid and other systems as it stands. I want to correct that and release TypeScript implementation of ACP before Jan 1st. After that I would like to move to what you are describing.
* Justin: That's great! It's good to have clarity on the path there. Please share the problem once you document it.
* Matthieu: I will open github issue.

ACTION: Matthieu to open GitHub issue documenting the design flaw.

### Constraining clients (apps) should be scoped to a user (social agent)

URL: https://solid.github.io/authorization-panel/acp-specification/#client-matcher & https://solid.github.io/authorization-panel/acp-specification/#policy-satisfaction

* Elf: The user should be able to constrain what applications should be able to do on their behalf.
* Looking at the ACP spec we have

    ex:matcherA acp:client ex:clientB

* How would
* Mattieu: We can have user/client combination
* If you want to restrict clients with specific users you would just pair them together.
* Elf: I will write up an example, and you can tell me if it works out.

### Access Matrix, collapsing by resources and agents
URL: https://github.com/solid/authorization-panel/discussions/203#discussioncomment-610302

* Elf: We want to express access Matrix by agent (bob has access to r1, r2...) and resources (resource is accessible for bob, alice...).
* Justin: I think we're talking about several different concepts here. The reason for tackling such concepts in interop is in order to have agents interoperating over data, you need understanding of the data and applications able to express which data is accessible without any knowledge of what data is accessible without understanding of what data is on alice's or bob's pod.
I'm gonna give app1 access to my tasks.
The end user is not gonna be able to think in terms of what access is on a specific folder and what is contained there unless you go the traditional 1 application root.
Most people don't have access management on their mobile phones.
We have in the interop spec concept of access grants non specific to ACP or WAC.
* Elf: When we get to Solid OIDC changed it will allow equivalent of OAuth scopes, allowing the ID Token and Data grant to work together. Data grant would provide the scopes functionality. ACP or WAC would need to work well with data grants. Where based on data grant ACP or WAC rules can be generated.

### Overlap with AuthN panel
URL: https://github.com/solid/solid-oidc/issues/30 & https://github.com/solid/solid-oidc/pull/18

* name: text
*

---

PROPOSAL: text
* name: +1,0,-1
*

RESOLUTION: text

ACTION: text