# 2021-08-23 Solid Authentication

https://meet.jit.si/solid-authentication

## Agenda

* [more common sequence diagram #17](https://github.com/solid/solid-oidc/pull/17)
* [Advertising trusted OIDC issuers via Link headers #32](https://github.com/solid/solid-oidc/issues/32)
* [The Public OIDC Client URI](https://solid.github.io/solid-oidc/#clientids-public-uri)
* How to make meetings more inclusive, especially for broader solid community
*

## Present

* elf Pavlik
* Aaron Coburn
* Nic AS
* Barath R
* ewingson

## Minutes

### Current implementations of Solid-OIDC

#### Provider-side

- CSS Identity Provider
- ESS Identity Provider

### Client-side

- @inrupt/solid-client-authn-*

### Sequence diagram update

The diagram will update what we currently have but which is based on a more common format. The source description of the diagram will be in OpenFlow (?) syntax, and the output SVG will be part of the documentation.

### Advertising trusted OIDC issuers via Link headers

Advertizing OIDC issuers is an optimization that enables bypassing parsing of 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 that trusted issuer can be used to initiate the login flow. Most cases will have a single OIDC issuer

Nic: 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.

### The Public OIDC Client URI

Pavlik: in interop panel, expectation that there would be application id and user id. This seems problematic: how would a resource server be able to rely on an app identifier. What are the cases where this is needed.

Aaron: this public URI is to bridge to using URI for client identifiers. If you have a client that doesn't want to perform DCR, and doesn't have a Client ID IRI, it can use this IRI as a fallback. The public client IRI is analoguous to the notion of anonymous client. The spec may mention that clients are encouraged not to use it, and resource owners would be recommanded 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 ginving 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

Nic: dynamic client registration is currently supported for ephemeral clients. Moving away from such ephemeral clients may be desired, but it provides a path by which clients can begin using IRIs for identifying themselves.

Aaron: Part of the issue is the question of bootstrapping. If you have a definite allowlist of clients allowed to do something, how can any new client get access to this allowlist ?

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 ? The RqP and RO are different. The RO may give access to the RqP, without specifying anything about the RlP that the PqP will use.

### Accessibility to entire Solid community

Nic: It is very valuable to get feedback from implementers and users. Implementers have technical knowledge about OAuth, OIDC etc. This dosn'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?

Nic: What I'd like to see is not about the entire solid ecosystem. For some users, it could be useful (e.g. 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 give feedback to the library developers and then the library developers will give feedback to the specification. That separation might be a better structure.

Nic: 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 that specification rather than an implementation decision.

Aaron: I discussed with Nic having infrequent but periodic open meetings from the panel. Could be in separate days if needed. Once a month once every two months we could post open invitation to solid-chat and/or solid-app-developers to come to the meetings and ask their 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. Is this process has been made explicit and followed.

Aaron: I think you are right to point out that process is opaque. At present AuthN panel oversees all things related to authentication. Specific proposals come to the panel, most mature one is Solid-OIDC. Henry Story drafts HttpSig which is in earlier stage. People are acting as editors of specific proposal. Even Solid-OIDC is in pre First Public Working Draft mode. Once we put stamp and we call it FPWD or even Candidate Recommendation (CR) process must be much more formalized.

Barath: Just to clarify, I'm not worrying about people's intentions. Codyfing process might be useful to be done sooner than later.

Aaron: We currently start with opening and issue on github. Once we start clarifying possible solution we create PR and work towards mergning it.

Pavlik: Except for the latest weeks, it has been a very limited audience to the meetings, which explains the lack of formalism of 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 auth too.

### Non-browser interactions

Pavlik: has there been any client-based work for non-browser based interactions? For example device code flow?

Nic: 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

Nic: 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.

## Actions

@acoburn will make a PR for [solid/solid-oidc#32](https://github.com/solid/solid-oidc/issues/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