Authentication Panel 2020-05-11

# Authentication Panel 2020-05-11 ## Present * @jaxoncreed * @justinwb * @ewingson * @elf-pavlik * Barath Raghavan * @dmitrizagidulin * davi * Oz Olivo ## Agenda ### Editorial Check-in - Justin: I'm one of the editors on the Solid Spec. We're trying to coordinate the realization of solid/specification which is the normative version of the Solid Spec that goes through peer review. I've been helping other editors. We're looking at the different sections that we need for the next rev of the specification to be complete. Obviously authentication is a big piece of that, but we're starting to make good progress. When we established panels they were one of the key resources for getting contributions and proposals into the specification. So, obviously we have a real need to get authentication written and done. In the panel repo, I see we have some work that Dmitri did a lot of, but that doesn't seem to have much movement in the last couple of months, but in general what I want to understand from an editorial standpoint is how is the panel helping to realize the completion of the format. And from an editorial standpoint. Is the panel focused on getting the authentication spec moved through. Is this the authentication or the authorization panel. The bigger one is how are the efforts coming together to get a candidate proposal - Jackson: We have place for authentication and authorization, but we have just one meeting. We've been focusing recently on authorization stuff. In terms of authentication we came to relative agreement in how it should work (DPoP proposal). Dmitri started normative spec, besides that Inrupt hired an expert in OIDC spec to work on normative spec. - Justin: If you have one meeting a week, how do you choose which do you spend time on? From spec stand point they both need to be there. I think a symptom would have been that one gets the focus on each week. Can we structure and focus that? - Pavlik: I'd like to comment on the Authentication Authorization separation. In one of the approaches we've been exploring in this panel. What we've been calling user-focused constraints. We have the possibility where the client presents a capability to the resource server. It's still not set, but it's an option. You can find that it presents an identity credential or a capability credential. With this approach is combines authentication and authorization. In that case we cannot fully separate it. Both pieces of information. I would suggest we should not separate the concepts. - Justin: We've talked about this a bit. I don't think it precludes the need to have a well-established specification. At least from my perspective it doesn't feel like that's a blocker to continue on how webid oidc works. - Jackson: We've come to relative conclusion on how the spec should look like. New spec writer hired by Inrupt works on normative document. - Justin: Dmitri where do you see blockers in the area of extension? - Dmitri: Mostly format of the token, wheater we combine client constraining credential with identity token. Also where user focused client restrictions get stored, if client presents them, do they stay in ACLs etc. - Justin: There isn't case where those are mutually exclusive, we could have them mixed or upgrade/evolution path. For example today RS determines those constrains in ACLs, over time we could evolve IdPs to extend what they include in the token. We could even document it in non-normative parts to make it clear. Spec could benefit from evolutionary trajectory with what we can't perform today but it can get added over time. - Pavlik: I think the next adjenda point will touch on that. And once we decide on the flows for how redirects are happening, and the front channel and backchannel is happening. I think we need to think a lot on how those flows are happening. And we want to know how the flow is intended. We would want the user to have one consent screen that redirects and it's not going too far from the common Oauth So I think we should consider if the flows would have to change. - Jackson: We've spend last 30 min on meta topics. While inrupt spec writer focuses on normative spec, we take time here to consider user focused client constraints and other topics that need to eventually be addressed. - Justin: Yeah you should inline the places in the spec with a link to the github issue that talks about where there should be modifications. ### Zoom termination - Jackson: Inrupt have caneled Zoom subscription so we only have 40 min, we need to jump ship... ### [Handle User-Focused Client Constraining Access Control via the ACL](https://github.com/solid/authorization-and-access-control-panel/issues/68) - Jackson: This proposal is based on conversation I had with Oz. UFCCAC gives users power to constrain what applications can access. Instead of saying that RC can make things public to everyone, RC can allow everyone to modify client constrains part of ACL. - ...: Let me walk you through the issue... - Justin: I'm wondering what problem it aims to solve. As I understand it effectively says that besides `acl:Control` we add another mode which only allows to manage authorized clients. - Jackson: Yes, we don't want give users `acl:Control` just for them to modify just the authorized clients part. They would not be able to modify which users have access to the resource. It would also enable audit trail for that resource. If you have `acl:Clients` you could read that auxiliary resource. - Justin: Who would get this mode? - Jackson: RC decides who gets that access mode, if they want to give everyone that access mode they can give it to `acl:AuthenticatedAgent` rule. - Pavlik: I posted a comment and it doesn't seem to clearly address where a user wants to give global authorization to the client. It seems like an authorization agent would need to maintain an index of all the ACLs and I don't see clearly on how this would work. - Jackson: I noted in possible drawbacks that it offloads a lot of complexity to Authorization Agent. So yes it may need to mantain index of client constraining ACLs and modify them. Still it allows to do things within already existing ACL system. - Dmitri: I think there are better places for the client restriction ACL statements to live. Like, either in the app user's application registry, or in a credential the app is carrying [from chat]. - Jackson: If we have this information in the credential client is carrying or in apps registry it adds new construct to existing solid access control system. - Dmitri: I think it also creates new access control system. It adds new auxiliary resource and layer of indirectin. I think for few enterprise use cases we modify existing system in this way. - Jackson: I agree that is not exactly the same ACL system. One can argue that having addition to existing system is easier than having a new system entirely. - Oz: Callin it ACL is misleading for number of reasons. In traditional way I think of ACL - I own this resource and this is list of users/clients which can access it. When you want to give other users power to decide which clients they want to use, calling it access control seems misleading. It makes it public to any client in the end. - Jackson: What would you propose to name it? - Oz: I see it more as preferences. If I give Jackson to my pictures, in his pod he could specify which apps have access to that resource. In that moment I would not call it access control since I gave access to any client. - Jackson: `acl:Clients` delegates only part of access control to others. - Oz: This whole concept of user setting access control on resources they don't own (control). I would not consider it as something having to do with authorization. - Justin: There's some basic mechanics that I want to understand where they're established and acknowledged that they exist. And before you can do client control you have to know what the clients are. And they have to be presented to the resource server. And that determination of what it wants to do would be through an ACL. I'm aware of a proposal that Michael Thornburg proposal submitted where he suggested `acl:app`. In effect, that connects the dots for me that you need a claim that includes not only who is the agent and what app are they using. Then you need something that says. - Jackson: In the panel consensus seems around using DPoP. - Justin: Ultimitely because we're talking about using it at all we need a way to get it. It's presented as another claim in the token. The IDP is able to do redirect based authorization of the app id, and you can only depend on it in certain cases. It would seem that we need to make sure that there is well documented complete agreement on how that claim gets into the token. And that would be part of - Justin: Have anyone revied in depth @zenomt's `acl:app` proposal and how it could work as possible path spec could evolve into. - Jackson: General networking flow for how identities are embedded in the token. https://github.com/solid/authorization-and-access-control-panel/blob/fcf2d422af477fe43bc4d388bd15eaa315d4026c/Proposals/TrustedAppsReplacement.md#general-networking-flow - Pavlik: I think when we talk about clients I think there's a whole broad specturm of apps. I know there's server side solid clients vs mobile apps. I would be interested in scenarios where people deploy their application. In that case there is no one client identity that is deployed accross multiple users. In that case the user would need to take responsiblity for that app identity and managing ACLs. And I think we could trust the user, in that case it may be enough just to limit the app identity to the proof of possession. What's actually the app identity could be the public key on the client.