Skip to content

Latest commit

 

History

History
107 lines (77 loc) · 10.4 KB

2022-11-07.md

File metadata and controls

107 lines (77 loc) · 10.4 KB

W3C Solid Community Group: 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

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?q=is%3Apr+is%3Aopen+sort%3Aupdated-asc

Issues

https://github.com/solid/solid-oidc/issues?q=is%3Apr+is%3Aopen+sort%3Aupdated-asc

Reconsider Client Identifiers

Minutes

Open PRs

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

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 definitions 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. Among other things, it defines a mechanism to define clients globally. The question is whether we can reuse it. The draft is at version 24. I have a 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 should be to easy to support current and next.
  • AC: As to migration path, there are 3 parts to federation when it comes to client identifiers. The client/application interacts with various endpoints 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 no 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 a 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 ecosystem.
  • ES: I understand Wouter talks about use.id.
  • eP: I haven't looked deeply into the trust chain. It would rely heavily on redirect_uri validation. Basic safety comes from that. What is the minimum needed for the trust/signature chain?
  • AC: In terms of minimum that's needed. One of the big differences between federation and our current client identifiers approach mostly relates to federation vs decentralization. As I mentioned, Client ID Documents don't currently 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 trust 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 of the spec that need to be adjusted to address our needs, we can ask.
  • ES: Can one really have OIDC Federation without having an OIDC server? We saw developers struggle even with rolling out client identifiers to the general public. Anything more complicated than that might be a step to far. We may need to provide a lot of tooling to make it possible for developers. We find many developers 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 has more complicated data structure and 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 least, 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 about a more centralized review process for apps. So while there is complexity, it also provides a (partial?) solution 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 some features that we will need and don't have at this moment.
  • WT: Where in the spec does it say that the leaf entity can't be its 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
  • WT: +1
  • 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 trust anchor at solidproject.org; can it say that all clients registered with it have a flag that it marks 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 section. 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 development preview. On the consent pages, we can flag that aspect of the application. I think trust will be a big part for any application in the future.
  • AC: I hear from practically all of us that trust is important. OIDC Federation can provide 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 hodgepodge.
  • AC: I would like a straw poll just to gauge opinions.
  • eP: I support 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 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 OIDC issue #207 that we were all in favor of pursuing it and fleshing out all the details.

  • ES: Would the OP for Solid Server 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 separate. One can have metadata for RP and 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 requirements for security, and once OP complies, it could be added to the federation.