# W3C Solid Community Group: Authentication Panel

* Date: 2022-03-21T14: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
* Abel Van den Briel
* elf Pavlik

---

## 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
* Aaron Coburn

---

## Agenda

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

*

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

* Deadline for ~FPWD
* [Specify the client authentication method when using a Client Identifier #78](https://github.com/solid/solid-oidc/issues/78)
* [Presenting multiple WebIDs in an ID Token #47](https://github.com/solid/solid-oidc/issues/47)
* [Accessing NonRDF-Sources directly via browser #31](https://github.com/solid/solid-oidc/issues/31)
* Overview of Client Credentials in Solid-OIDC

## Minutes

### FPWD Deadline

* AC: I think we should set specific data
* eP: We are pretty much ready, will take a last pass and check for in-line issues
* AC: We've been talkin about conformance classes. Should we wait for it.
* eP: good question (started with small pieces, script tags, etc). It would be better not to delay. We are clear that there are a few things to do. Will make a simple PR for this next week.
* AC: How about next week deadline?
* eP: +1
* eP: conformance classes can be added later, if they don't make it into the FPWD
* eP: there was an issue about namespaces

ACTIONS: AC will write PR to address [namespaces issue](https://github.com/solid/solid-oidc/issues/23)

ACTIONS: eP to add any missing issues inline
ACITONS: eP to add first version of conformance clases

### Specify the client authentication method when using a Client Identifier

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

* eP: https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication

> none
> The Client does not authenticate itself at the Token Endpoint, either because it uses only the Implicit Flow (and so does not use the Token Endpoint) or because it is a Public Client with no Client Secret or other authentication mechanism.

* eP: we should clarify what confidential clients do
* AC: are we going to restate what OIDC or OAuth2 states about it?
* eP: How do we see this working in practice? In some implementations, it seems to work with `none`?
* AvdB: the spec mentions client registration? where would the `none` be set?
* AvdB: when you register a client (e.g., Dynamic Client Registration), you can set a particular method. For Client Identifiers, these are public clients
* eP: I wasn't sure if this is for the token endpoint
* AC: Nature of client identfires is that these are public clients. If it is confidential clients. Those client identifiers are intended to be public clients. Maybe we should be clear about it the spec.
* eP: for use with confidential clients, in interop panel (authorization agent), it acts as a confidential client
* AC: what we define is about Public Clients but we don't say anything about confidential clients. If impl supports confidential clients can do whatever it does.
* eP: can Public Client get a refresh token?
* AC: There needs to be interaction with end-user to confirm refresh token.
* AC: I'm not a fan of refresh tokens, mostly with browser limitations.
* eP: it's recommended that an ID token is short-lived, so how do you get a token that isn't expired
* AC: One approach is using refresh tokens, another approach is rather than redirecting user away, open new window and direct user through the auth flow. Given that the have cookie there should not be any interaction
* eP: the prompt=none
* eP: for now, we can make this an in-line issue to make sure there's no problem/constraints with public clients
* eP: likely not before FPWD
* eP: for server-side client impl, we plan to use refresh tokens. With client credentials, it might be more attractive to use those

### Presenting multiple WebIDs in an ID Token

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

* AvdB: This may have been related to a blogpost about a WebID being a 1-1 relationship. E.g., one person can have multiple WebIDs, we may need the ability to put multiple WebIDs in a token.
* eP: Correlating WebIDs seems against the point of the blog post, because one may want to keep those identities separate, from a privacy consideration
* eP: If an OP puts all identities in a single token, that seems like a problem for privacy
* AC: I have multiple identities for different contexts, personal, work, open source etc. There are different trust domains and I like to manage them distinctly. When I login through some corporate id I don't get access to something I have access outside work. And vice versa.
* ...: Sometimes you want to say that a person have different identifiers and they should be able to use any of it. We can see nowadays people logging with google, twitter, facebook etc.
* ...: I would argue that ID Token is scoped to particular OP. If it manages this identity it should focus on that. We could focus on using multiple ID Tokens and possibly exchanging them at UMA AS. It can be more managable if we keep them separate from the start. For example building VCs based on separate identities. For ID Token there is focus on single WebID.
* eP: possibly a good point about multiple tokens, e.g., switch between different tokens/identities. If we get into VCs more generally, we need a mechanism for controlling disclosure. For multiple WebIDs, it seems that this can be achieved with multiple WebID tokens (e.g., pushing multiple times to an AS). Probably best to clarify the use case
* AvdB: email is probably a bad analogy, since there is a separate login. If all the WebIDs are in the same place, then it would also see all my other WebIDs at a given OP.
* eP: any objections to making this an inline issue? Perhaps mention in primer about using multiple ID tokens
* eP: "The webid claim must be the User's WebID" (TODO: verify text from spec)
* AvdB: I'm also not enitrely certain about this use case, need more clarification

### Accessing NonRDF-Sources directly via browser

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

* eP: Created an issue in the specification repository
* ...: Ruben mentioned the "Databrowser Hack"
* ...: Maybe we can just close this issue in Solid-OIDC and continue in the Solid Protocol spec issue
* AC: +1

ACTION: eP: close this issue and track the discussion in the protocol specification

### Overview how client credential is coming along

* AvdB: in various meetings there have been some discussion about how client credentials would work in the Solid Ecosystem. What is the status?
* eP: https://github.com/solid/solid-oidc/blob/main/alternative-flows.md
* eP: I think we should center the discussion around the document referenced here.
* ...: We should start creating issues where these items can be discussed
* AC: This issue has been around for quite some time. There are a number of experiments. There is a larger question about how we should specify that. Sometimes you want some exprimentation to lead implementation around particular pattern. I would be interested of client credentials in more comprehensive way. What are other flows that we have in solid. See what patterns come up in common.
* ...: Rather than have series of fall starts we should get a good sense of what we try to do first.
* eP: I likely won't have time to focus on this during March, but hope to pick this up in April and later, esp with public key authentication. Consent is another, related area.
* AC: The question of public/private key is pretty powerful. In a way it gets us back to WebID-TLS but we could avoid UX issues which it had.
* AC: Credentials Community group has been working on various solutions. CHAPI, DID-Comm etc. We've been really focused on OIDC but we should complete it and strat looking at other interesting approches which can be more flexible.
* eP: on the topic of public/private key, Henry has been using this with HTTP signatures. DPoP and GNAP also use proof of possession mechanisms. The common part can be about the publication of public keys.
* ...: it would be good to clarify how these public keys can be published in Solid, one of the future focus areas after Solid-OIDC
* AC: We wondered a little bit away. We should answer some of the questions brought up.
* AvdB: In general, we have been looking into and documenting how client credentials can be used with Solid, but we will want to explore some of the other flows, too
* eP: for me, the key question is that some of the OIDC test suites might fail if client credentials is supported. There is still the question of consent and whether a user approves that the client can use the ID token. This consent mechanism may span these different flows.
*