# W3C Solid Community Group: Authentication Panel

* Date: 2022-03-14T15:00:00Z
* Call: https://meet.jit.si/solid-authentication
* Chat: https://gitter.im/solid/authentication-panel
* Repository: https://github.com/solid/authentication-panel

## Present
* Aaron Coburn
* elf Pavlik
* Matthieu Bosquet
* Nicolas Seydoux

---

## Announcements

### Meeting Recordings and Transcripts
* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
* Use panel chat and repository. Queue in call to talk.

### Participation and Code of Conduct
* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/)
* [Solid Code of Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md)
* If this is your first time, welcome! please introduce yourself.

### Scribes
* elf Pavlik
---

## Agenda

### Pull Requests
https://github.com/solid/solid-oidc/pulls

*

### Issues
https://github.com/solid/solid-oidc/issues

* [In some cases OIDC issuer can't be disclosed in WebID Profile #92](https://github.com/solid/solid-oidc/issues/92)

## Minutes

### DST changess

* Pavlik: Can we stick with US time for next two weeks?
* Matthieu: ok for me, even better.
* Nicolas: ok

### In some cases OIDC issuer can't be disclosed in WebID Profile

[Issue#92](https://github.com/solid/solid-oidc/issues/92)

* MB: During AuthZ this requirement came up. We also discussed TrustedApps, which has privacy issue of having user disclosing trusted apps to the public. It stroke me that in many places disclosing trusted issuers in WebID document could be privacy issue. Depending on circumstances it could be damaging to someone forced to disclose it. For example government service.
* eP: For example unemployment service
* MB: We discussed someting in lines of WebID TLS where key management would be on the OP side.
* ...: You would disclose some kind of secret allowing verifying the issuer. So pretty much just public key of the issuer.
* NAS: So pretty much user would be providing OP rather than WebID.
* MB: I mean that OP would keep private key for each of the user. And as a user I would disclosed the public key associated with private key used by OP for my WebID.
* NAS: My understanding was that we want to center things around WebID. But here user would need to provide OP to the client.
* AC: It sounds like we can use `did:key` or something described in WebID-TLS. Is it separate from Solid-OIDC? We could have different kinds of interaction which could look more like WebID-TLS. This is valuable use case but not everyone use case.
* eP: Currently in [section 8.1](https://solid.github.io/solid-oidc/#id-token-validation), we say "unless the verifying party accepts keys via other means...". IOW, we already have this described "via other means", so could we use this to extend Solid-OIDC? Without disclosing issuer? I.e., just like Solid-OIDC but where the keys are retrieved via some other means.
* eP: It would be useful if the keys were also in JWK, that would keep the feature very similar to the current flow
* MB: I don't have well constructed opinion if this is too much of a departure to have it there. If it is compatible it would be nice to have it in Solid-OIDC.
* NAS: Currently it is possible, when you log user in based on WebID you know the WebID and discover OP from there. Then you can get OP keys. Is it possible that you can get token which was spoofed? There is no strong relationship between OP and the key. This is a strong change compared to Solid-OIDC. That may warrant to have it separate.
* AC: Let's say you have 2 storage servers A and B. With A there is this pre-existing trust where it trusts issuer P. Server B does not have the same trust with issuer P. What happens if a user tries to log in to server A with issuer P, they can do it fine. They would fail to log in to issuer B since they don't have that trust.
* ...: What might be interesting as an alternative, is rather than trying to say I trust this particular issuer or specific issuers. I trust a [federation of issuer](https://openid.net/specs/openid-connect-federation-1_0.html). If you trust federation of let's say 20 or 30. It will not give away that much information. This may answer some of the use cases. We would have the question how you discover the federation.
* MB: The federation would still be a group of issuers adhering to certain set of values. It may be more private, but still disclose some association with the values carried by such federation.
* eP: Aaron, is it related to issuer restriction case? For example `acp:issuer`
* AC: The first thing is AS looks up the WebID profile to check the issuer is trusted by this WebID profile. Because I can write a valid ID TOken claiming to be anyone. How can an AS know that this particular ID Token is to be trusted.
* eP: We discussed having a public key that could proove the token was issued by someone trusted.
* AC: We would have to be careful about token rotation.
* eP: Yes, with per user key it's probably less frequent need, but it would indeed put some management burden on the user since they would have to do it.
* MB: If this scenario is one that we would support, yes the user would need to manage key rotation.
* eP: If you want to avoid rotating that, it's a kind of trade-off. There could be a standard period for the user to update their profile. Some services prompt a user to change their password regularly, it seems reasonable.
* MB: Issuer restrictions would get more complex here. If issuer is in charge of managing key pairs it could be a piece of software on your machine.
* eP: Do you refer to self-issued OIDC like flows?
* MB: Yes, it is de-facto the same kind of thing (or a possible implementation thereof).
* eP: How to follow up on this issue/conversation? Is anyone interested in proposing initial text of how to address it?
* MB: It might be interesting to involve people behind WebID-TLS. The main problem was usability issue, which was never resolved on the browser level. If that could be resolved server side.
* eP: Would you like to reach out Matthieu? I'll try to reach out to the self-sovereign identity people.
* MB: Yes, I'll reach out.
* AC: In terms of scope I'd like to make sure that we make it clear what is in scope for Solid-OIDC. I think self-issued OIDC is much more in scope. When it comes to WebID-TLS I would see it outside of the scope. I would rather see multiple documents rather than one complicated with forking options.
* MB: At this stage, I only mentioned WebID-TLS just because it relies on public/private key pair. I would ask what about managing private key on the server side. Maybe the two aren't incompatible.
* AC: One thing to keep in mind. When it comes to existing OIDC infrastructure and ecosystem. The more requirements we put on OP, the harder it is for existing ecosystem to adjust.
* ...: WebID scope (fairly typical, adding new scopes to OPs)
* ...: DPoP which is draft and moving through to the OAuth working group
* ...: Entirely Solid-OIDC is the client identifiers which is a little bit of a challenge for new providers to support...
* Anything we add akin to that 3rd category/the more requirements we add to OPs, the harder it will be for existing ones in the ecosystem to come along with where we're going.
* EP: I'm thinking the core spec could have a generic working as an etension, but not as a requirement (issuer delegation/publishing public key). I think it would be a completely different spec and let some server implement that. In my case, if there's no IdP restriction, that's fine, if there are restrictions, then the user is stuck with that OP if they want to use data.
* MB: In solid we want to separate the concerns. Enforcing issuer restriction is a way of locking you into an island of solid ecosystem. If you want to use provider which does it.
* eP: If the data owner wants to restrict the data access, you pretty much rely on issuer restriction, you're stuck
* AC: I wanted to mention that this conversation started around privacy and at present you have to disclose the issuers in your WebID profile. I think we should keep it separate from the conversation about getting locked into a specific issuer.
* NAS: I agree with Aaron
* MB: +1

ACTION: MB to follow up with WebID-TLS community
ACTION: eP to investigate self-issued OIDC

* eP: If we dive into HTTPSig worked on by Henry we should keep it in authentication-panel repo instead of following up on [#92](https://github.com/solid/solid-oidc/issues/92).