# W3C Solid Community Group: Authorization Panel

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

## Present
* Matthieu B
* Henry S
* e Pavlik
* Barath
* Emilia Smith

---

## Introductions

* Emelia: I work with Matthieu and more specifically on the SDK which is Inrupt's JavaScript client for Solid.

## 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
*
* Matthieu Bosquet (extra)

## Topics

### Previous meeting minutes

[PR#279](https://github.com/solid/authorization-panel/pull/279)

* Henry: I will look at the comment and add a PR on the merged document later.

### Added evaluation for 2.5.2 client-constraints

[RP#278](https://github.com/solid/authorization-panel/pull/278)

* Matthieu: LGTM happy to merge.
* Pavlik: It just shows how ACP can express that for given agents specific clients are allowed.
* Matthieu: Can we commit this one and add more in next PRs ?
* Pavlik: +1
* Henry: It needs a bit of explanatory text and some details of what the rules are.
* Matthieu: I agree with Henry, we could work on it a bit this week and try to review a more comprehensive example with WAC next week.
* Elf: We could also just use an issue.
* Matthieu: Whatever is easier.
* Elf: I would prefer creating multiple PRs.
* Henry: Since you're happy Matthieu, and it is describing ACPs answer, we can commit. I will then make a new PR to see how WAC does.

### Security issue for WAC

* Henry: There was a security issue mentioned one the specification gitter channel, and I was wondering if we had that documented.
* Matthieu: I'm not sure where, but I think it has to do with the effective ACL discovery and inherited access being over-written.
* ...: Perhaps we could ask Sarven or someone else historically involved to point us to the details of this.
* Henry: Yes, it would be important to know what has been found.

### Authorization Server

* https://github.com/solid/authorization-panel/discussions/271
* https://solid.github.io/data-interoperability-panel/specification/#data-grant
* https://github.com/solid/solid-oidc/pull/18#issuecomment-974897450

* Elf: Traditionally in OAuth, the access token is responsible for authz. It should give access including the notion of scopes. We don't have that in Solid.
* ...: What we have in interop shows there is an AS and AA. You can see the example of a data grant. It's a way that always has one grantee. This is a projection on the user. That's where the application starts discovery.
* ...: [The data grant tells you what you can access](https://solid.github.io/data-interoperability-panel/specification/#data-grant).
* ...: Interestingly, you can also delegate data grants. A delegated grant is equivalent to OAuth scopes.
* ...: In the PR, you can see that the resource server doesn't have to understand the grant. The AS issues an opaque token. And using token introspection, you could get understanding of what can be accessed.
* ...: The AS could for example write appropriate ACRs on the RS.
* ...: The application refers to the original data grant and the AS can verify that Alice gave access to Bob there. It is mostly now about coordinating the details of this AS. In other words agree on which parts of the delegated data grant to include in the Authorization Token.
* Matthieu: We need to agree which parts of data grant get included in claim token.
* Elf: In the end the Resource server has to enforce that.
* Matthieu: In my mind, the RS talks to the AS and if the AS says agent X has the correct access modes, it performs the entailed operations accordingly.
* Elf: The source of truth would be the AS and it would incorporate the delegated data grant. Bob is using their authorization agent to set the authorization grant. What I say is that ACP is one way that could enforce such data grants. Who's actually enforcing that? The AS is deciding who can have access but in the end the RS serves the resource.
* ...: In my opinion the client should not need to understand anything about ACP, just the data grants. The RS should not have to understand data grants because the AS has a way to coordinate with the RS. So in a way the AS would pretty much translate the data grants into ACRs. AS would need to understand both (ACP and data grants). The RS would have data grants and project them as ACRs.
* Elf: One question here is how Alice is setting the access policies?
* ...: The way Alice is granting access to Bob, it's Bob's choice what client they use. So Alice gives access to Bob and Bob gives access to a client (delegated data grants, narrowing access). So Bob can delegate read only access to a client using a data grant.
* ...: Alice uses her authz server. I don't think Alice sets ACRs, Alice uses a UI. Bob uses his authorization agent.
* Matthieu: How do data grants and verifiable credentials relate to each other?
* Elf: Possibly linked data capabilities should need to be defined. Really we're trying to respond to the problem of OAuth scopes. The app doesn't know what Alice gave access to for Bob.
* Matthieu: So the data grants vocabulary is the important part here that allows us to define a scope of which resources and access modes for something.
* Elf: I think the approach I'm describing here the AS would set the permissions and the users would not use a random client to set permissions. They should use a client that they trust. To understand what the consequence of their decisions is.
* Emelia: I think there might be different thing here. There exists Access Grants that work through signed JWTs that's a way (Alice creates a grant and Bob exchanges it from the AS for an access token).
* ...: As far as I recall the only entity that can change ACRs is the owner of the resource. So Alice could allow access to Bob but Bob would not as not owner be able to change the ACR. I don't think any client should change any ACR.
* Henry: I have another answer which I'll implement in a month or two. I can also show how one can do it in a declarative way. But I've talked about it for about 2 years, so I should implement it to prove the launcher app works. I think the best is to implement both and see what the commonalities are.
* Elf: I think the important bit is the user having one UI or trusted App to set permissions. One place where they set them and they understand how it works and the consequences. The authz agent is the same sort of thing.
* Henry: Perhaps one should start with questions. Your main claim is one app to do all authz (but it can do it only on one server).
* Elf: Alice's authz agent would be aware of all the access granted to and by her.
* ...: Both a launcher app and authz agent would have similar roles, but instead of living on a device, the agent would be a service in the cloud.
* Henry: Let's keep in mind the follow your nose approach. For example if access was granted to the friend of a friend.
* Elf: If access was not explicitly granted, there's still a question of discovery. They are slightly different scenarios.
* Henry: What you're doing is similar to an inbox.
* Elf: Yeah, in interop there are access receipts and access inbox. From thereon we use the notification system such as webhooks. Because there are problem with public inboxes.
* Henry: I think from a WAC/ACP perspective, what Matthieu and I need is a brief presentation of exactly what you need from an interop perspective. And then if we know precisely what it is, we can have a proposal.
* Emelia: From a cursory interop spec review, it seems that there's a lot that is re-defined (or already defined in authz such as ACP).
* Elf: We need to collapse things on Agent rather than collapsing on resource.
* Emelia: Might be worth mentioning that currently, Inrupt's solid client defines ACP as a separate resource. I'm not sure it might collapse as you say.
* Elf: If you have a memo resource, the ACR of that would say what agents can do on them.
* Matthieu: Yes, collapsing per user would be super expensive as per current implementation of ACP.
* Elf: Yeah and data grants do it the other way.
* Henry: But why would you need a different ontology?
* ...: There is a way to express the same kind of thing with the WAC or the ACP ontology.
* ...: It's a problem because everytime you're creating a new ontology to say the same thing, it's clutter. The first thing would be good to know whether you can just use something existing to say the same thing.
* ...: If interop is about interoperability, it would be good that it reuses existing ontologies rather than creating a new one.
* Elf: We reuse access modes.
* Henry: Why the new predicate?
* Elf: because the access modes are object of a statement where the subject is an access grant.
* Henry: One might do a mapping from WAC to this ontology.
* ...: I've used the accessTo predicate for many things and I think it's there in the ontology.
* ...: I think if we could simplify it would be really useful.