# W3C Solid Community Group: Authentication Panel

* Date: 2022-11-07T14: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
* Emelia Smith
* Wouter Termont

---

## 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
* Pavlik

### Introductions
* Emelia: I work at Inrupt with Aaron. I work on SDKs including authn SDK.

---

## Agenda

### Open PRs

https://github.com/solid/solid-oidc/pulls

### Issues

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

[Reconsider Client Identifiers](https://github.com/solid/solid-oidc/issues/207)

## Minutes

### Open PRs

AC: Both Pavlik and I made PRs to authentication panel to clarify UTC. I'll close mine since Pavlik's has little more details.

### Reconsider Client Identifiers #207

Proposal:

> The Solid-OIDC specification should drop the current definition of Client Identifiers and associated JSON-LD appendix in favor of adopting the OpenID Connect Federation definition of an Entity Identifier and Automatic Registration

AC: With OAuth2 and OIDC it is hard to globally identify clients. In most cases client_id is local to the OP or AS. In Solid we need global client identifiers, and defined them in Solid-OIDC.
...: Now there is the [OpenID Federation draft](https://openid.net/specs/openid-connect-federation-1_0.html
). Among other things it defines mechanism to define clients globally. The question is if we can reuse it since it. The draft is at version 24. I have specific proposal which I would like to suggest. Let's take some questions first.
WT: I also went through most of the spec. I want to know what people see as possible obstacles.
ES: With migrating to OIDC Federation, what would the migration plan look like. The server would most likely need to support current version and next. How would we deal with the federation.
WT: I think it shouldn't be that hard. It sould be to easy to support current and next.
AC: To migration path, there are 3 parts to federation when it comes to client identifiers. The client / application interacts with various endponts using client_id query parameter with URL as value. This will not change.
...: The two others are not as easy. On OP level, it will need to use the .well-known instead of just dereferencing the client_id. Check the signature chain etc. It is more complicated. On the plus side, since it is spec in OIDC family of specs. We can expect that OP providers will support it. The Solid specific provider should be able to make use of that. So in the short term there might be more work for OPs but in long term it should be more broadly available.
...: Currently there is not requirement on signatures and trust chains for Client ID document. If we go with OIDC Federation, you can't just publish the document. It has to be signed and there must be trust chain.
WT: Do you know about existing implementations of OIDC Federation draft?
AC: I currently don't know any. I also don't know about any Solid Client ID outside of Solid.
WT: We implement it.
AC: I know, I just don't expect adoption outside of Solid-OIDC ecysystem.
ES: I understand Wouter talks about use.id
eP: For the trust chain, I haven't loooked deeply into that. It would rely heavily on the redirect_uri validation. The basic safety comes from that. What is the minimum needed for the trust/signature chain.
AC: In terms of minimal that's needed. On of the big differences between federation and our current client identifiers approach. It mostly relates to federation vs decentralization. As I mentioned currently Client ID Documents don't have to be signed. In a way they are the root of their own federation. How can we replicate that federation of one entity in context of solid. In order to have that minimal structure, there are two concepts: *trust anchor* and *leaf entity*. I understand that they have to be different, IMO it would be easier if they could be the same. At the same time I think both can be provided by the same software package. If we take some app, it could provide both, even created by developer at build time using some static mechanism. So SPA should work as expected. I was unsure if turst anchor has to provide set of APIs, federation API and list API. If we take some photo application, it ends up signing the app key with federation key. The verifier asks for key with some id *1234*. Some problems could come up with relation to implementing it.
eP: keep in mind that this is still a draft and if there are areas that need to be adjusted, we can ask if there are areas of the spec to address our needs.
ES: Can one really have OIDC Federation without having an OIDC server. With rolling out client identifiers to the general public, we saw developers to struggle even with that. Anything more complicated with that might be a step to far. We may need to provide a lot of tooling to make it possible to do for developers. We find many developers to host Client ID documents on solid storages.
AS: I think you hit the nail in the head. I was a little surprised how easy it was to mess up client identifiers. Using federation will be much more complicated, it's more complicated data structure and it also introduces signatures. There are 2 things that need to happen. With client identifiers part of the idea is that one can hand write those documents. At leeast that's how I did it. If we go OIDC Federation path we probably will want special tooling for it. There could be federation providers which could take care of the signing for the developer and we could provide a really good tooling for it.
eP: Agree that it will add complexity, but we also don't currently have a mechanism for trusted apps / app stores. There could be community / corporate trust anchors. There have been conversations to have a more centralized / review process for apps. So while there is complexity, it also provides a solution (partial?) to a problem that we haven't yet been able to solve.
WT: I agree that there could be some advantage. IMO even now developers need tooling to assist them.
AC: I agree with both of you. Yes it is more complicated but it also opens up to some features that we will need and don't have at this moment.
WT: Where in the spec it says that the leaf entity can't be their own trust anchor?
AC: Let me find it... https://openid.net/specs/openid-connect-federation-1_0.html#section-4.8
...: It relates to federation fetch endpoint which has mutually exclusive requirements for trust anchor and leaf entity.
WT: Maybe it's just an oversight.
eP: Perhaps we should create an issue for this. We can then get a sense of whether this might be addressed in the federation spec
AC: I think I have a good idea about the problem.

ACTION: AC to create issue tracking disjont definition of leaf entity and trust

ES: I understand that federation works with the same claims as dynamic registration. Is there a way to add more data? Let's say we have trus anchor at solidproject.org, can it say that all clients registered with it have a flag that it marks it as 'in preview' or untrusted. It would be helpful with any app marketplace to mark apps.
AC: Yes you can add metadata. Inside of Entity Configuration there is *metadata* secion. It is generally what we would see in .well-known/openid-configuration for the RP there would be mostly dynamic client registration information. There is also *metadata policy* which can for example define constraints in all entities in the federation, which is kind of nice. It can set high level constraints in the federation which can be well defined in the whole system.
ES: People often mix localhost and production URLs together, which I recommend since it says it is the same client. To be able to have a federation server, which says *all documents registered with me are developmen preview*. On the consent pages we can flag that aspec of the application. I think trust will be a big part in the future for any application.
AC: I hear practically from all of us that trust is important. What OIDC Federation can give us provides much better foundation for building this trust. We can devise a specific federation which is for development. When you use that app with your pod you will know how much you can trust it. Now everything is a hodge podge.
AC: I would like a strawman vote just to gauge opinions.
eP: In support of exploring this. Am interested in drafting a PR to the primer, where we can see what form this will take. That will give us an idea for how the spec change would look.
ES: Getting the primer written first will be a good step. Showing how the things will work in context of solid will help.
WT: I think this is a good idea, we should look for minimal setup based on OIDC Federation.

ACTION: AC to add note to the issue 207 that we were all in favor of pursuing it and fleashing out all the details.

ES: Would the OP for Solid Server would be the same as provider of the federation server? For example would one go to id.inrupt.net to register the client.
AC: I feel like one could have a federation which would be tied to OP but it could also be independent. If I were to write it I would probably keep them sepeate. One can have metadata for RP but also for OPs. If you want to be a root for OPs you would want to be independent from a specific OP.
WT: It is really attractive to keep them separate but also bundling multiple providers in ecosystem. The federation can put extra requrements for security and once OP complies it could be added to the federation.