# W3C Solid Community Group: Authorization Panel

* Date: 2022-04-06T14: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
* Sarven C
* e Pavlik
* Wouter Termont

---

## 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
* Pavlik
* Matthieu

---

## Topics

### PR adding inline issue to Solid Protocol: Authorization

https://solidproject.org/TR/protocol#authorization

* eP: Solid Protocol should have an inline issue signaling that other authorization systems are being proposed.
* ...: I can take an action to create issue and PR adding it inline to the spec but would like to have quick discussion around it.
* SC: Doesn't need to "signal" anything now or have an "inline issue" - that's not even the right way of using inline issues. In the same way we don't throw in placeholders or have random stuff from the work items listed under https://solidproject.org/TR/ . Or in the same way, we don't throw in alternative solutions to Authentication, or interop in the data interop specs.. -1 to action item. Distraction.
* Matthieu: To my understanding currently protocol requires WAC compliance, and Pavlik has concern that it doesn't leave space for other AuthZ specifications. Is that correct?
* eP: Yes, for example, if you have an ACP AS, does it still need to be compliant with WAC.
* MB: I assume that currently server supporting ACP would also need to comply with WAC in order to be fully Solid Protocol compliant.
* SC: The process is that if you introduce a new item or feature it explains how it fits in. If ACP says that it works along WAC than we evaluate it based on that. I know that there is open discussion how this stuff works out. You don't want to break requirements that we have right now.
* eP: How do we get to 1.0, is there still gonna be breaking changes?
* SC: Well, if you want WebID TLS out, then I guess that everything can be thrown out including Solid OIDC.
* ...: All panel discussions are non-commital, it is a research project (no matter how you want to frame it). There is a number of work items and we're not throwing everything into the protocol because it would be too confusing.
* MB: What would be the best way to propose or specify a way in which server could use either ACP or WAC or lets say an Authorization Interoperability framework?
* SC: I don't know, is there a protocol or something that works.... Is there a solution in place explaining how they could work together. We can only look at that when there is proposal on it. We are not putting HTTPSig as alternative or how we can make it work with VC Auth. I refer back to implementations, I don't see implementations. Why solid editors should spend time comping up with those hypothetical combinations/solutions...
* MB: So the best way would be to start with an implementation. We have different implementations in the wild. CSS wants to implement WAC and ACP - both. ESS implements both and mostly runs on ACP. There are other server implementations which work on WAC. We can feed back impl experience from there. How do we feed that implementation experience?
* SC: I was going with an example of solution X or Y. If implementation shows how X and Y can be used at the same time then ok. There seems that there is some kind of goal in mind. I don't know how solution looks like on X or Y. If anything can be replaced make the case on why something can be replaced.
* eP: We're still pre-1.0 so it's a better time to make breaking changes. I think it's good to talk about ACP as there are potentially two implementations (CSS upcoming and ESS current). If we don't resolve this conversation, I think it warrants having a conversation inside the spec that something needs to be resolved. Because the current spec doesn't reflect what is needed. It's not currently answering any solution to that topic (which is better than misleading the spec that nothing is to anticipate).
* SC: Just taking an example, I assume that all specs and panels are mostly ED.
* eP: We're adding more inline issues in OIDC because we think it's better signaling the potential changes.
* SC: We're not talking about specific requirements or alternative solutions to a need, you're talking about a whole component. We have the technical reports documents, all of the work items in Solid TRs are too many to add to the Solid protocol.
* ...: Specific requirements being controversial... Why does WAC require this bit or work that way? We had an issue about using registering the "acl" type rel or a URI for resource discovery. WAC is required and it would not be a surprise that WAC is required in 1.0. We agree that other aspects are needed and we'll take that up when there's a PR for it. There are considerations on how these specs work out (extending WAC/ACP/interfaces...) that's on the table. For example, if it can be shown how ACP extends WAC or can work alongside WAC, then that's a good way of approaching how to deal with those different specs.
* SC: What you want sounds fundamentally about addressing https://github.com/solid/authorization-panel/issues/121 .
* SC: ACP/WAC/ODRL might be required for different bits and if it's clear how they can work together, then we'll go with that.
* MB: I think it's pretty clear, elf, anything else?
* eP: I think I'll still create an issue and PR, I prefer having push back on that PR.
* SC: I'm telling you that solving [121](https://github.com/solid/authorization-panel/issues/121) is a good way to go at it. This is not just about WAC or ACP... Because we need a proper view of extensibility.
* SC: I'll have to jump off.
* eP: It would help to document ACP in ESS.
* MB: Everything supports either or, i don't know of a pod that have WAC and ACP at the same time.
* WT: Would there be a benefit of using both WAC and ACP in the same solid storage?
* MB: There is a lot in WAC specification that is not about expressing permissions: effective ACL discovery, access modes discovery (wac-allow header), access modes used... The declarative permissions bit is quite small in WAC and that is most of ACP (it's a domain model).
* ...: It's probably good to choose between one domain model for declaring permissions or the other (ACP or ACL).
* eP: I also created https://github.com/solid/specification/issues/377 talking about storage types.
* WT: I agree that after 0.9 can be 0.10 0.11 etc. It's not penultimate to 1.0.
* eP: Matthieu as editor of ACP do you see it ready for FPWD? We can think of it as 0.1
* MB: I don't know what the implication is of tagging it this way. I find answering #121 more important.

### ACP Context attributes

https://solid.github.io/authorization-panel/acp-specification/#context-attributes

https://github.com/solid/specification/issues/379#issuecomment-1090235543

* eP: I'd like to discuss it considering that AS and not RS might be evaluating the policies.
* eP: My understanding is: the RS provides context to the AS and AS runs the ACP engine and respond to the resource server with allowed or disallowed?
* MB: The interface between AS and RS in the response is mainly the set of access modes. RS provides description of the request (the context), including full representation of the effective ACR. The AS reponds with set of access modes, which may be empty.
* eP: context includes `acp:mode` why AS would repond with a list of modes. This is good reason to say we work on ???.
* MB: The interface between AS and RS would be describing the request and getting back set of access modes. Especially even more in the response. Both should be understood by the AS and RS.
* eP: I try to understand the case. Say on a get request, the server creates a context and post the access mode (Read), the response to get could include that you can do more than Read.
* MB: So my intent in describing (potentially) the access modes requested is that it might enable some interesting optimisations on the AS side. Once you found answers you are done. But if you didn't specify any mode, you might get all the possible ones back.
* eP: Is the AS responsible to fetch all the Policies the ACR depends on?
* MB: RS and AS could have a dialog and AS can query RS multiple types. RS may entrust AS with entirely with the authz graph. The important part is that there is a trust relation between RS and AS. My preference would be to leave the AuthZ graph to the RS since it makes it more portable. 8
* eP: The RS as I understand is not responsible over the policies (say if they are external). Possibly, the AS may not even have access to those resources.
* MB: I have no strong opinion to any of this. I care that the ACP engine is able to have access to a full authoritative authorization graph (the full ACL representation in other words), and this requires full trust. You can't deference polices comming from about anywhere because it's unsafe.
* eP: Do you remember that we talked about Data Grants spanning accross multiple Resource Servers? If they define different ASs, what trust is required?
* MB: Sorry, I need to drop off.