Intention to start an [oauth] "working group" - Mailing list pgsql-hackers

From Jacob Champion
Subject Intention to start an [oauth] "working group"
Date
Msg-id CAOYmi+n5tXFTuE=khSKBGGr-OX4hbqP+ALV1yUe=gn9nbE3Hzw@mail.gmail.com
Whole thread Raw
List pgsql-hackers
Hi all,

At pgconf.dev 2025 there was an unconference session called "Scaling
PostgreSQL Development". Unfortunately, the wiki entry for it at [1]
is empty, but two of the conversation topics that resonated with me
were

- the idea of labeling a space on the list for a particular area of
development, and
- the idea of pulling a document that captures some form of consensus
(the "spec", if you will) out of the mailing list thread that is
capturing the day-to-day development and discussion.

I can't really guess how well these will work within our community. So
I'd like to propose an experimental working group covering the new
OAuth code.

= What does that mean? =

"Working group" probably carries a bunch of baggage as a term (and
honestly, I wouldn't mind a better suggestion). I want something
lightweight, so here's what I propose to do:

- I will add "[oauth]" to feature threads I start, so people can filter on it.
- I will add an "[oauth]" tag to the CF app.
- I will attempt to keep a living summary on the wiki for every
[oauth] feature, including ones started by other people, with some
inspiration from my favorite parts of the Python PEPs [2].

And that's it. The intent is for this to be an aid for discussion and
community building, rather than a silo with its own processes and
politics. This experiment is not binding on others and would ideally
not carry any more weight than "Jacob is trying a thing" -- though I
could use a skeptic or two keeping an eye on it to ensure it stays
that way, if it happens to gain momentum.

And if it doesn't gain momentum, that's fine (and probably expected).
OAuth might be too niche to attract much discussion. Worst case, the
community will hopefully have some extra design documentation on the
wiki.

= Why OAuth? =

I'm proposing OAuth for my experiment because
- I'm quite familiar with it now :)
- I expect to be doing a large fraction of the review and development
on it in the short term, until it matures
- it occupies a very small niche
- it's security-critical
- it already interacts with a maze of IETF specifications

There are opportunities for improvement that I don't expect to be able
to get to myself, and I want an excuse to write down what's in my head
and share it outward.

Honestly, OAuth is probably too narrow a focus, but IMO that's a
better side to err on. I certainly don't want try to put "all of
Postgres authentication" or "the protocol" under a personal
experiment, though I think those could potentially be great working
groups.

WDYT? Is this proposal light enough that it doesn't cramp other styles?

--Jacob

[1] https://wiki.postgresql.org/wiki/PGConf.dev_2025_Developer_Unconference
[2] https://peps.python.org/pep-0001/



pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: [PATCH] Add archive_mode=follow_primary to prevent unarchived WAL on standby promotion
Next
From: Sergey Prokhorenko
Date:
Subject: Re: Add uuid_to_base32hex() and base32hex_to_uuid() built-in functions