W3C Solid Community Group: Authentication Panel

# W3C Solid Community Group: Authentication Panel * Date: 2022-01-03T15: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 * e 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 --- ## Agenda * [Open Pull Requests](https://github.com/solid/solid-oidc/pulls) * [Add RS associated AS issuing Access Token PR#18](https://github.com/solid/solid-oidc/pull/18) * FPWD timeframe * Ideas for next 6-12 months --- ## Topics ### Open Pull Requests #### [Add RS associated AS issuing Access Token PR#18](https://github.com/solid/solid-oidc/pull/18) * eP: What should be the next step? should we render it and ask for community feedback? * AC: We may be more forward about this, since this conversation has been going on for almost 6 months. An additional request for review for a couple of weeks won't change much. * AC: We may want to publish the current work as an Editor's draft, and collect feedback then. This creates a version number that we can refer to, and moves the effort forward. * eP: +1 * Nicolas: This makes sense. The relevant stakeholders are informed of this direction. The editor's draft/fixed version publication makes sense and that will help get more attention. * eP: are you distinguishing between FPWD and editor's draft? * NS: I meant FWPD * AC: We can leave the PR open for another week, and plan for it to be merged next week. * eP: No additional changes are planned expect for potential feedback. ### First Public Working Draft timeframe * AC: If you look at the Solid-OIDC web page, it simply says Editor's draft. That tracks every change in the repo, and that makes sense. However, from an implementor's perspective, having a specific version to refer to helps planning and communicating about what exactly is supported. * AC: We have the infrastructure to make a split between a static-ish FPWD and an Editor's draft. GH actions may be used for some aitomation * eP: using git tags can support automation in that domain to specify version that should be published as public working drafts as opposed to the evergreen Editor's draft. * AC: Agreed * eP: What tags should be used? * AC: No strong opinion, except that it should be a monotonically increasing number, e.g. `draft-1`, `draft-2`... * eP: We can also use dates, which additional gives the information when the draft was released. * AC: I like the dates format too. No strong opinion. Unless a strong opposition is raised, let's use the dates formatting https://www.w3.org/TR/2021/REC-vc-data-model-20211109/ * eP: let's start using the version tracking for the FPWD after having merged the latest upstanding PR * NS: no strong opinion. Dates are fine, too * AC: Action item: add tooling for this * eP: Once we have tooling, we can look into having the GH pages published. * AC: There's typically some noise when setting up such CD infrastructure, so I may have to merge my own PRs * eP: I don't know if it's allowed to push to main, but happy to allow it at least temporarily to set this up. ### Ideas for next 6-12 months * AC: The purpose of this agenda item is to start thinking ahead. Solid-OIDC is becoming fairly mature, so we may want to start thinking about what's coming next in the upcoming period of time. Items that we may want to provide more clarity on include client credentials, device code flow... Not necessarily providing spec, but we may have a WG note to indicate to the community we are working on this and provide some clarity. * eP: Working on client credentials and device code flow is definitely interesting. * eP: The priority can be, when we merge PR #18, to reorganize things so that we identify conformance classes with the associated requirements. Some conformance classes, such as the Solid-OIDC provider, have a lot of requirements, while Client Identifier for instance have much fewer. Clarifying this would be a nice first step towards completing the test suite. * AC: Agreed * eP: Action item: After merging #18, I can open a PR to reorganize the sections. * AC: When shuffling text around, it will be important to make sure the IRIs which change and were referenced by the test suite are updated accordingly. * eP: Having to do this change is a motivation to complete this reshuffle before tagging the FWPD * eP: An additional goal for the coming months is to complete the test suite, and collect implementation feedback running the test suites on existing implementations * AC: Within the next 6 months, I'd like to see Solid-OIDC move from FPWD to a proper recommendation * eP: That sounds doable. We've been conservative thus far in terms of making changes, but with the ~FPWD, we should be quite close to a ~CR status * NS: Increase community engagement (spread the word) * AC: This goes along with the incremental release process, from FPWD to candidate recommendation and finally recommendation.