> If we remove the endpoint in Polaris, clients prior to that release will have no mechanism for generating a token.
Missed to address this in my previous reply :) Existing Java REST Catalog clients (based on Iceberg's impl.) will be able to use bearer tokens and the Client Credentials OAuth2 Flow IIRC. Cheers, Dmitri. On Mon, Sep 23, 2024 at 3:23 PM Dmitri Bourlatchkov < dmitri.bourlatch...@dremio.com> wrote: > > If we remove the endpoint in Polaris, clients prior to that release will > have no mechanism for generating a token. > > The basic problem is that producing an auth token from the /token endpoint > in Polaris makes it assume the role of the Authorization Server according > to the OAth2 RFC [2]. > > Moreover, since Polaris is mainly a Resource Owner, assuming the > Authorization Server role goes against the grain of the OAuth2 design [3]. > > We can certainly go into more details on this, but maybe it should be a > separate discussion thread. > > My point about the first release is that such a concern already exists and > has been discussed in the Iceberg community. I think we ought to consider > it. > > Cheers, > Dmitri. > > [2] https://www.rfc-editor.org/rfc/rfc6749 > [3] > https://docs.google.com/document/d/1Xi5MRk8WdBWFC3N_eSmVcrLhk3yu5nJ9x_wC0ec6kVQ/edit#heading=h.2xju2266i6df > > > On Mon, Sep 23, 2024 at 3:06 PM Michael Collado <collado.m...@gmail.com> > wrote: > >> +1 on Russell’s comment. >> >> Re: the OAuth endpoint, it seems to me that compatibility with Iceberg >> clients needs to be considered. I think that prior to Iceberg 1.5 or so, >> there was not support for an external oauth tokens endpoint. If we remove >> the endpoint in Polaris, clients prior to that release will have no >> mechanism for generating a token. >> >> How far back do we want to maintain compatibility for Iceberg clients? >> IMO, >> Iceberg 1.5 isn’t that old. >> >> Mike >> >> On Mon, Sep 23, 2024 at 11:54 AM Russell Spitzer < >> russell.spit...@gmail.com> >> wrote: >> >> > My only minor feedback is I'd prefer we do a first release as 1.0. I >> think >> > there is an allergy to 0.1 software in production so I'd rather we just >> > start at 1. >> > >> > On Mon, Sep 23, 2024 at 1:50 PM Jean-Baptiste Onofré <j...@nanthrax.net> >> > wrote: >> > >> > > Hi Dmitri >> > > >> > > It makes sense to me. >> > > >> > > Regards >> > > JB >> > > >> > > Le lun. 23 sept. 2024 à 20:01, Dmitri Bourlatchkov >> > > <dmitri.bourlatch...@dremio.com.invalid> a écrit : >> > > >> > > > From my POV, I'd propose to resolve the OAuth token endpoint concern >> > [1] >> > > > before the initial release. >> > > > >> > > > I guess it might be a rather big refactoring, but this issue is >> already >> > > > generally accepted as a security concern in the Iceberg community, >> so I >> > > > think it would be preferable to resolve it before the first release. >> > > WDYT? >> > > > >> > > > Thanks, >> > > > Dmitri. >> > > > >> > > > [1] https://github.com/apache/polaris/issues/12 >> > > > >> > > > On Mon, Sep 23, 2024 at 1:22 PM Jean-Baptiste Onofré < >> j...@nanthrax.net> >> > > > wrote: >> > > > >> > > > > Hi folks, >> > > > > >> > > > > As we know from experience, that the first release needs some >> careful >> > > > > preparation steps, I would like to propose aiming for the Apache >> > > > > Polaris release by the end of October (after CoC NA). >> > > > > >> > > > > I propose to start from 0.1-incubating (currently we are building >> > > > > 999-SNAPSHOT :) ). >> > > > > I already created 0.1 milestone on GitHub. We can rename it if >> > needed. >> > > > > >> > > > > The preparation steps would be: >> > > > > - do the triage on the GitHub issues, assigning issues to the 0.1 >> > > > milestone >> > > > > - check the legal (LICENSE, NOTICE, DISCLAIMER, KEYS, etc). I will >> > > > > start some new checks/updates on that (as I have some experience >> :) >> > ). >> > > > > - check distribution and artifact publication (dist.apache.org, >> > > > > repository.apache.org, ...) >> > > > > >> > > > > I have several PRs in preparation, including the release >> preparation >> > > > > related PRs. >> > > > > >> > > > > As reminder about the process >> > > > > (https://incubator.apache.org/guides/releasemanagement.html), we >> > need >> > > > > to do release "internally" to the podling , and then start "again" >> > the >> > > > > vote on the incubator general mailing list. So it's a "longer" >> > process >> > > > > comparing to a TLP release. >> > > > > >> > > > > What do you think ? >> > > > > >> > > > > Thanks, >> > > > > Regards >> > > > > JB >> > > > > >> > > > >> > > >> > >> >
