# 2020-05-18 Authentication Panel

## Present

* @jaxoncreed
* @justinwb
* Adam Migus
* Barath
* @elf-pavlik
* Davi Ottenheim...
* Osmar Olivo
* @dmitrizagidulin

## Agenda

### [Improving the effectiveness of panels #202](https://github.com/solid/process/issues/202)
- Justin: We're at a point where we can take some learnings from the spec process. And the question is how do we get more quality submissions from the spec coming into expert groups. We want to illicit response from people who are participating in panels and for people to provide feedback for update proposals to the process. We want people to chime in.

### Adam Introduction
- Jackson: Inrupt has hired and OIDC expert to help us out with writing normative spec.
- Adam: I'm coming into this new. I've been doing identity and access management for a decade and have been connected with Justin Richer. So, I spoke to emmet and everybody. So, I'm coming to this a little new. Back in 2018 I participated in the VC working group with the w3c. So I've been tracking and following that group for a while, but haven't been active lately. So, I'm in a pretty good position to help you guys and I also have some help. We have "Ricky" he's my tech writer. So we see what he's writing. I'm sorry if this is disruptive to where everybody is and we want to start anew on the normative spec. The best way for us to move forward is to create a new draft document in 4 weeks. Then we'll release it and put it into git for panel review.
- Pavlik: Hi welcome. I just wanted to ask you if you mostly focus on the oidc part, or if you've looked at the client authorizations. We've been discussing if the client would pass on app authorization.
- Adam: As everyone knows Authentication and Authorization goes hand in hand. So I'm involved in the authentication specification by mandate. Where we draw the line in the spec is TBD but I'm happy to participate in the discussion of authorization.
- Dmitri: Welcome Adam. My question is can you give us a preview on the different directions you're thinking of taking the spec in from the current documents
- Adam: I would say for starters, it's clear there's a lot of converation around a bunch of different directions people want to go and there's no shortage of ideas on how to make things extensible and robust. And we're going to focus on the musts and the musts only and then we'll add the "mays." We need to find the critical path of the protocols. .
- Dmitri: What are the musts in your mind so far.
- Adam: Too soon to say. For example I was looking at DPoP and it looks like it's a May so far, and I was thinking it should be a Must.
- Justin: Welcom Adam. From a editorial standpoint, getting a full spec pushed through authentication is a key piece of it. I'd be interested in how we evolve the key parts of the spec and try to review them. My concern is if we wait for a grand reveal for a while that can push things out, so if there's a way to work through specific things in sequence rather than waiting, we can get some efficiencies there, that would be beneficial.
- Adam: I get that. I'm stuck with how I work and all I can say is we definitely understand and want to provide something concrete as soon as possible. So, we'll offer whatever we can. We want to get to the point where we arrive at a spec as soon as possible. We're going to just try and be as organized as possible. So hopefully it will be time efficient.

