owned this note
owned this note
Published
Linked with GitHub
# W3C Solid Community Group: Authorization Panel
* Date: 2022-04-27T14:00:00Z
* Call: https://meet.jit.si/solid-authorization
* Chat: https://gitter.im/solid/authorization-panel
* Repository: https://github.com/solid/authorization-panel
## Present
* Justin Bingham
* Laurens Debackere
* Elf Pavlik
* Matthieu Bosquet
---
## 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
* Elf Pavlik
### Introductions
* Laurens Debackere: Working on research with Solid Lab and digital Flanders/Flemish gvt to implement use cases (UMA using access grants and data grants from the interop spec to generate access tokens). Would like to understand how access modes (acl:append and acl:update) really mean from an authorization service's point of view. Did mostly WAC work rather than ACP.
---
## Topics
### PR 300: Deprecation of ACP access
* See also: [PR 300](https://github.com/solid/authorization-panel/pull/300) and [issue 277](https://github.com/solid/authorization-panel/issues/277).
* MB: It is basically getting rid of a redundant property and aligning on WAC.
* JB: It did always feel like a piece that wouldn't really be needed. Good for me.
* EP: I just approved it. In the issue, my main concern was about access for the access control, but it didn't seem like a common requirement.
### Access Modes
https://github.com/laurensdeb/interoperability/issues/42
https://github.com/solid/authorization-panel/issues/253
* LD: The implementation I've done is based on the CSS which uses in terms of access modes uses Read Write Append and there is the new Update mode used in the interop which isn't used anywhere else in Solid. I'm not sure what the difference between Update and Append.
* JB: In the interop spec, in the [access section](https://solid.github.io/data-interoperability-panel/specification/#access-scopes) there is a table enumerating each mode (Create Update and Delete). I've been pushing to get more granular modes in line with CRUD at the protocol level. I think that the current modes are a security problem. So we define what's intended by the grant.
* LD: Right now we're close to WAC. I'm pretty sure that my implementation aligns with the spec except for Update.
* ...: If you perform a PUT or a POST on a resource, right now modes are mostly defined in terms of Write and Append.
* JB: Currently, these modes are overloaded. What I propose still provides full backwards compatibility, but introduces more granular modes, that is, you can still have Write and Append, but you get more security and clarity by using the Update and Delete modes.
* LD: What I'm going to be looking into is that in checking whether we could use the more granular modes in the CSS and perform the compatibility check. I think it will be better to perform the translation that way.
* LD: Do we intend to normatively say in an authorization service that it should interpret ACP or WAC and that other services (like the interop spec) should translate to it or can we use the Data Grant from the interop spec to get an authorization?
* EP: Are we asking what the RS has to conform to or what the AS has to conform to? The question would be what the AS needs to support? I wouldn't generalize.
* ...: If we go from the RS perspective, now implementation specific in coordination to have the AS or RS supporting ACP or WAC? From a previous discussion, it sounded like Matthieu thought that the AS would interpret ACP.
* LD: I think that's the main point for me. An authz server can implement any access mode implemented from an authz service and also support other mechanism like VC and so on.
* ...: A lot of code related to authz is hard to pull out of the CSS. For example how access modes are interpreted is very tied into the CSS code. For the CSS server, there is a tied requirement to understand which access modes are required for an operation.
* Matthieu: The way I see it. Access modes should be the common interface between RS and AS. The service which is trusted to evaluate authorization, gets passed something that describes the request. AS may support ACP, WAC etc. All you need between AS and RS is that it can return set of access modes to the RS.
* ...: In OAuth access tokens are opaque,
* LD: I like that idea of having access modes as common interface
* JB: I agree with that too.
* EP: Access tokens are defined as opaque to the client only.
* ...: Also the AS might need to know a bit about the data to evaluate a request. For example for inherited access.
* JB: Could it be if you used some access control language, that either at the AS or another level.??? you could use a Data Grant or Access Grant and transform that into a ticket. You could model that using ACP. If the AS is using ACP to process and turn something into modes... Laurens says he goes straight from Data Grants to modes. But in that case, you would need something to calculate that relation.
* Matthieu: I think that ultimatelly the problem is what is the authoritative source for authorization. You wnat to be able to enforce set of contitions, for example by ACP. But than you open authorization to a paralel system. You could end up with a situation that conditions you try to enforce on acp level is not being enforced by other system. For example in ACP you can grant access based on Verifiable Credential. One could have VC based way of verifying credentials. On ACP side it is only require to check if VC access is enabled for the resource.
* ...: If we allow Data Grant based access to resources. We would need to say that access to given resource would be for example at most read. It would require to agree who is the ultimate source of the authorization.
* ...: There is also a case if data grants grants you an access over multiple resources.
* EP: I just have a quick comment that while talking about Access Modes added in access token, we don't want to get an access token for every request. We shouldn't require the client to get a new token for every request. I don't think the access token should be specific for each request.
* MB: Yes, as far as I understand, the ID token defined in Solid OIDC, you only claim the identity of requesting agent and issuer/client... But the authorization evaluation needs to happen on every request.
* EP: The request would include access token, so the authz server can correlate what it knows about the user.
* LD: I think it's quite hard to prevent token re-issuance. I'll get back to my implementation [on GitHub](https://github.com/laurensdeb/interoperability). Right now, you need token reissuance with every request.
* ...: When you get a 401 with a token previously got, you can add claims to your token and get new tokens with lesser overhead but it's quite complex to avoid reissuance. You get a ticket with the access modes requested. The access tokens pass information between AS and RS and also give to the token a JTI (token id). You could speed up the work of the UMA AS.
* EP: There is an incoming request and then you use a backchannel.
* LD: Indeed you could do that, but the main issue you have right now is that the CSS has to evaluate which access modes are granted over a specific resource. Which makes token re-issuance a necessity. Unless you defined an opaque token with a token introspection endpoint.
* EP: That's my kind of point. I think the token should be issued based on the claims pushed. With requests being made, the RS says which modes are allowed for which resources.
* LD: You could have a session id in UMA specific to a RS and via introspection optimise how modes are granted. When using UMA, you should ideally not have to trigger issuance for every request. But I'm still unsure about how to implement it.
* EP: With UMA, different resources could be protected by different AS. I think with UMA, you could in theory in 401 for different resource return differen AS usign `as_uri`
* LD: We want the AS to perform authorization. And it's not specified anywhere.
* MB: Both WAC and ACP have a very resource centric approach, so you evaluate access based on which resource you try to access rather than which resource a user has access to.
* JB:
* LD: The hardest part with respecting the UMA spec is it doesn't really specify what happens when you get outside of the boundary of your token (token upgrade), it only says get a 403 (not a www header with an UMA ticket). That's mainly why every request comes with its own flow. Otherwise, there is no way of figuring out what the limits of your ticket really are. I think there is security implications for the choice of a 403 rather than 401 in UMA.
* MB: It's complicated.
* LD: I'm trying to get UMA modules into CSS.
* EP: I don't think we were aiming for full UMA compliance. We mostly wanted the claim pushing part. From RS we pretty much want the AS and IRI. I don't think we should expect that RS is fully UMA compliant.
* MB: In terms of what we are trying to achieve here. We shouldn't tightly couple ACP or WAC or Data Grants to UMA. We can agree that it's good to have access modes interface that needs to be standard across all authorization systems. Access modes entail operations.
* LD: If it's of interest, I could give a brief demo of what I've implemented in the CSS at the beginning of the next panel. I think there's a bit of a tension to decide what's the responsibility of the AS and how that relates to for example authorization headers passed along via the RS.
* MB: I'd like to see the demo.
* LD: It will be similar to what I presented during interop impl call.