# W3C Solid Community Group: Authorization Panel

* Date: 2022-09-28T14: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 Bosquet
* Elf Pavlik

---

## 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

---

## Topics

### Fix Authz Panel CI

URL: https://github.com/solid/authorization-panel/pull/317

* Matthieu: Does that PR look good to fix the panel CI?
* ...: Are we OK with merging?
* Elf: Yes. Done!

### Remove acp:mode from Context properties

URL: https://github.com/solid/authorization-panel/issues/311

* Matthieu: Are we ok to push through Tim's proposal?
* Elf: Just to double check I understand the issue.
* ...: The RS should get the access modes back but was the AS supposed to interpret the access modes requested?
* Matthieu: The initial idea was that the RS could indicate exactly which modes are required which might allow the AS to return early. However it doesn't really fit well with the ACP resolution algorithm.

PROPOSAL: Removing `acp:mode` from the spec: https://github.com/solid/authorization-panel/pull/314
* Matthieu: +1
* Elf: +1

RESOLUTION: Approved.

ACTION: Merge PR.

### Matching contexts that contain a client/issuer

URL: https://github.com/solid/authorization-panel/issues/312

* Matthieu: That issue is about matching contexts where there is a client as opposed to contexts where there is no client.
* Elf: Is it related to the conversation where we said matching the client is mandatory.
* Matthieu: In some ways. It is tangential.
* ...: Here we acknowledge the fact that there is possibly some contexts in which there would not be a client, that is unmitigated access, for example, server to server.
* Elf: But doesn't the Solid OIDC ID Token requires a client ID?
* Matthieu: I think that requiring a client_id claim in ID tokens is a mistake. Clients should be required only if agent is using a Client.
* ...: That said, maybe you wouldn't use Solid-OIDC for unmitigated resource access.
* Elf: OK, but no client is a bit unrealistic because whatever performs the HTTP request is the client.
* Matthieu: I think it's important to make the distinction between User-Agents (say a Browser, CurL, Postman...) and a client in the Solid sense, that is, an HTTP application identifying itself via a Client ID Document.
* ...: I think in the latter case, Solid will very much care about restricting access based on client identifier documents.
* ...: But in the former case, there is no natural way for the client to assert its identity. Hence it falls in the "Any" vs "Public" (or no) client category of distinction.
* ...: A CurL running on your desktop cannot authenticate in the Solid OIDC sense... Hence there would be no client to match in that case. Which is different from matching any client.
* Elf: https://github.com/solid/solid-oidc/blob/main/alternative-flows.md
* Elf: What do you use for authentication there?
* Matthieu: That's the thing. I don't really want to discuss Solid OIDC, but I want to acknowledge the fact that an Authorization Server might receive a request in a client-less context. And specific rules should be possible to express against that kind of scenarios (in other words, being able to say in ACP that it is different to have 1 or no client).
* Matthieu: An "AuthenticatedClient" matcher will fail if there is not a client. A "PublicClient" matcher will succeed if there is not a client.
* Elf: So it's like "AuthenticatedAgent", the agent needs to be present if "PublicAgent" it will not need to have an agent.
* ...: Ok, so ACP uses public agent in the same sort of way as WAC?
* Matthieu: Yes.
* Elf: This sounds like [my comment](https://github.com/solid/authorization-panel/issues/292#issuecomment-1063600607) on secure defaults for client access issue.
* Elf: What happens when a matcher does not specify a client attribute compared to the case where the matcher specifies a client attribute matching the "PublicClient"?
* Matthieu: If a matcher specifies a single client attribute matching the "PublicClient", then it will be satisfied if any or no client is used (in other words, all contexts).
* ...: If a matcher does not specify a client attribute, then it will need to match on something else (for example, agent or issuer...). In other words, a Matcher that does not specify a client attribute will not be satisfied by a client but might be satisfied by something else.
* Matthieu: Via Authenticated client now you could say that a client is required (disallow unmitigated access). Consider the following policy:

[]
  acp:deny acl:Read, acl:Append, acl:Write, acl:Control ;
  acp:allOf [ acp:client acp:PublicClient ] ;
  acp:noneOf [ acp:client acp:AuthenticatedClient ] .

* Matthieu: In that example policy, all access is denied except when there is a client. That addresses [your comment](https://github.com/solid/authorization-panel/issues/292#issuecomment-1063600607) in some way because it is a way of denying unmitigated client access.
* Elf: But isn't the deny a default?
* Matthieu: The default is that nothing is allowed.
* ...: Not that everything is denied.
* ...: Deny acts as a thing that trumps everything that is allowed (something denied cannot be otherwise allowed).
* Elf: Let's look for example at the [client constraint evaluation](https://github.com/solid/authorization-panel/blob/main/proposals/evaluation/uc-2.5.2-client-constraints.md) (simplified):

PREFIX acp: <http://www.w3.org/ns/solid/acp#>
PREFIX acl: <http://www.w3.org/ns/auth/acl#>
PREFIX ex: <https://example.com/>

ex:ReaderAgentPolicy
  acp:anyOf ex:BobMatcher ;
  acp:allow acl:Read .

ex:BobMatcher
  acp:agent ex:Bob ;
  acp:client ex:Projectron .

* Elf: and discuss the difference between those two matchers:

ex:BobMatcher
  acp:agent ex:Bob ;
  acp:client acp:PublicClient .

ex:BobMatcher
  acp:agent ex:Bob .

* Matthieu: The matcher where Bob and the ~~Public Client~~ Authenticated Client (Note to reader: I thought we were discussing Authenticated agent) are required to satisfy authorization will require Bob using a client.
* ...: The other matcher will be satisfied if Bob does not use a client as well.
* Elf: Could you write the second case context

[]
  acp:target ex:resourceX ;
  acp:agent ex:Bob .

* Matthieu: The above context being client-less will resolve successfully if acp:client acp:PublicClient is not required.
* ...: Really it is just a case of unmitigated resource access. If we say unmitigated resource access exists, then the AuthZ domain needs to be able to express this.
* Matthieu: Sorry I meant "for acp:AuthenticatedClient", I thought we were discussing unmitigated resource access.
* Elf: In ACP if you ommit acp:agent in the matcher, any agent (incl. no agent) will match? Assuming other properties in the matcher.
* Matthieu: An empty matcher is never satisfied.
* ...: This issue [312](https://github.com/solid/authorization-panel/issues/312) is really just about acknowledging the existence of unmitigated client access.
* ...: I agree that the "Public" named individuals are a bit misleading because they are not matching on a specific attribute, we could consider creating an always matcher instead...
* Elf: Ok, I see how AuthenticatedClient makes sense.
* ...: So as soon as you have a non-empty matcher the attributes targetting a "Public" named individual can be ignored?
* Matthieu: Yes. And empty matchers are never satisfied.
* ...: For example, the following Policy will never be satisfied because the empty matcher of the allOf condition will never be satisfied.

[]
  acp:allow acl:Read ;
  acp:allOf [ acp:agent ex:Bob ], [] ;

* Matthieu: On the other hand, in the following Policy, the second matcher adds no value. It will be satisfied if Bob is the agent.

[]
  acp:allow acl:Read ;
  acp:allOf [ acp:agent ex:Bob ], [ acp:client acp:PublicClient ] ;

* Elf: So in other words, you cannot say that Public is default because of that empty matcher edge case.
* Matthieu: Indeed.
* Elf: As long as you have non-empty matcher, any additional attribute with public value could be as well omitted.
* Matthieu: And the public matcher is always satisfied which is useful to create an allow list for example (see my Public vs Authenticated client example).
* Elf: I don't know if it would be more consistent to allow things by default in an empty matcher.
* Matthieu: No because that would be a case of open by default, say if you removed the last attribute of a Matcher, then you would potentially open a Policy by default. To be perfectly honest, some of this should be addressed by specifying an Access Control Resource representation format (disallowing empty matcher/and Policies with no conditions...). But even then, we will want to keep the part of the ACP resolution algorithm enforcing that empty matchers are never satisfied.
* ...: Let's follow up online with an issue

PROPOSAL: Named individuals matching contexts containing a client/issuer: https://github.com/solid/authorization-panel/pull/313
* Matthieu: +1
* Elf: +1

RESOLUTION: Approved.

ACTION: Merge PR. Create an issue to discuss Public named individuals and empty matchers.