### Michael Thornburg's Thoughts on DPoP
- [Michael](https://gitter.im/solid/authentication-panel?at=5ebc29672cf0da0ad9fe32b4): in the minutes from 2020-05-11, i see that @jaxoncreed said "In the panel consensus seems around using DPoP." however, "consensus" is the wrong word, because i have technical concerns and objections that i don't think are resolved. at best it could be "rough consensus" (at least as that term is understood in the IETF), so long as the rest of the panel agrees that my concerns and objections are either non-issues or that they can be lived with. i believe that's the position of at least some participants. there can be "rough consensus" without unanimity, but "consensus" implies the endorsement (or at least absence of objection) of everyone in the panel. the latter is not the case. that might seem like a trivial distinction, but it's especially important to those with objections. :) [Technical Objections and Concerns with Proposed DPoP + VC Scheme #47](https://github.com/solid/authentication-panel/issues/47)
- Davi: We should define *consensus*, IMO it doesn't requre 100% agreement.
- Adam: In the past, my own experience given the determination is significant enough we will fall back to the voting process.
- Pavlik: He's concerned about the nuance between concensus and rough concensus. Maybe we should address it better on github so that he sees we've addressed ite better than we've done here.
- Jackson: going over [Technical Objections and Concerns with Proposed DPoP + VC Scheme #47](https://github.com/solid/authentication-panel/issues/47)
- Dmitri: DPoP spec declairs `jti` as optional. As I understand Inrupt's security advisary, we should require `jti` to prevent reply attacks.
- Jackson: `jti` is one method, restricting it to one place prevents replying it to other place.
- Adam: Do you refer to channel bound?
- Jackson: Yes
- Justin: 2 operational things. In this issue the responses you're providing aren't being written in the issue. In the proposal spec text, the issue should be cited in line. Just in the draft, but having inline callouts helps a lot in review and bringing stuff into context.
- Adam: I think that would make a lot of sense, and I would add in the past what has happened is DPoP could be profiled in the spec. We could go the route of making it a "Shall." We either need to explain it in the non normative spec or something else.

ACTION: Jackson to respond to Thornburgs issue with Aaron's feedback

### Client Constraining Access Control
- Jackson: Last week we discussed issue [Handle User-Focused Client Constraining Access Control via the ACL #68](https://github.com/solid/authorization-and-access-control-panel/issues/68)
- ...: there were some confusion around Authorization Agent. It is entity which user trusts to manage all the access control rules on their pod.
- Pavlik: My concerns are mostly around synchronizing authorizations. If a user changed their rules in the authorization agent, the agent would need to keep track of every authorization rule that a user has and update them all. This could very difficult.
- Jackson: Justin proposed this term in one of interop panel documents. I proposed this approach to simplify some aspects of access control.
- Pavlik: [Distinct aspects of Trusted App replacements #63](https://github.com/solid/authorization-and-access-control-panel/issues/63) my understanding is that the client constraints modle would not be affected. I think that creating client authorization would be one part. I think we could use this to see which things it affects which means that we can keep working on the model and I think these distinct aspects can see what things are affector or not by this proposal.
- Jackson: In both those proposals client presents capabilities at request time. In my proposal we offload those responsibilities to Authorization Agent.
- Pavlik: I think that one of the difficulties is that the Authorization Agent comes from a document from the interop panel. We also didn't discuss how the flows would work. That document I recall has just one consent screen, but I think we would need some kind of sequence diagrams before we can discuss an authorization agent. So, for me it's too much of a black box for me.
- + Create sequence diagrams for Authorization Agent based flow.
- Justin: Pavlik is correct, the text on the authorization agent and the text @jaxoncreed is referring to is in the process of being published and in a handful of days we can start referencing it. This discussion seems premature. From a priorities standpoint, there are some basic fundamentals to be established. A discussion like this needs a lot of basis and context to make it productive. It references some contexts that need to be vetted. There's a solution that's being proposed, but the problem area needs to be depicted. And there's material being created taht provides some context on this, but it seems like there are more emminent things to talk about before we get to this.
- Jackson: We are talking about client constraining access controll because we believe it could backpaddle and affect discussion on authentication. For example if token needs to include client capabilities.
- Justin: Detailing that concept is on its own a good topic for discussion. And any specification work that can be done on OIDC should be referencing and taking that into account, so if there's material along those lines, that would be good, but until that discussion is settled as a basis, and we should be focus on that question.
- Jackson: My proposal was created in response to objection to user focused client constrained. It shows that we don't need to add another system and can reuse existing one.
- Osmar: I still want detailed description of the problem we try to solve.
- Jackson: As a resource controller I want to allow users to access it with any application they want to use. I think you don't find this use case convincing.
- Pavlik: And just to clarify this use case: The resource controller would want the clients to decide. And I want the resource server to enforce the constraints that the user put on these clients.
- Justin: There's a pretty clear narative here that could be written up concicely, that could catch everybody up and allow people to deliberate on this intelligently and better represent their own thinking on it.
- Oz: before talking about the solution if we can see a requirements spec around what are the expected user workflows around the use cases.
- Jackson: use cases: https://github.com/solid/authorization-and-access-control-panel/issues/67, https://github.com/solid/authorization-and-access-control-panel/blob/master/UseCases.md
-