W3C Solid Community Group: Authorization Panel

# W3C Solid Community Group: Authorization Panel * Date: 2021-10-13T14:00:00Z * Call: https://meet.jit.si/solid-authorization * Chat: https://gitter.im/solid/authorization-panel * Repository: https://github.com/solid/authorization-panel ## Present * [Sarven Capadisli](https://csarven.ca/#i) * elf Pavlik * Eric P * Barath * Aaron Coburn * Justin B * Kjetil K * Henry S * Matthieu --- ## 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. * Join queue 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 * Sarven * Henry (partly) ### Introductions * name: text * --- ## Topics ### Previous week actions * Matthieu to write down example of CreatorAgent. DONE. See: https://github.com/solid/authorization-panel/issues/262#issuecomment-939881814 * Matthieu to talk to Ruben and Joachim to understand where on the roadmap this can go and try to fit. Also where to fit readying and releasing the existing TypeScript implementation. DONE: We're aiming to integrate ASAP when time/availability allows. Hopefully around December we will have something. * Elf to write down approach where only storage owner writes to ACRs and delegation handles others, sharing their access. * Elf to open a discussion on UMA. See how to coordinate the overlap between authn and authz. * Matthieu to write inheritance for ACRs of members of a container in the [evaluations folder](https://github.com/solid/authorization-panel/tree/main/proposals/evaluation). -> Moved to next week ACTIONS ### ENTER TOPIC HERE URL: https://github.com/solid/authorization-panel/issues/269 * name: Process Point of Order in meeting 2021-09-29 consists of 2 sub issues: 1. Direct merging of minutes to `main` was not agreed to. Can we either a. reverting to previous agreed to practice b. improve that with 3 step process as per [discussion 268](https://github.com/solid/authorization-panel/discussions/268) and as was discussed [last week](https://github.com/solid/authorization-panel/blob/main/meetings/2021-10-06.md). 2. the ACP merge discussion that did not happen on 2021-09-29 * what is the status of ACP? * What is the process for making changes to ACP? * How does that integrate with WAC? * How do we come to a consensus? * Would it not be better to have an ACP repo where people can make their unilateral decisions? (otherwise) 3. Two issues to make a point on ACP and WAC: + Scalability of ACP https://github.com/solid/authorization-panel/issues/206 + 2n+1 WAC https://github.com/solid/web-access-control-spec/issues/99 ### Initial UMA discussion (10min) [Discussion#271](https://github.com/solid/authorization-panel/discussions/271) --- ### Matthieu to write inheritance for ACRs of members of a container in the [evaluations folder](https://github.com/solid/authorization-panel/tree/main/proposals/evaluation). * Elf: will talk about his issues in the UMA section * M: Answered CreatorAgent * M: I didn't have time for inheritance.. will take it up next week. * M : ACP implementaiton in CSS.. just finding time to set aside. hope to find time befor eend of year. doubt it will be before December. will try to before that. * eP: ### Creator agent https://github.com/solid/authorization-panel/issues/262 * elf: not seeing issue on 262. noting that it could be fairly confusing same predicate using in two different ways.. so perhaps we can use a single. a different predicate not matching ??? * M: The type of agent is to match against any agent to match agent class. it is to match basde on webid. the idea is that, each type of matcher can potentially be combined with other restrictions. to allow owner agent.. also to identify speicif issuer. specific agent with combined with.. so i tis the same typeo f drestriction as webid. we could try something else, but not sure if another predicate is required. * HS: thanks for that answer. will look at it next week. a lot of coding to do so didn't have time to look at your answer. you've put it on Monday.. time goes quickly. ### ACP merge * eP: timebox for 10 minutes. Henry you've proposed.. would you like to explain. what's missing.. or what actions can we take from this discussion? * HS: Can we change the order.. the ones that I've presented? * eP: one is process related.. one is delivery related. would like to prioritise. * HS: Reason why I'm bringing up the PR when Tim was present was because the process was broken in 2021-10-12 meeting. If we don't follow the process, we won't come to a consensus. this is so that we don't reopen issues. i don't know if you noticed but DIDs just didn't go through the W3C WG. 3 yeras working on it.. and suddenly someone says it is not going through. so when we are making compromises.. to understand how we integrate what exists with WAC. then we are not doing anything right. we need to have a process and the process has been broken.. and the reason for the process being broken.. and the minute have been pushed in. * eP: i understand that the merging was a mistake. i was completely clear that we were merging the PR.. i dont' wan tto tlak about other people but that's definitely not my case. if you were confused about what you were voting on but.. * JB: i think we need to avoid conflating a few things together.. not that it is intentional. how we deal with meeting moinutes.. how we deal with drafts.. frankly, i don't see the relevance of tim being ther eor not. as for ACP, we have reviewed that PR.. over several months, asked if we could get that on the agenda. and merge and continue to iterate.. and there were several minutes of discussion on this. it feels odd that we weren't aware of PR. there were a couple of +1s. two minutes later, the ACP draft was mentioned to be published at this URL. it seemed pretty obvious what we were talking about. there was good feelings together.. but i don't htink it is constructive to lump these things together. ill just point out that this is in proposal folder. acp as a proposal spec.. what that vote didn't say was the next thing that it is getting from the spec tomrrow. all that said was that this was a good draft spec. it is hard to disagree with that.. but maybe people want to. * AC: most of what i said justin already said. this is just a draft proposal. i dont attend meetings but follow the minutes. from the outside, it seemed like the acp is a proposal. as a proposal it is a lower bar as for how far it can move forward it was completely clear to me it was goin got merge and as a proposal. * HS: It wasn't clear to me because the order of the meeting was changed. the meeting tpyically starts with commiting the minutes but instead the PR was pushed. so the order was a different business. and the minutes pushed 60 minutes after the call. this is confusing. the minutes from the previous call was pushed to the main. something that didn't happen before. and for last week (going to the other issue): i/everyone understands that acp is a proposal. in the next part.. we'll discuss, we can look in more detail on trying to come to consensus. i dont think there is an action to be had here. ### Direct merging of minutes to `main` * eP: let's timebox to 5 minutes as a process point. we can develop the oconversation in github. * HS: we used to have a practice here. it is a simple one. we have a meeting, we made a PR, that pr gets improved, next week we vote and approve. last week we discussed this.. explained the problem. my proposal was to fix that by having a draft-minutes branch for all - not to have a deleted branch but to have a constant branch. that solves the problemt that Sarven brought up. can we vote on reverting to previous process or another having a draft minutes and committing to that. as ive explained in discussion 268. * HS: >Push minutes to the draft-minutes branch of relevant repository immediately after the call. >Improvements to the minutes MUST be PRs (can be done by editing the content on github) >After approval of minutes in next neeting, press github "Merge Pull Request" button. * HS: +1 * eP: 0 * AC: If we require a specific branch name.. then the only people can scribe are the ones that have access to the repo/branch. * HS: good issue. people could create a PR against that branch. * eP: better to discuss in the issue. for today. is there a counter * SC: There is a paralle PR 319 worth considering. * HS: +1 (to my proposal) * eP: Aaron has counter proposal. * AC: COUNTER PROPOSAL: use the process described at https://github.com/solid/specification/pull/319 * eP: 0 * HS: your proposal is 50 pages long.. it is unclear.. and two days later.. after votes.. the question is how many people. * eP: I propose the scribe does it today as they see fit. Just for today's. ### Inefficiency of ACP and WAC https://github.com/solid/authorization-panel/issues/206 https://github.com/solid/web-access-control-spec/issues/99 * HS: took awhile to understand that.. and this 2n+1 in WAC. both of these are efficiency problems. a simple way to understand this.. essentially every resource has an ACL. double the amount of resources. instead of having one default access control rule. just in terms of calls, it is too much. trying to find the default rule.. it has to go down and find the rule. this is not magic.. we're doing engineering. for these to come together. acp to not require one acr for every resource but to go like wac where it has default resources. but wac needs to have a link to the default one like acp, like ACR. and that ACR might not exist. that would be the diff with ACP. so you have default resources like ??? you have base. ??? everythign is public perhaps. every resources could potentially have an ACR. this is a compromise solution where we can stitch the two protocols together and come to an agreement. * M: It is unclear to me this is an efficiency problem. If we are talking about cache. ACP has 1:1 resources/ACR and only the first level is not reusable. I don't see how to make the cache more efficient since ACP defacto reduces redundancies. Not convinced that something can't be optimised ahead of time.. * AC: there are two kinds of interactions with acp/wac: there is update and read. the informcement and chang ein access contorl. what wac does is, makes writes to acl easy and quick. read is more complicated as henry pointed out. so wac puts simplicity on writes and complexity on reads. acp is the other way around. when someone is building a wac system they'll find, (ive build several wac ystesms) so need to build cache systems ay way.. on an engineering side.. these request happen so fastr.. you'll need to buid a cache any way. * HS: Aaron described it well but could do better e.g. wac can do better on .. acp has cache .. unnece.. eg go to root and then for every reas.. ??? **HENRY PLEASE FILL IN THESE DETAILS** There is no rason why WAC can't do tat eg. potin to root, another point to potential access control rule. if yo ufind this compromise, an elegant comproimse for both sides. so everbody should have an advantage to improve both protocols simultaneously. perhaps to create an issue to make it clear. * KK: Agree with Aaron. WAC needs to be implemented with cache any way.. also agree with your assessment on 2n+1 but tha thas a relatively trivial solutoin to point at the effective resource. trying to look at this more fundmanetal analyusi sangle: you hav eth URI space.. worst case / scalability . solid takes off exponentially. so, have to limit that exp time increase by something.. and there is moorse law and possibly bring it down to something that's not exp. there are thins like spinning disks.. which has linear improvement. the problem is.. efficient on read but on write it is terrible because on every writ eit has to propogate to children that goes ??? 2n? need to block all accesses, don't know =? progotation happen. i ack that im not particularly good at htis. ther emay be things to elevate this. * AC: a lot can be addressed through implementation detail. re henry's point on precomputed cache.. there're all kinds of caches. dont need to realise all in acr cache. don't need to block reads. those imp details are allowable within the spec. * MB: ACP makes everything reusable all the time no matter if working on hierarchy or not. * HS: it is not sometihng you can optimise. ti is a protocol. it can be optimised by adding a new link. Aaron raised this issue.. to have a second link. we can have an efficient system. add a new access control link. ACP should be something evolving.. towards something more efficient. My action can be.. Aaron, Matthieu, myself, and Sarven can look into this. * HS: we had too many talks on UMA for awhile.. elf Pavlik, you're telling us that we are taking up time. * KK: I'm not confident that the implementation detail will take care of this problem. It seems more of a fundamental problem with data representaiton and the complexity that arises from that. There are limits to in terms of optimisations. I underrstand that i"m not the right person.. but worried that we are implementing something that can't scale.. if Solid goes exponential. i would like to be confident abotu that. * eP: can we follow in issues? for acp and for wac * AC: It is great to talk about this in theory but when we are talking about these details from direct implementation experience.. jus to say that we need the imp exp. ### UMA URL: https://github.com/solid/authorization-panel/discussions/271 * SC: {eP shares screen} * eP: There is Authorization Server (AS) is connected to Resource Server (RS). The end user will login w/ clien to AS. the AS will talk to the client to make a request to the RS.... see URL for details. * AC: these flows get complicated as UCs extended. to separate the AS from RS.. makes the impl of RS much easier. isolate code. being able to separate is really nice. * JB: Interop doesn't necessarily require.. all these infra is in place.. but these are patterns where protocols have solved them.. have flows where ??? for average users over complex data.