2020-04-27 Authentication Panel

# 2020-04-27 Authentication Panel ## Present * Jackson * elf Pavlik * Dmitri * Matthias ## Issues ### [Use case update](https://github.com/solid/authorization-and-access-control-panel/issues/67) - Jackson: I had nice long conversation with product team internaly in Inrupt. They will join panel meeting next week. It's not that use cases are more enterprise, just product manager doesn't see compelling use cases for user constraining access control for clients. - Dmitri: Isn't in question if we need *resource controller* clients constrains, not *user* client constraints? - Jackson: Even that officailly we inform the spec, it's good to have buy in from product team in Inrupt. Product managers gather requirements and for now they gathered mostly requirements from companies. - ...: Inrupt PM doesn't find open for anyone use case convincing. He uses example of Zoom meetings open to everyone. I give example of community forum where admin trusts all the users to choose their clients. This eliminates friction. PM questioned if it really eliminates firction if admin can just approve clietns. - Pavlik: I mentioned at the end of the last panel that I want to prototype something called "Peer relationship management." It's a combination of customer relationship management (https://hackmd.io/Yb8qBdIoQROeF32TCa0zTg?view). In this example I'm using a worker that could possibly work for multiple cooperatives. And it could happen in scenarios where there is a small network of cooperatives. In this case, it's not a completely open ecosystem, but a person should be able to use their client to do activities for multiple cooperatives. They don't need to change it for each cooperative. ( PRM use case https://hackmd.io/Yb8qBdIoQROeF32TCa0zTg?view ) - Dmitri: I think I'm missing something basic. Why are we switching the topic to coming up with use cases for user-centric. The point is that the thing that Oz is asking for is not technically possible and highly morally questionable. - Jackson: For me it starts out philosophicaly with a focus on resource controller. [...] I try to explain that it's not about transferring ownerhsip to the resource. Inrupt PM was suggesting that it's like making resource public. - Dmitri: I see that what they ask for is DRM, and after industries spendng milions on trying to enforce it, it turned out impossible in practice. DRM means - protect the resource that only approved clients can access it. I see it the same as resource controlled client constraints. - Jackson: I didn't emphasise enough the technical challanges with enforcing resource controlled constraints. - Pavlik: I want to clarify the zoom case. The way I understand, zoom only allows the official zoom clients. I don't see exactly where the zoom use case is related to client constraints. It's like constraining access to users rather than clients. Could you clarify. - Jackson: I think zoom case wasn't direct analogy, it just served as example to have restrictive policy first. - [@zenomt on gitter](https://gitter.im/solid/app-authorization-panel?at=5ea0f59a1eb8bd3978ebf172) i thought that one of the fundamental principles of Solid was that the user should be able to use whatever app she wants to access whatever data. it's not reasonable for a resource controller/owner to have to maintain a whitelist of all the different apps all the different consuming users want to use. i thought we-all had decided that a long time ago. however, the minutes from monday's meeting sound like people had gone back to the controller/owner explicitly specifying what apps users can use. that or "user uses a proxy". i'm very -1 on both of those antipatterns. - Dmitri: Haven't we been talking about DRM for decades. - Pavlik: I think we should be able to agree on control being delgated to users. I think there are cases that can be made for both, and if someone were to make cases for resource controllers that's fine, but they're completely coupled together, but in some cases we want to leave it up to the users and support that. - Matthias: Is this conversation still about defaults - Elf: I think that we should clarify what we mean by default. I don't want to specify the different implementations. When we talk about default, we're talking about what happens when there is no rule of what to do. I'm quite open to that. Then there's a decision around the explicit rules that can go beyond the default. - Jackson: We can have explicit defaults emerged in ecosystem to have things more open. - Jackson: We have DRM use case, I see public forum a good use case. - Dmitri: I don't think we need use cases to back users constraining clients - ...: That forum use case sounds like - do I want only chrome users to access it. - Pavlik: I would like to be able to independently say that there are use cases, but we don't need to resolve that before we agree to accepting requirements. - Jackson: We had conversation about auditing, as in if someone used `shadyapp.example` resource controller may want to know about user using it. (Create a logging issue) ### Interop Panel Update - Pavlik: I will make requests to the interop panel and move use cases there. We agreed to that during lat week interop panel meeting. ### [Peer Relationship Management](https://hackmd.io/Yb8qBdIoQROeF32TCa0zTg?view) - Pavlik: If a doctor and a patient have a chat, is it hosted on the doctor's storage or the patients? In that case it works more like SMS where each party has it's own copy. It makes it less dependent to have the histroy. Check out for CfA http://conversationsforaction.com/cfa-playground - Dmitri: I see some interesting aspects of Data Retention which we didn't get into. - Jackson: I recall use case where chat app bundled with solid browser. Where data retention woudl be on the pod, app would create new resource every day which caused that conversation order would have to send a message to open converstation for that day.