2020-04-20 Authentication Panel

# 2020-04-20 Authentication Panel ## Present * Jamie * Jackson * Dmitri * Elf * @ewingson ## Issues ### [reorganize use cases and requirements #66](https://github.com/solid/authorization-and-access-control-panel/pull/66) - Elf: Reorganized use cases ### Spec Update - Dmitri: Inrupt has hired a 3rd party to finish the spec. My personal bandwidth and the shipping deadlines are not mixing. I still hope to particiapte in this panel and solid.community in general. - Jackson: I can't share yet who, but we hope to introduce the person to you very soon. Dmitri was providing amazing resources. The process will stay the same. - Elf: How much is this person familiar with the app authorization part and varifiable credentials. Will we need to reiterate some things we've been discussing. Especially on the part where we capabilities. - Jackson: We mostly discussed the current spec and we want to focus on that. ### User-Focused Client Constraining Access Control - Jackson: By default everything should be 'locked down'. I would see it uncommon for the resource controller to leave it open which applications can accesst. In security, one wants to go with secure by default. For example zoom had problem with creating zoom meetings which anyone with link could join. Now by default meetings are private and require invitation. If things are secure by default people will make effort to change it if they want to share it. - ...: For example when I share socal media post only with 'my friends'. As a default I would dictate which applications people can use to access it. - Elf: If we approach it this way we could also see it in a way where by default, no other client than the storage server itself can access it, so by default the person needs to authenticate with the storage server. As soon as you choose the client, you don't make it default anymore. When the resource controller defines the client I wouldn't consider it the default most secure anyway. - Jackson: I still can make argument of having it more secure. - Elf: People would want to opt in to relax it, and those people can choose their own clients. For social media posts, I don't think that anyone would want to maintain a list. - Justin: I’m tied up for the session today but as far as client constrained access defaults, wanted to offer my perspective. Ultimately the determination of how rigid client constrained access should be is left up to the controller of that data. Certain people will be more capable of making these determinations for themselves, and others will need help or to completely defer this judgement to other agents or providers to make good choices on their behalf. Our first task is to ensure that solid supports this flexibility and freedom to choose. Our second task is to ensure we have the frameworks and modes to enable both sides of the spectrum. Consequently, the defaults will/should be contextual, based on the data, provider, or agent in use. - Jackson: We have use case where we share social media post with a public. - ...: We have a use case where I share social media post with my friends. - Dmitri: Two things could be argued. 1) Locking down which apps can access doesn't directly guarantee more security, and in fact is security theater. There is a whole class of applications (any applications that are not traditional server-side applications deployed on domains with SSL certificates) where it is _theoretically impossible_ to enforce client constraints. 2) We need to consider the social and reputational aspects of this decision (of implying that Solid supports a resource owner restricting which clients can access a resource). There are no other precedents in ecosystem where users lock down which app can access documents stored in standard format. It also places an impossible (or at very least, unreasonable) informational burden on the resource controller. With each lockdown decision I need to become expert with space of available apps and coordinate with users I share with approving those apps. - Elf: I think we can take a use case of the solid project, and if we talk about issue management where only some members can manage issues. In that case, if we have some kind of policy of trusting who is added to the solid team, we can say "we can trust them." We can feel confident that they have the correct client selected. And it can be an explicit kind of statement that it's user controlled what clients they are using. - Jackson: We have two different ways of thinking. As Dmitri said we may put to much burden on resource controller. I think we can have two ways of dealing with it 1) User based client restrictions and leaving it up to users 2) One could have automated agent which would maintain list of all the 'trusted' clients for given type of data. - Elf: Option 2 seems to be against the open world assumption to have an authority on the apps that are approved. This would require the user to point to the agent to discover that. I'm worried that it's more like a closed world approach. - Dmitri: It's coming down to both a philosophy and a technical capability thing. You can't confirm the client. - Jackson: What about approach where RS redirect to the client to verify it? - Dmitri: Redirect is not sufficient for strict enforcement of client identity. - Elf: Also I think I would propose a use case where a User uses open source clients and hosts them themselves. Even for each client source or app source, there would be a deployment per user, and I install the apps there. The source may be certified by something, but I want to have them on my origin. - Jackson: Is that challenge only come with non compliant user agent? - Dmitri: One could just use proxy and let users to rely on it to circumvent those client restrictions. - Jackson: If we trust the user we also trust that they use complient user agent. - Dmitri: I don't see it possible to trust the user but not trust application they choose to use. - Elf: When I look at the comment from Justin, we should support both. - Dmitri: I don't think not trusting an uncle or app to choose things is a valid use case. Your family is trustable - ...: We do not want Solid and Inrupt to be known for keeping the dream of DRM alive. - POINT SUMMARIZE - Use case where you trust everyone (Like panel members) - Reputional (Don't want Solid to be known for DRM) - Technical problems around enforcing app identiers - Proxies and Browser Extensions - Users deploying clients on their own domains - There is no other precendent in CS for not trusting your aunt and uncle - We could fully constrain to server side apps - Jackson: Having user constrained access complicates ecosystem in many ways. - Elf: Dmitri, could you write up these examples for one canonical example - Dmitri: Yeah, if I have the bandwidth - Jackson: Previous having non-complian browser was out of scope. In that case redirect on RS seemed sufficient for enforcting it. - Dmitri: We don't even need people to intall modified user agent, proxies and browser extensions could offer similar way around those restrictions.