W3C Solid Community Group: Authorization Panel

# W3C Solid Community Group: Authorization Panel * Date: 2021-09-22T14: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 * Kjetil * Barath * Henry * 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. * 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. ### Scribe Selection * Pavlik * Sarven ### Introductions * name: text * Kjetil: My name is pronounced Kghjetil. been in sw community 1998. studied theoratical physics. phd in sparql on the open decentralised web. nowadays im helping writing specs.. and also test suite.. around specs to verify conformance.. --- ## Topics ### Ideas for access modes and corresponding operations in the Protocol URL: https://github.com/solid/authorization-panel/issues/253 * Kjetil: I posted some ideas around operations we should be specifying in the protocol spec. * ...: Access modes are generally defined in various access control systems * ...: Protocol should define operations, based on what happens on HTTP layer. * ...: Access control systems like WAC and ACP define the access modes. * ...: We should come up with something which we can continue in spec repo. * ...: There is a lot of legacy and thought that went into solid over the years. * ...: We are not greenfielding, we should be careful what we can bring to the spec repo. * Pavlik: ACP stays agnostic to access modes, it just helps to define which mode should be used. * Henry: We should move it into discussion so that we can use threading. * ...: I would like to bring WAC and ACP together so that we have one spec. * ...: I would like to do math of category theory, i think we have lenses and monoids... * ...: I've done some work in terms of modeling it with lenses. * Sarven: To get back on Kjetil, he should wrap up the context and we can move on with details * ...: I understand that we are interested in operations, and how they can be realized with access modes. The notion of create can be written in many different ways. * Pavlik: ... * Sarven: The use case presented by Justin, it sounds like centralized scenario. which is fine but normally we talk about decentralised annotations and notifications. * ...: This use case relies on notion of creator. This seems to be hidden. * ...: If we track the creator we shouldn't have problem to handle that use case. * ...: I think we should focus on operations, is tracking the creator is the objective? * Kjetil: I have problem with use case defining specific way on how things get stored * ...: If you don't do it you can derive it from other requirements * Pavlik: okay to have 'centralised' case .. similar to gh forks. * Henry: I think we should deal with creator. We could use OWL class to restrict the agent * ...: You want to say that agent who created the resource is the same as the one accessing it. * ...: You can't have collection of creators, everyone is creator of something. * Henry: should i open new issue * Sarven: I don't think this problem should be solved on authz level * ...: We almost had consensus on where we store server-managed data, creator could be stored there. * Henry: I see it problem for a default. How do you say it in generic way. * Pavlik: Creator could captured using different property when we specify access modes. * Henry: How do you write it that every resource can be deleted by a creator. I would want to do it with OWL. * Sarven: If we remove creator from the use case posted by Justin it falls apart. * Kjetil: The relation between AuthZ work in various group we need to specify. As I understand in interop.. is that right? * Pavlik: In inteorp panel we focus on. Roles for resources. Columns for users. acp/wac focus on projecting access matrix on resources, in interop we project access matrix on users project on users. which resources users can access. [access matrix image](https://github.com/solid/authorization-panel/discussions/203#discussioncomment-610302) * Matthieu: In ACP, the notion of creator can be used to define matchers. There is no default involving the creator. From ACP's perspective, it's a solid protocol thing (or in other words, ACP expects the creator of a resource to be fed to it as input in order to match it if it is used). * ...: On the other hand, ACP uses the notion of owner for default permissions (the owner of a resource always can edit its access control) (note that ACP also expects a server to be fed who are the owners of a resource being accessed, it's also a Solid protocol thing). * ...: Obviously, it would be possible to define rules involving a creator and apply them by default (using the inheritance mechanism). * ...: See also the ACP agent matcher described in the spec https://htmlpreview.github.io/?https://github.com/solid/authorization-panel/blob/initial-acp-spec/proposals/acp-specification/index.html#agent-matcher * Henry: how to use wac ontology to authorize. wac can be use to say this agent/app read these resources. eg. https://github.com/solid/authorization-panel/discussions/258 * Henry: For me the discussion is about how you can use WAC to limit authentication of apps. * ...: I see that we produce 3 different specs, this may be end of solid. * Barath: ultimately systems work well when they are pluralistic. we need to produce a single answer.. we can't forsee future UCs.. talking about diverse world might be using this thing.. what i'd like to see is.. okay ot see different specs.. as long as there is loose interop. and people can migrate... web works through coexistence.. * Pavlik: translating data grants into ACP rules. data grants give a way for auth agents ot auth apps.. owned by different users. * Kjetil: purpose of the issue i opoenbed to establish baseline interop. by putting in the protocol spec's various oeprations we see coming out of this.. on the greater issue: there is more of a balancing act. there is diverging .. likely to hurt interop. on the other hand, so restrictive people can't be creative. that's also bad. * Sarven: +1 protocol spec as baseline. * Sarven: why isn't the data grants being translated to WAC? * Pavlik: EricP were looking into translating to WAC. wac-ucr had list of limitation found in that process. * Sarven: WAC is called basic access control ontology, it should be able to do a lot of stuff fro you. There is long list of things the can also be done which it doesn't do - but it can re extensions.. or updating the spec. * ...: This didn't stop ACP to be considered, unless there are fundamental issues, we can't do greenfielding on everything. * ...: We have less than 10 people in those meetings and we come up with multiple solutions. * ...: This panel could be it's own working group. * Henry: If you look at HTML it creates spiral of improvements. We should build by growing WAC step by step. If you freeze WAC you get split efforts. * ...: I see reasoning of moving to ACP as wrong. Have shown that WAC can do what ACP is claiming.. but we need movement on both sides.. eg. removing control will open up some options. access control for public spaces.. we want our UCs to be listened to and improve things.. the role of these groups to reach ocnsensus .. try to find out places.. and can we improve things. * Kjetil: Can we agree that Read and Write can be top level classes. We could reach consensus already. * Sarven: yes. they're class of operations. is there no consensus on that? * Kjetil: Justin mentioned Write could be deprecated.. but that's not the case for a lot of social groups. Idea of having RW as upper classes .. can we have consensus on that. * Henry: yes.. that works well with lenses. mind boggling to think that this concept has so much .. * Sarven: yes. * Pavlik: WAC's RW or ? * Henry: generic. * Sarven: RW *operations* * Henry: observation -> transformation * .. Control is essential to access control. what they say is true. home owner says don't go into house. speech act. making true rather than.. * Sarven: I don't think there are big differences between ACL and ACP. It's not like capability vs ACL. * Pavlik: * Kjetil: we're also talking about modify, create, delete.. and so on. how many operations will we bring in to the specification. also how the http protocol sees them. there are lots of things there. * Pavlik: I find it confusing to call both operation and access mode 'Read', 'Write'. * Henry: * Sarven: ... * Sarven: We can introduce new access model to Delete, it seems to just substitute variable name but end result seems the same. * Henry: I think Justin should try to write how this example would work with WAC, and show what Delete would give us. * Sarven: too much intelectualising not enough visible implementations. * Henry: will write client libraries. * Pavlik: re Read operation on the resource.. ACL seems the nuance of e.g. Read mode. * Matthieu: wondering about UCs and think Henry is right.. Write on .. hierarc * Sarven: we have issue about error codes * ...: is reading part of creating or something different? * ...: for example when you do PUT, if it's get updated you get 201 if created 200 or 204 * ...: we should clarify it * Henry: We should organize problems and prioritize how we dive into them. * ### Remove Control [deprecate wac:Control #303](https://github.com/solid/specification/issues/303) ### Application Authorization ### Topic URL: * name: text * PROPOSAL: text * name: +1,0,-1 * ACTION: text