# W3C Solid Community Group: Authentication Panel

* Date: 2022-01-31T15:00:00Z
* Call: https://meet.jit.si/solid-authentication
* Chat: https://gitter.im/solid/authentication-panel
* Repository: https://github.com/solid/authentication-panel

## Present
* Nicolas AS
* Abel Van den Briel
* Barath
* elf Pavlik
* Aaron Coburn

---

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

---

## Agenda

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

* [Reorganize spec #73](https://github.com/solid/solid-oidc/pull/73)

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

* [Same Client ID can be used by server-side and on-device components of the client #70](https://github.com/solid/solid-oidc/issues/70)

## Introductions

* Abel Van den Briel: a developer at Digita, will be joining in the stead of Wouter
* AC: There are two repos to look at: official discussions happen in the solid-oidc repo and the authentication panel repo. Some discussion also happen on Gitter
* EP: Which parts of Solid-OIDc are you implementing at Digita ?
* AVB: We've implemented a proxy we want to make compatible with existing Solid-OIDC providers.
* EP: The proxy would conform to the OP class, correct ?.
* AVB: Correct. We'll maybe also implement an AS component at some point.
* EP: Note that the AS will be even more relevant in the AuthZ and interop panels.

## Minutes

### Reorganize spec

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

* EP: Different editions of the spec. 1: the JSON-LD document has been moved to appendixes. It creates a better reading experience, and it is linked to from the section where it is referenced.
* AC: +1
* NAS: +1
* EP: IdP has been replaced by OP to be more consistent with the OIDC spec.
* AC: +1
* NAS: +1
* EP: The next change is to refactor the spec to structure it around conformance classes. The test suite has references to conformant classes using the predicate `spec:requirementSubject`
* AC: Note https://github.com/solid/solid-oidc-tests/blob/main/data/solid-oidc.jsonld, driving some Solid-OIDC tests for the OP. Currently, the conformance class IRI is hard-coded in the JSON-LD context. The JSON-LD context is an RDF interpretation of the spec. The proposal by Pavlik is to prevent from needing this interpretation, and instead having the spec being structured so that the conformance classes are clearly identified.
* EP: Section 5.1 includes statements applying to two difference conformance classes for instance. What we could do is having the spec text describing the flow from a high-level, and then have each conformance class describing the details of the role of each class has in that higher-level flow.
* AC: +1. Some requirements apply to several conformance classes, so the structure you propose would avoid repeating these requirements in difference places. That would also be useful to implementors, who could refer to specific conformance classes.
* EP: The Client ID document conformance class would simply describe the structure of the client identifier. Then, the RP conformance class would describe how the RP is expected to provide the client identifier to the OP, and the OP conformance class would describe how to verifiy the client identifier. Another example would be for the WebID Issuer discovery via Link Headers. Note that the sequence diagam already identifies what would be the confirmance classes. The breakdown may be slightly more verbose (even though not too much), but it will make the mapping of requirements much clearer.
* AVB: +1
* NAS: +1
* EP: I will start with one of them, and ping everyone for initial review.
* AC: In the spirit of smaller, focused commits: should the current PR not include additional commits, and then each conformance class being merged one by one ?
* EP: +1 on merging the current PR. Not sure if refactoring the conformance classes can be done each in separate PRs, but will try to.

### Same Client ID can be used by server-side and on-device components of the client

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

* EP: The issue came up discussing a push API for notifications. The RP would be the one issuing the push notification. In this case, two parts of the same client communicate: the device-side portion of the client, and the server-side part. These two components could use the same Client identifier, and the user would log into each of these components using the auth code flow, but how could these client components use refresh tokens ?
* AC: Adding such examples in the priment is a good idea. This would be possible to implement with two sessions (device and server-side), which should not share access token.
* EP: The UX we want is that the user only sees one client, identified by its client identifier, and not get into the details of the components. They would have two separate login sessions in your description, correct ?
* AC: Correct.
* EP: it becomes up top the client to implement these two sessions independently. This is a good approach, will add this to the issue.

### Client credentials

* EP: Should we start discussing client credentials now ?
* NAS: I would rather have this discussion through async discussion in issues
* AC: +1, maybe the discussion would be more efficient with a couple of presentations from implementors and a focused agenda.
* EP: Is anyone interested in taking leadership ?
* AC: I would be able to. Starting with clear use cases is a nice way starting discussing a new feature. That would help to onboard people who aren't familiar with the panel work.
* EP: Will ask Justin for use cases on the Interop panel
* AVB: We also have questions about this flow. I will try to formulate a proper use case as well.
* EP: What we are talking about here is the flow between the RP and the OP. The interaction between RP and AS would be out of of scope for this discussion.