Hi Rory, Do you have a specific catalog server implementation in mind, or a use case? This could help decide what is the best option moving forward.
It occurs to me that Iceberg Java indeed has a BasicAuthManager, so Basic auth is "unofficially" supported at least in Java already. If we really want to mention this new scheme globally, let's at least make sure it is accompanied by a clear written warning regarding its security limitations. Thanks, Alex On Wed, Apr 8, 2026 at 2:37 PM Steve Loughran <[email protected]> wrote: > > > why? > > It's not "a security scheme" by the modern definition of authentication > mechanisms, whose weaknesses after 30 years are well documented. > > No defence against MITM > Transmits credentials over the wire; if stolen are gone until you next roll > the secre. > Doesn't validate message integrity > etc > > About the only thing in its favour is the clients don't need to rely on an > library to do the auth as it's built into most http clients. But if you only > support basic auth then you can only talk to those catalogs that implemented > it, so are either restricted to a subset of catalogs or, if the app turns out > to be popular, force all implementations to support an auth mechanism which > we all agree is flawed. > > I would personally advocate for the # of auth mechanisms to be kept to an > absolute minimum, ideally: 1: > > Testing interoperability becomes a lot easier as everyone authenticates the > same way. > If a client has an auth problem, it's likely to surface everywhere > > i know basic auth is easy to set up so you can deploy a dev system without > having to set up a more complex authentication protocol -but requiring those > dev systems to use a stricter auth protocol forces everyone to get that > implementation right as failures will happen during development, rather than > only surfacing in production. > >>
