(Presenter: M Hickford, Notetaker: Lessley Dennington)
(Slides: https://docs.google.com/presentation/d/127xue1Sr19J1m6wk1KwY9-5G1lPxbyHOgaIi2Ro12ts/edit?usp=sharing)

* (Hickford) I interact with many Git "hosts" (GitHub, GitLab,
  gitlab.freedesktop.org, etc.). I had 15 Personal Access Tokens (PATs) around,
  which was tedious. I was using Git Credential Manager, which has an option to
  authenticate via web browser which creates a token. I released
  git-credential-oauth with this feature which you can use with a storage
  helper. I'm going to show an example of authenticating to a host I've never
  used before (Gitea). Demonstrates signing into Gitea via web browser and
  cloning his fork of project xorm/xorm. Since the repo is public, no
  authentication is necessary. Makes a commit and pushes. Auth flow is
  triggered, provides consent. Authentication was successful. There was no need
  for PATs or shell keys. Git-credential-oauth supports GitHub, GitLab, Gitea,
  and Gitee out of the box. Works using new(ish) password_expiry_utc attribute
  and wwwauth[] headers.
* (brian) Thinks it's a great idea because it's convenient. github.com/github
  requires SAML/SSO and the browser, and this should work just fine. It wouldn't
  be great to have in C, but as a helper it's super convenient.
* (Hickford) Ruled out a C implementation due to the challenges. Goal was to
  remove a barrier to entry for contributors to OSS trying to make bug fixes and
  having to set up/deal with PATs/SSH keys.
* (Jakub) Still work to do with creating a fork, pushing.
* (brian) GCM does this but represents a greater barrier to entry for less Git
  literate users. Less beneficial for Git power users.
   * Edit: Lessley and brian spoke after the meeting, and Lessley realized the
     above was not recorded correctly. git-credential-oauth and GCM both remove
     the need for users to manually set up PATs/SSH keys (which was what was
     being considered as the high barrier to entry).