# W3C Solid Community Group: Authentication Panel

* Date: 2022-03-07T15: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
* elf Pavlik
* Nic AS

---

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

---

## Agenda

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

* [Primer: Solid OIDC Flow #86](https://github.com/solid/solid-oidc/pull/86)
* [Simplify Solid-OIDC Conformance Discovery language #89](https://github.com/solid/solid-oidc/pull/89)
* [make id token verification not be exclusive to AS #90](https://github.com/solid/solid-oidc/pull/90)

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

* [Accessing NonRDF-Sources directly via browser #31](https://github.com/solid/solid-oidc/issues/31)
* [Clarify what the issuer URL is #38](https://github.com/solid/solid-oidc/issues/38)
* [Presenting multiple WebIDs in an ID Token #47](https://github.com/solid/solid-oidc/issues/47)

## Minutes

### Primer: Solid OIDC Flow

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

* AC: I left it open in case someone has comments
* eP: I'll go ahead and merge it. Were there parts of the issue that were not addressed?
* AC: AFAIK, all the points in the issue were addressed
* eP: I'll merge the PR

### Simplify Solid-OIDC Conformance Discovery language

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

* eP: submitted ealier this morning
* AC: I will review after the meeting
* NAS: seems like a good clarification

ACTION: AC to review and merge

### make id token verification not be exclusive to AS

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

* eP: this was last minute
* eP: (screen sharing to show preview)
* eP: Issuer discovery section separated from verification
* eP: the use of `solid:oidcIssuer` predicate made explicit
* NAS: to clarify -- we added language about link headers. Is it possible to have an empty webid but also link headers
* eP: the link header section says that _if_ they are present in the headers, that the values MUST be the same as in the RDF. IOW, it would be an invalid WebID Profile (for Solid-OIDC) to have an inconsistency between the headers and the RDF document in this regard
* NAS: thank you
* eP: Sub-section for ID token validation, reference to OIDC-Core (e.g. MUST be valid according to parent spec). Verifying party must perform OIDC discovery
* eP: this decouples this section from the authorization server
* eP: this allows the text to reference the specific verification sections, delegating to parent specs, as needed
* eP: small changes
* AC: Looks like a good direction, especially being able to separate sections and refer to them as needed. It should help with defining conformance classes.
* eP: I will plan to start adding conformance classes (possibly next PR). E.g., add "client may perform client validation"

### Accessing NonRDF-Sources directly via browser

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

* eP: old issue (Dec 2019) that has been discussed a few times. There have been experiments with cookies and origin restrictions
* eP: this is the case where the RS acts as a client (RP)
* eP: if you access the solid Storage directly, there would be no use of an access token. Just an access token.
* eP: this is an example where the client must validate the ID token
* eP: it would be good to add a note to the spec related to this use case. For example, a way to login and act as a client.
* AC: This came up couple of times, we implemented it and removed the implementation. At high level I would argue that it doesn't belong in Solid-OIDC spec itself. However it would belong in the primer and best practices. One of the important things is that one can separate apps from the data. Here we would tie your app to the data. We want to be clear what that means and how that would work in the context of solid. We also need to specify implications, we need to be careful how we use client identifiers. Also how other apps could try to use cookies to circumvent their restrictions.
* eP: very much agree. Possibly the security considerations section would be relevant. Maybe mention that the cookie is for the same origin, possibly also for the Solid storage specification. Certainly it should be mentioned that this shouldn't be used to circumvent other client restrictions
* NAS: it seems like there is a fundamental question whether the Solid Storage is a Webapp or an API. In the case where the browser accesses the data directly, the pattern is that of a Webapp, but we need to clarify that, possibly at the level of the protocol spec. This flows from the nature of the solid protocol

ACTION: eP will open an issue in the protocol spec about this

### Clarify what the issuer URL is

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

* eP: issue from a while ago. Some conversation but hasn't been closed.
* eP: we should mention simple string comparison rather than IRI normalization
* eP: trailing slash could be an issue for users
* eP: should we add a statement about simple string comparison
* AC: +1
* NAS: +1

ACTION: eP will open a small PR to clarify this

### Presenting multiple WebIDs in an ID Token

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

* eP: if the OP knows that the user has multiple WebIDs, it could include both
* eP: there are also use cases where a user would not want these correlated
* eP: is the current defn of the webid claim sufficient? It doesn't say if it's singular or plural
* AC: I think it should be singular, if we want to allow chained delegation there are other ways to do that. I would prefer to keep Solid-OIDC simple
* NAS: +1
* eP: in that case, should we make it clear that the webid claim is a single value?
* AC: yes

ACTION: AC will make PR to clarify this