For the token endpoint, I recommend we stay consistent with the Iceberg REST spec by marking it as deprecated and aligning its removal with the same timeline as outlined in the Iceberg spec. Here are a few key points to consider:
1. Since the endpoint is marked as deprecated, and most production environments already rely on third-party token endpoints, the security risk remains minimal. 2. Per Iceberg REST spec, this endpoint is "Deprecated since Iceberg (Java) 1.6.0. The endpoint and related types will be removed from this spec in Iceberg (Java) 2.0.", Iceberg(Java) 2.0 is still a long way to go. There would be compatibility issues for dev and test raised between now and 2.0 if Polaris doesn't have it. 3. Support for third-party token endpoints was introduced about seven months ago in both Java and Python, which isn't too far back, as Michael pointed out. WDYT? Yufei On Mon, Sep 23, 2024 at 12:27 PM Dmitri Bourlatchkov <dmitri.bourlatch...@dremio.com.invalid> wrote: > > 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 > >> > > > > > >> > > > > >> > > > >> > > >> > > >
