# W3C Solid Community Group: Authentication Panel

* Date: 2022-04-04T14: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
* Aaron C
* Sarven C
* e Pavlik
* 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 AS

---

## Agenda

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

*

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

* Community Group Draft Publication
* [Feedback from editors](https://github.com/solid/specification/blob/main/meetings/2022-03-30.md#add-solid-oidc-draft-specification-and-primer-to-solid-project)
* Version numbering (e.g., 1.0)
* [Automation](https://github.com/solid/solid-oidc/pull/101)
* Draft Status: https://tabatkins.github.io/bikeshed/#metadata-status
* https://www.w3.org/standards/types#UD
* example of UD - Unofficial Proposal Draft https://w3c.github.io/web-locks/
* https://www.w3.org/standards/types#Others

## Minutes

### Community Group Draft Publication

* AC: Moving things forward for the FPWD, and addressing remaining loose ends. The first topic is feedback shared by the editors, in particular regarding version numbering (see [Feedback from editors](https://github.com/solid/specification/blob/main/meetings/2022-03-30.md#add-solid-oidc-draft-specification-and-primer-to-solid-project)). @SC, do you want to share feedback ?
* SC: Specifically about version numbering, or in general ?
* AC: In general. To my understanding, the version nubering should look like 1.0-WD.1 (and then 1.0-WD.2...)
* SC: Before the PR bringing Solid-OIDC to FPWD, there has been editorial discussion about version numbering. The w3c version numbering isn't oficially adopted by the Solid WG. The reason why we think having a {.n} extension is to align with other scpecifications, such as CSS. There was no strong opinions by the editors, but a general agreement about the 1.0-STATUS.version pattern to convey a clear message about the state of the specs. Calling the state a FPWD doesn't clearely convey if it is implementation-ready or not.
* AC: Generally, what we are trying to target with this spec is a 1.0, even if we're just in a draft spec. The proposed pattern makes a lot of sense to convey this intention. Having a {.n} extension shows that there can be multiple iterations of the docupment in its current state, but indicates stability of the current exact version.
* SC: We're ironing things out because we're not striclty operating under the CG process, and there's a lot of influence from the solid project. There are some documents which will be deprecated altogether (e.g. WebSockets 2021), but overall these TRs are here to stay. Not all panels will have specs, and we want to have alignment between those who will. The editorial team is working towards a clear guideline for that soon. In the meantime, panels shouldn't necessarily spend too much time to consolidate a convention until it is agreed upon at the editorial level.
* AC: Should we use CG-DRAFT status or FPWD status in these docs? We can pick any now, and it's fine to come back on it later. Being the first ones going through this, it's expected that there is some friction that hopefully will benefit to other panels.
* SC: Besides editor's draft, CG-Draft is fine, which is currently what's in the PR. There are specs in the notifications panel that can be used as an example too.
* AC: Note that there have been some reviews on the primer, with improvements suggestions, some of which have been merged already. The approach we can take is to make changes in the source document. For more substancial changes, we can open issues in the source repository first.
* eP: +1 on inline changes of the source document. Tracking feedback in issues is also a good thing. How do we update the . We should reconsider having hard dates in the snapshot not to be prevented from editing the PRs proposal
* SC: One approach that could work (currently outside of a process), instead of PRing into solid-specifications, would be to get the editors to come to the source repositories (to review the PR). All the feedback iteration happens in the source repository, and then once it is accepted getting the latest version to the solid-spec repo is just a mecanical thing. Reviewers should go to the source, instead of the proposals coming to the solid-spec.
* AC: On the one hand, having PRs going to the spec repo can be useful for gating, but +1 on reviews happening in the editor's draft in tghe source repo. Change is easier to handle there, so it would be ideal. Realistically though, editors won't necessarily go to the source repos until a PR is opened on the solid-spec repo
* eP: Editors have editor's meeting, so we could signal the fact that new versions of the editor's draft is about to be published so that they can take action to review it. Reviews don't need to happen in a PR, but rather in the snapshot that is the draft once the PR has been merged.
* SC: +1. The notification panel right now branched the snapshots for inclusion to be included in the solid-specification repository. When a WG proposes a document be published, the reviewers review the snapshot to be added, and not the draft. Then the editor's draft is updated, and a new snapshot is created, and so on. No strong feeling about which repository should be reviewed. We don't want reviews to become unclear because it's unclear what reviewers are committing to.
* AC: Right now we make a PR to the solid-spec, that's the snapshot. We can continue like this. There is an issue with automation though, because updating the draft to become a snapshot is very manual and error-prone. I've put together some automation to create a snapshot in a branch based on a tag. The challenge is with the first TR: there is currently nothing at the TR's URL. As soon as we merge something into this locaion, we can refer to it, but to be able to refer to it in the snapshot it needs to be created. If we merge the current snapshot in the solid-spec repo, a document will exist at the TR URL, but itself will refer to a non-existing document. Is it something all TR's face ?
* eP: Snapshots are immutable, so updating them based on reviews doesn't really make sense. About the URLs, should they reflect the version numbers ?
* SC:
* The snapshot which is reviewed is the proposal to be published, and not the published document itself, which allows more flexibility for the URL issue.
* If the editor's draft isn't published yet, the TR URL can be omitted, or 404.
* solidproject has a TR/ container, with resources intended to point at the latest snapshot of the sec. Each of these intermediary containers will then contain specific immutable versions of the iterative snapshots. The "latest" URL is the one we want to be passed around generally, and specific versions are more for implementations.
* AC: Re versions in URLs, different groups do different things. VC use the same link for 1.0 and 1.1. RDF concepts has RDF-Concepts and RDF-Concepts/1.1, so basically we'll follow whatever the specification aligns on. It seems that a common pattern is to have a "latest" URL which will default to the latest versionned one, and then immutable versionned ones.
* SC: We just want to be consistent with our persistence policy. The versioning policies are documented in the repo's CONTRIBUTING and/or README.
* AC: Then we'll keep doing what we are doing, which seems aligned with what you're describing, and let us know if there's an issue.

## Draft Status

* AC: is this related to the previously discussed items ?
* eP: The issue is that the status is used as a watermark in the default bikeshed style, which may be off-putting depending on the status we use. Should we override bikeshed's style, or which status should be used ?
* AC: The watermark is also an incentive to move into REC status
* SC: As long as the document status is clear about endorsement and intellectual property, from a communication point of view it's okay to call the document an Editor's Draft or Unofficial Draft.
* eP: We should also have the same consideration for the primer, it's typically a note.
* SC: Since we're not using the W3C actual terminology in Solid, there isn't really any constraint on how we want to call the primer.
* AC: Bikeshed has a NOTE-WD for "Working draft" of a note, which works well for the primer
* eP: +1
* NAS: +1
* AC: And WG-NOTE for the final published version
* AC: I propose to iterate on the editor's draft until next week, and then open a new snapshot into the solid-spec repo, in order to keep a certain pace to get the Solid-OIDC spec mooving.
* eP: +1
* SC: Would the diff between the snapshots be just based on reviews, or would there be additional content ?
* AC: Actually what we would want is to merge the current PR, and then open a new one, all driven by automation
* eP: We should have some kind of changelog capturing what changes have been incorporated for each version.
* AC: +1, we can just remove that for the final published versuion
* SC: eg. https://www.w3.org/TR/ldn/#change-log