# W3C Solid Community Group: Authentication Panel

* Date: 2022-02-14T15: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 C
* Laurens D
* e Pavlik
* Nicolas AS
* Abel VdB

---

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

---

## Agenda

### Pull Requests

* [created WebID Document section #79](https://github.com/solid/solid-oidc/pull/79)

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

* [Authorization server behaviour for Client-Credentials Grant flow #75](https://github.com/solid/solid-oidc/issues/75)
* [Clarify implicitly trusted OIDC issuer #51](https://github.com/solid/solid-oidc/issues/51)
*

### Open business

## Minutes

### Introductions

* LD: Architect working with the Flemish government implementing Solid use cases.
* AC: Note that in order to contribute to any of the solid panels, it's better to join the Working Group (see the Participation & CoC section)

### created WebID Document section

[PR#79](https://github.com/solid/solid-oidc/pull/79)

* EP: This is a first bite-size PR to the overall restructuration. The WebID document section has been added as a conformance class. Verification of the WebID validity has been added in some conformance classes, e.g. in OIDC issuer discovery for the RS conformance class. Implicit trust to same-domain OP has been removed as well.
* AC: Should "to verify the ID token" be prefixed with the applicable conformance class ?
* EP:
* LD: It is mentioned that a WebID profile may trust multiple OP. What should we do there ? Could more metadata help making an informed decision.
* EP: There is a taskforce emering for the WebID document, which is considering if a preferred OIDC issuer should be specified.
* AC: This question has come up in multiple contexts. An interpretation to the presence of multiple OP is that the user may be presented with multiple options to log in (from the Client point of view). This means involving the user at this point would be a desirable pattern.
* EP: Note that ACP also allows to restrict issuers when accessing some data. If the user is logged in multiple trusted OP, then it may have multiple ID token to select from.
* NAS: Currently browser based clients wouldn't support being logged into multiple OP. We have full window redirect. It would be supported on the server side but we haven't actively studied it. We'll have to check how it applies.

### Authorization server behaviour for Client-Credentials Grant flow

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

* LD: Context: in the Flamish gov, we have two different ID tokens. A user-facing OP, and an OAuth 2.0 AuthN server for server-to-server communication. So far we are relying on the access token issued by the OP, and we used the OAuth 2.0 non-opaque access token in that role. Moving away from this pattern questions how to support this server-to-server communication.
* EP: In your use case, one of the server still acts as a client, correct ?
* LD: Correct. The server app acts on behalf of an orghanization through the client credentials flow.
* EP: In this flow, when you use the OAuth 2.0 access token, is there still a phase of issuer discuvery ?
* LD: The issuer for this organizational WebID is the domain for both the OP and OAuth issuer. So yes for discovery
* AC: One thing to mention, client credentials is more an oauth2 mechanism than oidc. It's unclear how Solid-OIDC will relate to client credentials. It is however very relevant to this panel, and we are looking at producing a different document with recommandations for this use case. However, it not being defgined with OIDC doesn't prevent from using the cleint credentials flow with an OP. The question the becomes, how do you pair the obtained client credentials with a WebID ? There are multiple patterns: (1) using a WebID as the Client ID. There are challenges with this, in particular the client ID will be unique, and then only one client secret will be supported. (2) having an interface where the client may register client credentials. You login through a web page, and you can obtain server-managed client IDs and secrets associated to this session.
* EP: Agreed in general. It would be worth defining some patterns for client credentials, if not specifying about it. At the end, we want a dpop-bound ID token to be obtained, so it sort of relates to the Solid-OIDc spec. If you could get an access token with the appropriate org WebID from a client credentials pair, would it work for your use case ?
* LD: I believe so. The only major concerns from ID team is that adding the client credentials flow will fail the conformance tests, because these flows are indeed undefined in the OIDC spec.
* EP: That's useful feedback. Justin also has use cases for the client credential flow, it would be interesting to get him to contribute to the question. The end goal is to have an ID token exchange at the AS, and to allow the ID token to be obtained in ad-hoc manner.
* LD: The OAuth issuer is managing its realm, and may add the WebID claim to the tokens it issues.
* EP: Do you use client identifiers ?
* LD: We are service integrators, and we have to check that the access tokens are properly bound to the appropriate WebID
* EP: Having a separate document for the client credentials flow seems to be a useful pattern.
* LD: +1
* NAS: +1
* AC: Having this separate document would allow discussing these use cases and how to best address them before possibkly merging this to the Solid-OIDC spec. A typical client credential flow will result in an Access Token, but in our case we want it to issue an ID token. There are also different flows which will be relevant too, such as device-code flow. Thinking of all these flows together would be useful.
* EP: These flows may result in significant changes in the spec (if they result in a non-ID token JWT). Considering this, should we discuss all these before working towards CR ? Not being even FPWD yet, we still have a lot of flexibility regarding the overall organization.
* LD: +1. It is worthwile to separate out the spec and address these concerns in a way which doesn't result in the Solid-OIDC spec being too bloated.
* EP: I would like us to start iterating on document specifying client credentials grant with OP.
* AC: This document would be an incubator before being moved in front of the panel and eventtually possibly the spec.
* EP: Which repository, solid-oidc or the panel ?
* AC: solid-oidc should be fine
* EP: +1
* LD: +1. I'll join the community group to be sure to be able to contribute our use cases to this document then.
* EP: Documenting how Client id, WebID and OP are associated will be very interesting.

### Clarify implicitly trusted OIDC issuer

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

* EP: This issue has been languishing around for a while. It looks like it has support (e.g. from Ruben V). One things which is still an open question is around if the WebID profile isn't public, and if headers should be set appropriately in that case. Related to issue #52 too.
* AC: This sounds sensible. PR #79 could fix these. All of the community seems to be going in this direction, and implicit trust doesn't seem to be required in any component
* EP: The specific case about the non-public WebID document could be worked around by setting Link Headers, does it sound good to you and should it be added to #79 to close the issues ?
* AC: +1. Glancing at the WebID spec draft, a non-normative statement says that the WebID profile should be public, and it sort of makes sense as per the definition of WebID. I'm not too concerned about the edge-case of a non-public WebID document.
* EP: We can also add an inline note as part of the PR and address this outside of the Solid-OIDC spec.
* AC: We could also add a note in our terminology about WebID that we expect the WebID to be a public document.
* EP: It sounds like there is enough conversation to be had to defer this and not bloat the current PR. We could also in the same manner require the WebID to be an HTTPS resource.
* AC: +1. Using an HTTP WebID opens a lot of MiM attack, and should be restricted to development.
* LD: Having exceptions for localhost for instance has been an issue in the past.
* AC: We could leave development-scpecific cases out of the spec at all. We should be careful not to require *only* https though, to be future-proof for DIDs etc.