# 2020-05-04 Authentication Panel

## Present

* @jaxoncreed
* @elf-pavlik
* @dmitrizagidulin
* @oolivo
* davi
* Barath Raghavan

## Agenda

### [Compelling Use Cases for user-focused CCAC](https://github.com/solid/authorization-and-access-control-panel/issues/67)
- Jackson: Should it be possible to have resources which restrict access for users but those users can restric further which application can access it on their behalf.
- Oz: Can we clarify terminology, what exacly do you mean by the user?
- Jackson: Application user.
- Pavlik: I find it useful to talk about social entities. For a user it could be a social/legal entity that you share access with. The software doesn't have its own agency, the software always acts on behalf of these entities. Because software cannot be held accountable for its actions. The software acts on behalf of the agent.
- Davi: Is there a dictionary
- Dmitri: Partially there authentication spec has concepts that get into it.
- Dmitri: I would argue that this is a confusing way to phrase it. What we're arguing about the client application filter and client application access control. User-focused can exist and DRM cannot.
- Barath: There's an orthogonal thing. There's a question of in what context can you constrain an application. The question is can you constrain it even when it's off your Pod
- Dmitri: That's not orthogonal, because it's describing DRM.
- Pavlik: Just to clarify what multiple hops mean.
- Jackson: We don't talk about preventing users from making a copy of a resource.
- Jackson: We have two ways of constraining clients. 1. by resource controller 2. by users accessing it
- Oz: Let's not start from the angle of concerns. It would be useful to get a better understanding of the use cases we envision. Generally this is something that is a fairly unique model. Others don't have this model of sharing with people and then letting those people have control over the entities that can access it. So what are the real use cases.
- Pavlik: I just thought this morning that appending Linked Data Notifications to a public inbox is a good use case. I don't think there's a way to have some kind of whitelist for that. An inbox would want to allow any application to append to the public inbox.
- Davi: Why wouldn't there be a whitelist for that? Public inbox being exploited. (spam issue)
- Dmitri: Could we put a pin on the inbox discussion? It's pretty complex and I want to understand the goals.
- Dmitri: I'd like to address Oz's question about what's the purpose here for User-Focused CCAC. And it's basically a decent protection from Phishing. Solid is one of the first systems that brings to the table this capability: I install a music player and I don't want it to access my taxes. That's why we started this authorization overhaul. It's because right now any application I use has whole access to my data space. So User-Focused app filtering is a way to partition this data space. And mostly aside from user convenience and cognative compfort. That's the main use case.
- Oz: That confused me more. So, your description doesn't match. "User Focused" is saying "I want to control what apps". What about resources you have access to that someone else controls?
- Dmitri: There's a simple clarification for this. You can only restrict that apps that you're using.
- Jackson: If user also acts as resource controller I think we have agreement that they can restric which apps they can access that data with. Our cases relate mostly to users which don't have control access to data.
- Dmitri: Whose data you accessing doesn't matter, it matters only who is using the app.
- Oz: At the resource level I think our reasons are different. I can at least get behind the idea that I as an owner of a Pod want to restrict the applications that a user can see. As a Pod owner I require the capability to restrict what applications

| | A. I control the resource | B. I do not control the resource |
|-------------------------------|-----------------------------------------------|--------------------------------------------------------------|
| 1. **I am using the application** | I can constrain the appplication through ACLs (or client credential) | ?? |
| 2. **I am not the application user** | ?? (DRM territory). App authn is challenge (for [public clients](https://oauth.net/2/client-types/)). | There is no reason for you to be involved in this situation |

- Jackson: One side can conclude, as resource controller i want users who don't have control to request from me which applications they can use.
- Oz: Let's start with 2A and if we get answer to that it will map to 1B
- Dmitri: Can we agree that 2A refers to DRM capabilities. DRM only allows access to resources by approved clients. So in 2A you're doing exactly that. Which is impossible for desktop, mobile, and in browser Javascript apps. The only one it is possible for is browser apps with a server side component.
- Jackson: I find the most compeling that it's not possible on mobile apps and we want to support native mobile apps.
- Dmitri: I see better phishing protection for 'your grandma'
- Oz: Are we saying that maintaining whitelist of applications which can access the resource is impossible to enforce?
- Dmitri: Only if someone else pilots the application, if you pilot yourself you can enforce it.
- Dmitri: We have strongly identifiable vs. weekly identifiable applications. If you pilot application you can strongly identify it, if someone else is using it we have only week identifiability.
- Oz: I hear for the first time that we have no way to authenticate application making the request.
- Pavlik: There are 3 things I think are very out a bit.
- If you put DRM in that table if we add in the top header "control the resource and which apps can access it"
- And we haven't talked about the grandma being the resource controller in scenario where we restrict aplications so she doesn't need to take that responsibility.
- And when we cannot identify an application, we cannot identify beyond what a user says. So if I'm the user I can say that I identify the application but we can't know for sure what an app is if it's someone else.
- Oz: I don't think even in 1A we can fully identify the application.
- Dmitri: In terms of Phishing it helps to look at probabilities.
- Jackson: In the end user has control over the request made.
- Dmitri: As a user do you care about restricting that music player can only access music an nothing else you as a user have access to.
- Oz: Once I've given up the firewall of I control access. Now that we're doing second order hops that's borderline public.
- Dmitri: That's the current status quo
- Pavlik: If we restrict what applications other users can use, do we want to restrict uses from getting whatever representation they get. Or just strict downloading resources. When it comes to read access it's also quite easy to work around it. If you want to prevent that. That's DRM by definition.
- Oz: The area I'd encourage us to think about is auditability. There's the perfect DRM which doesn't exist. But there the standard eveyone operates at, which I don't think we meet.
- Dmitri: I would claim that even in enterprises and government installations, there aren't any restrictions of whether you use one email client of another. There are legal ways, but no technical way.
- Davi: That's not true. An application has to have the ability to present a certificate.
- Dmitri: Not all applications are _able_ to present certificates. For public clients, there's no way for you to derive secrets, in OAuth2/OIDC. That is a known limitation.
- Jackson: If user provides this secret to application, they can provide it to any application they use.
- Dmitri: See, for example, the OAuth2 concept of "public client" https://oauth.net/2/client-types/