> 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 > > > > > > > > > > > > > > >
