https://meet.jit.si/solid-authentication
- more common sequence diagram — PR #17
- Advertising trusted OIDC issuers via Link headers — Issue #32
- The Public OIDC Client URI
- How to make meetings more inclusive, especially for broader solid community
- elf Pavlik
- Aaron Coburn
- Nicolas Seydoux
- Barath Raghavan
- ewingson
- CSS Identity Provider
- ESS Identity Provider
@inrupt/solid-client-authn-*
The diagram in PR-17 will replace what we currently have with one which is based on a more common format. The source description of the diagram will use the mermaid syntax, and the output SVG will be part of the documentation.
Advertising OIDC issuers in server-managed link headers is an optimization that makes it possible for client applications to avoid parsing the RDF the WebID document.
Aaron: This shouldn't be required, but if the server supports it, the Resource Server should consider the headers authoritative.
Pavlik: Clients could also use this to start with a WebID and the trusted issuer can be used to initiate the login flow. Most cases will have a single OIDC issuer.
Nicolas: that would make for a nice user experience on the relying party side and an optimization for the resource server.
Pavlik: Make sure that the spec makes it clear that the only hard requirement on the client is to parse the WebID and get the OIDC issuer from there, and that it cannot make it a hard expectation to find the headers.
Pavlik: in interop panel, there is an expectation that there would be application id and user id with each interaction. The use of the Public OIDC Client URI seems problematic: how would a resource server be able to rely on an app identifier when apps use this mechanism? What are the cases where this is needed?
Aaron: this public URI is to bridge using a IRI for client identifiers. If you have a client that is unable or unwilling to perform DCR, and does not have a Client ID IRI, it can use this IRI as a fallback. The public client IRI is analoguous to the notion of an anonymous client. One option may be for the spec to mention that clients are encouraged not to use it, and resource owners would be recommended to limit the level of permission given to such clients.
Pavlik: if we put something in the spec, people will use it. From an authZ perspective, the user will be giving explicit consent to a particular client. Attaching to a public key would be a stronger way to identify clients. Using this public identifier may introduce undesirable patterns for Solid.
Nicolas: dynamic client registration is currently supported for ephemeral clients. Moving away from such ephemeral clients may be desired, but this provides a path by which clients can begin using IRIs to identify themselves.
Aaron: Part of the issue is the question of bootstrapping. If you have a definite allow-list of clients allowed to do something, how can any new client request being added to this allow-list ?
Pavlik: Is it a possible security vulnerability, where the credentials to a public client may get higher credentials than a client which is explicitly forbidden? Assuming that the Requesting Party (RqP) and Resource Owner (RO) are different, the RO may give access to the RqP, without specifying anything about the Relying Party that the RqP will use.
Nicolas: It is very valuable to get feedback from implementers and users. Implementers have technical knowledge about OAuth, OIDC, etc. This doesn't need to hold for regular app developers. It would be valuable to get feedback from those app developers and even users.
Pavlik: looking at the audience of the spec, it's mostly implementers rather than users. Most app developers would use some well-developed library, so that they don't introduce security holes. What sort of feedback flow would you like to see for this?
Nicolas: What I'd like to see is not about inviting the entire solid ecosystem. For
some users, it could be useful (e.g., the conversation about solid:PublicOidcClient)
that app developers understand the details of these decisions.
Pavlik: The app developers will likely use some library. Would it be better for the app developers to give feedback to the library developers, and then the library developers will give feedback to the specification? That separation might be a better structure.
Nicolas: That separation makes sense, but one issue is that there is currently only a single implementation, and if there is bias in that implementation, then that bias might be perceived as part of the specification rather than an implementation decision.
Aaron: I discussed with Nicolas the possibility of having infrequent but periodic open meetings from the panel. Could be on separate days if needed. Once a month or once every two months, we could post an open invitation to solid-chat and/or solid-app-developers to come to the meetings and ask questions. While we may want this indirection of feedback app devs -> lib devs -> spec wirters, we also want to have broader base understanding among all.
Barath: As someone who just joined the conversation, I don't see clearly the decision process, who makes decisions on what stays in the spec. Is there a chair for each panel who gets elected by everyone present? Has this process been made explicit and followed?
Aaron: I think you are right to point out that the process is now opaque. At present, the AuthN panel oversees all things related to authentication. Specific proposals come to the panel, the most mature of which is Solid-OIDC. Henry Story has been drafting HttpSig which is at an earlier stage. People act as editors of specific proposals. Even Solid-OIDC is in pre ~First Public Working Draft mode. Once we put a stamp and we call it ~FPWD or even ~Candidate Recommendation (~CR), the process will need to be much more formalized.
Barath: Just to clarify, I'm not worrying about people's intentions. Codifying process might be useful to be done sooner than later.
Aaron: We currently start with opening an issue on github. We then clarify possible solutions, and finally we create PRs and work toward merging them. There are some smaller, simpler changes that can skip the issue step, and proceed directly to PR.
Pavlik: Until recent weeks, there has been a very limited audience to the meetings, which helps explain the lack of formalism in the decision-making process.
Ewingson: Having a dedicated forum to ask questions around authentication is very interesting. It makes for a better community.
Pavlik: The learning curve may be steep, so what is your experience on how you'd expect to engage with the authentication panel?
Ewingson: My contribution to the ecosystem is to run NSS and potentially CSS, but I'm glad I can ask questions around authN, too.
Pavlik: has there been any client-based work for non-browser based interactions? For example, device code flow?
Nicolas: The node.js-based client library does not expect there to be a browser redirection,
but it expects that the client manages that redirection externally.
There is also a mechanism for the use of refresh tokens.
There is also a mechanism for client credentials.
No support for device flow at present.
Pavlik: The client_credentials would require some sort of static registration. It would just require the IdP to support that feature
Nicolas: That's part of the OAuth2 spec, and could be added to a Solid-OIDC provider (e.g., a self-service endpoint). This has been a common request that has come from the community. There are some challenges in the Solid context (e.g., client identifier), but it would be interesting to explore these options.
Pavlik: it would be good to provide some support for these sorts of scripts.
- @acoburn will make a PR for solid/solid-oidc#32
- @elf-pavlik to open issue about Public OIDC Client URI
- @nseydoux to open an issue describing limitations client credentials flow
- @nseydoux to open an issue proposing some approaches to enable broader discussion around the spec