# 2020-07-13 Authentication Panel

## Agenda

* Solid-OIDC Issues
* [Verifying client's control of claimed WebID (client_webid) #52](https://github.com/solid/authentication-panel/issues/52)
* [Next week agenda](https://hackmd.io/cvW3fSb5S4qBm3rl7XlECg)

## Present

* Aaron Coburn
* Dmitri Zagidulin
* Jackson Morgan
* Justin Bingham
* Ricky White
* elf Pavlik
* Adam Migus
* Davi Ottenheimer

## Minutes

### [Verifying client's control of claimed WebID (client_webid) #52](https://github.com/solid/authentication-panel/issues/52)

- Adam: WebID is not ultimately trustworthy, just as User-Agent, it's self asserted fact. I don't see need to make it any stronger. Looking at the rest of the protocol it doesn't seem to break anything.
- Jackson: Would it be possible to create terminology when we say WebID, we know if we talk about User's WebID or Client (application) WebID. In the past we asserted that one can spoof client webid to RS, it is more difficult tot spoof it to IdP. We have considered including `redirect_uri` in client's WebID Document. This way app would not be able to spoof identity to IdP. RS is dealing with the same problem, plus case where client and IdP are colluding to spoof client's WebID.
- Adam: What is the argument to have that strongly verifiable client WebID
- Pavlik: I think this is needed for authorization not for authenticadtion and it seems like a extension point to build on for authorization.
- Adam: We are not going to create really good spec if we front run implementations. In Aaron's implementation authorization is not implement yet. I think as Pavlik suggested it may not belong to the spec at least now.
- Aaron: My implementation uses `redirect_uri` as client_webid. To state what I think Jackson is hinting at. We have a use case where RS is trying not only which users has access but also which clients can access. I think we should clarify that inluding `localhost` address is asking for problem.
- Adam: I see so many open questions with no concrete need for it yet. It is a bigger problem than this call. If we want to include this client_webid requirement we may need to clarify a lot of things we haven't done yet.
- Davi: It seems worthwihile to do but separate from this conversation.
- Jackson: In general we can leave things for later, but I would recommend working on it soon. In terms of use cases Oz wanted this as a use case.
- Davi: What do you mean by soon?
- Jackson: I think next months, not go into complete icebox. Here is my proposal: https://github.com/solid/authorization-panel/blob/master/proposals/TrustedAppsReplacement.md#general-networking-flow
- Justin: I generally agree with everyone. Ecosystem proposal [has section on client identification](https://solid.github.io/data-interoperability-panel/ecosystem/#client). Weekly identifiable clients are only strongly identifiable to the user using them. It is hard to enforce Justin only allowing Adam using specific app. As a user I have better possibilities to enforce which apps that I use can access specific data.
- Jackson: So any reference to `client_webid` will be removed from current draft and we will work on how it suppost to be specified. I've posted above my proposal to how I see it defined.
- Adam: Out of scope section is empty and we can mention it there.
- Davi: It seems that we have two competing requirments.
- Justin: In flows that we present we rely on IdP to furnish the client id and include it in the token.
- Jackson: Putting it out of scope means only for this version of the draft not for the final spec?
- Adam: We put it in the out of scope sction with language that it has to be addressed.
- Pavlik: If we plan to indlude it in the spec, putting it in out of scope sounds contradictory.
- Adam: I can't comment on the timeline of the spec. Can all those conversation happen in the time window while Ricky and I are engaged in work with Inrupt.
- Adam: So 1.0 version of the spec would keep it in out of scope section.
- Aaron: I see it as really thorny issue, yet to see something air tight. If 1.0 spec depends on it we will never get to it in any reasonable time frame. I think we need strong of things we are confident about and call out other things we need to address. Because of this interaction with authorization we get into this weird cycle. If we have this mutual dependency we will block each other for the long time. I would propose to have it as an extension point or something to need to be addressed in the future.
- Adam: I see this problem registered forever in OAuth circles and it still doesn't seem to have solution. It may hold up 1.0 indefinetly if we commit to address it. Spec can't have half way concepts in it.
- Justin: I see those arugments as compelling. Maybe we could agree to just include some 'hooks', saying that if you want to incorporate specific requirement you should do it this way.
- Aaron: Because we use JWT we already have way to extend it. I would prefer to have usage patterns that develop. We could figure out best way to do it through implementations.
- Adam: We can include section in Security Considerations explaining client identification.
- Davi: We can work on it in security panel.
- Jackson: We've been handling it in both AuthN and AuthZ panels. I've linked it couple of times.
- Justin: We removed bunch of inactive panels last week. We have 3 active panels AuthN, AuthZ and interop.
- Jackson: Specification should consistently point out all the possible holes.
- Henry: I think we should have an issue open.
- Adam: Let's talk next week how we refer to what Ricky and I deliver.

### Solid-OIDC Issue