# W3C Solid Community Group: Authentication Panel

* Date: 2022-04-25T14: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
* Nicolas AS
* 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
* Nicolas AS

---

## Agenda

### Issues

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

* Prioritization
* Timeframe
* [Version format](https://github.com/solid/solid-oidc/issues/114) (e.g., 0.2)

## Minutes

### Mutliple open editorial issues

* AC: The 0.1 version has been released, which is a huge milestone. We just need to make sure we are aligned with the editors regarding version numbers. Take IETF for instance, with draft-v01, draft-v02... iterated until formal recognition. Currently, the draft is published under the TR label, which may lead to expect more stability than the stage we are in, we want to be extra clear about our assumptions and expectations.
* eP: Once we've iterated through enough 0.x versions and feel ready, we can move to the CR status.
* AC: In our draft, we can add a PR to update the version to Editor's draft 0.2, clearly stating that's the future version for the TR draft.
* eP: Is it required to call out editor's draft, as we're not under the /TR ?
* AC: Aligning the version number between the tag and the text makes it easier to work with in automation.
* eP: What you think is most practical with automation should be good.
* eP: I can go through the open issues about the primer.
* AC: A bunch of these issues should be individually small size, so if we could close some up that would be good. To prioritize, we can first focus on issues touching on normative text, then those who deal with terminology/abstract concepts (non-normative). Happy to take some of these.
* eP: Some of these issue may come from a lack of familiarity with OAuth. It could be settled with a simple reference to the underlying spec defining the term.
* AC: In [that particular case](https://github.com/solid/solid-oidc/issues/139), on the first instance change "code" into OAuth 2.0 code linking tho the auth code definition.
* eP: We can provide a reference, but don't need to get into too much details because implementors will have familiarity with OIDC/Oauth
* AC: +1
* eP: On issue https://github.com/solid/solid-oidc/issues/125, the suggestion seems to change a normative triple pattern to an example, which is not something we want to do.
* AC: In section 6.1, we do have an OP discovery example described, with the solid namespace defined, which would make https://github.com/solid/solid-oidc/issues/125 a wontfix. Would it make sense to have the example lower in the text, so that all of the normative text is together and not split by the example in the middle?
* eP: The conformance section explicitly calls out that the examples are non-normative, and it should be clear that the triple pattern is itself normative.
* AC: Let's comment on the issue, see what the reporter says, and maybe close it as a wontfix.
* AC: The general goal would be for the 0.2 to be ready by the end of May, would that be reasonable?
* eP: Yes
* AC: We would need to add a changelog, in particular for the normative text.
* eP: +1 on only normative changelog, because it is useful for the implementors.
* AC: It would be useful to have 1 entry in the changelog to summarize editorial changes as well, in addition to the normative changes.
* AC: The other thing we would like to clarify is https://github.com/solid/solid-oidc/issues/158, by explicitly calling out that access tokens are out of scope.
* eP: One tool that could help for the changelog is https://services.w3.org/htmldiff
* AC: One last item for today is https://github.com/solid/solid-oidc/issues/152. The architectural pattern around the AS and UMA is the only "SHOULD" of the spec on the server side, there are a handful of SHOULDs or MAYs for clients. Question: should we say that there MUST be an AS, and mention UMA as an example?
* eP: That would be related to making access token out of scope. How would we phrase this to support interop, e.g. between UMA and token exchange?
* AC: We expect that a lot of implementors will use UMA, but this should be open.
* eP: Should we do it in the same way as the notifications type, with mini-specs provided as extension points providing clear specifications for each possible mechanism being considered.
* AC: +1
* NAS: +1
* eP: For logistics, could we make sure to assign ourselves to the issues we are working on to avoid duplicatiion of work?
* AC: +1
* NAS: +1